jay (support) wrote:Yeah - currently the getActionsDict() method, which has the dictionary of all actions in it, is only called at plugin startup so overriding that won't help much. And in order to do what you want to do that method would have to be called several other times as well (like for instance after every device creation/update/deletion).
OK, so do I have access at startup of the device to delete actions, similar to how I currently delete states that are irrelevant using getDeviceStateList and end it with "return newStateList"? This is what I'm looking to do.
jay (support) wrote:I actually think it's good to show every action regardless of whether there's a device that can do it. It's one way a user has to explore functionality and learn about other features. If they see an action in your plugin that they can't perform it may prompt them to go figure out what it would take to perform that action.
That may be true for many devices, but in a pool/spa plugin, the only device you choose is your system, and if you have a combination pool/spa, you are not likely to learn much from having actions applicable only to a separate pool and spa system. It's not like you can go buy a $49.99 Insteon spa pump, plumbing and heater. To use the other version of those few actions you need to spend at least several thousand dollars and renovate your entire pool plumbing. I guess I could write and maintain two separate pool/spa plugins, but that seems like a pain for me when 90+% is identical??
Note, however, that there are several actions that show up that folks on a given "main" system may not be able to use on their system, that they could add with a new pool relay or the like. As you note, seeing those may prompt them to ask questions and explore new options. That's not the case for the "main" system plumbing options/actions however.
Jim