Add / Remove Actions from Action.xml set

I seem to recall reading somewhere in the documentation that it is possible to add/remove actions that are part of the Action.xml set, but can't seem to find it now that I need to know how. I'm not referring to adding Action Groups to Indigo, but rather those that show up as device specific actions for Triggers and Control Pages.

I want to have one or two actions that are specific to the device selection (in my case pool/spa combo system vs. pool/spa separate equipment system), and remove those that are not appropriate for the alternate system.

I know I could handle the action, allowing or disallowing, based on device, but would rather not even have an inappropriate action even show up, if possible.

Jim

[jay (support)]

You can specify a device filter on your action definition - if it's there then when you select that action a list of matching devices will show up just under the action popup. Define the action like this in the Actions.xml:

Code: Select all

<Action id="myAction" deviceFilter="self.myDeviceType">

If you want it to work on any of your devices just use "self". Is that what you were looking for?

You can specify a device filter on your action definition - if it's there then when you select that action a list of matching devices will show up just under the action popup. Define the action like this in the Actions.xml:

Code: Select all

<Action id="myAction" deviceFilter="self.myDeviceType">

If you want it to work on any of your devices just use "self". Is that what you were looking for?

Jay,

Not sure this will work. The ID is specific to the model (e.g. id=jandyAqualink-RS-4-Combo), and therefore the actions, but all of the devices have a type=custom.

Is there a way to add or remove an action, or filter it based on deviceId?

Jim

[jay (support)]

The filter is your unique id, not the type.

The filter is your unique id, not the type.

?? I'm being dense I guess.

I have four device possibilities: jandyAqualink-RS-4-Combo, jandyAqualink-RS-6-Combo, jandyAqualink-RS-8-Combo or jandyAqualink-RS-2-6-SepEquip.

I want to have an action for the first three that looks like:

Code: Select all

   <Action id="togglePump" deviceFilter="self">
      <Name>Toggle pump on/off (Pool/Spa Combo systems only)</Name>
      <CallbackMethod>togglePump</CallbackMethod>
   </Action>


and one specific to the last device type (the RS-2-6) that looks like:

Code: Select all

   <Action id="togglePoolPump" deviceFilter="self">
      <Name>Toggle pool pump on/off (Pool/Spa Separate Equipment systems only)</Name>
      <CallbackMethod>togglePoolPump</CallbackMethod>
   </Action>


Can I have the first set show for only those device ids, and the latter for the RS-2-6 only? Changing deviceFilter="self" to deviceFilter="self.jandyAqualink-RS-2-6-SepEquip" doesn't work. I can have the plugin.py file differentiate the device id after the action is set up, but I don't want the user even see an action that isn't applicable to their device.

Jim

[jay (support)]

There's no way to filter out multiple of your device types - it's either all the devices defined by your plugin or a single device. This, however, should have worked:

Code: Select all

<Action id="myAction" deviceFilter="self.jandyAqualink-RS-4-Combo">

That will cause the client to build a device list of "jandyAqualink-RS-4-Combo" type devices. That's exactly how the iTunes plugin (for instance) works with it's actions.

There's no way to filter out multiple of your device types - it's either all the devices defined by your plugin or a single device. This, however, should have worked:

Code: Select all

<Action id="myAction" deviceFilter="self.jandyAqualink-RS-4-Combo">

That will cause the client to build a device list of "jandyAqualink-RS-4-Combo" type devices. That's exactly how the iTunes plugin (for instance) works with it's actions.

Jay, Got it ... finally. So, when I use the code above, I get the following when "my" device=pool/spa system is not the one listed - that is, the device pop-up is blank, because "my" device doesn't support the selected action:

Screen Shot.png (57.11 KiB) Viewed 2705 times

What I've been trying to ask is whether I can in some manner change the list that pops up at the start (derived from Actions.xml), so that only the actions in yellow or those in pink are displayed, based on my device.

Action Selections.png (181.67 KiB) Viewed 2705 times

I expect I'd need to manage this in the plugin.py code, but don't know if I can?

Jim

P.S. I finally figured out how to get in-line png files posted.

[jay (support)]

No - the flow of the popups is Type, Plugin, Action, Device (if there's a device filter) - you can't do Type, Plugin, Device, Action which is what you'd need to customize the Action popup based on a device.

But if you think about it, fundamentally it's the same thing. Select the action and get a list of only the devices that can perform that action.

I think I see where you're going - you don't want to show actions that can't be performed because you have no devices that can do them. We have the same problem - if for instance you select "Control Thermostat" but don't have a thermostat then you can't get much further in the process.

I think I see where you're going - you don't want to show actions that can't be performed because you have no devices that can do them. We have the same problem - if for instance you select "Control Thermostat" but don't have a thermostat then you can't get much further in the process.

Exactly. For the pool/spa plugin I've worked on, there is almost no chance that someone will have two devices, i.e. two pool/spa systems, active in their device list at the same time. So, there's really no reason to have actions in the Action.xml that they can't use.

For those who are adept, they can modify the Actions.xml file to remove "unusable" actions, but I was hoping there was some way I could do that in python, similar to how I use the getDeviceStateList call to remove the states that are not applicable for a given system.

I guess it's not possible, and that will just have to do.

Jim

[jay (support)]

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).

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.

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.

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

[jay (support)]

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.

Nope - as I state above the actions list is only built once in the server (at plugin startup) and is then immutable until the plugin restarts.

I suppose you could restart the plugin each time you add a device - then override the getActionsDict() method to filter out the actions you don't want to show. A hack to be sure...

I suppose you could restart the plugin each time you add a device - then override the getActionsDict() method to filter out the actions you don't want to show. A hack to be sure...

Would I just add a "def getActionsDict(self, dev)" to the python.py file, along with the code to loop through each action and dump those that are not needed?

Again, for this type of system, one device is added (a pool/spa system) and only one device. I cannot imagine there are too many people using Indigo that have two pool/spa "systems" that they are controlling, so having this execute each time a new system is added, which would only be if something was screwed up in the original device creation, should be fine.

I'll give it a try,
Jim

[jay (support)]

This is the getActionsDict method as it's implemented in the base class:

Code: Select all

def getActionsDict(self):
   return self.actionsTypeDict


self.actionsTypeDict is a dictionary where your action ID is the key. So if you were to go through self.actionsTypeDict and remove the ones you don't want before you return it then I believe you'd be set.