All Control Plugin v.05

[sub]Note: See at the end of this post for updates.[/sub]

[sub]Updated: 02 September 2013[/sub]

I was reading through the forums, and stumbled across an old post by Ap15e called AOO - a plugin that would turn Z-Wave devices (that supported it) on or off using the ALL ON or ALL OFF Z-Wave command.

Original discussion on this can be found at:,9034.msg59072.html#msg59072

And more info with the no longer available AOO plugin:,9080.0.html


WARNING: This plugin may trigger devices other than what you have configured. The UI in Vera is not always updated to show the current state of the device, so you will have to visually check to make sure everything is on or off. I highly recommend you use the information in the AOO plugin thread to disable any devices you don’t want triggered before using this plugin.

I was disappointed that this was a plugin that was no long available to for download/use. Since the concept of operation was described in detail in the two forum posts above, I decided I would try my hand at making my own plugin.

I present to you:
All Control Plugin v.05

The theory behind the operation/function of this plugin is, if a Z-Wave device supports and has been configured to respond to the ALL ON or ALL OFF Z-wave command, then you can control those devices with a single push of a button.

I used the Binary Light device for the interface, with the buttons labeled “All On” and “All Off”. It should function as a master light switch.

The plugin has the following variables that must be configured:

Devices - A list of devices (using altids) and config mode.

Format: [alt id]=[mode].

Where mode is:
0 - Disabled (device ignores)
1 - Off enabled
2 - On enabled
255 - On and Off enabled

Suppose you have three devices, all with the alt ids of 5,6 and 7. You want to disable 5, have 6 respond to both ON and OFF commands, and 7 only respond to the ON command. To do this, you would set the Devices variable to:


SendMode - Changes the behavior of the data passed with the SendMode command. The data will either use spaces or dashes to separate the data items passed.

0 - Don’t use dashes (default)
1 - Use dashes

StartupConfig - This will prevent the ACP Plugin from calling the config routine at startup.

0 - Off. Prevents the config routine from being called at startup.
1 - On. Calls the config routine at startup (default)

ForceSetup - This will cause the configure routine to be called before the ALL ON or ALL OFF command, causing them to be re-setup on each run.

0 - Off, don’t setup z-wave devices before sending ALL ON/OFF command (default)
1 - On, configure z-wave devices before sending ALL ON/OFF command

Note: If you set StartupConfig to 0, ForceSetup must be set to 1.

VerboseDebug - causes additional messages to be sent to the log file

0 - Off (default)
1 - On

OnCount - Number of times to send the ALL ON command (default = 1).

OffCount - Number of times to send the ALL OFF command (default = 1).

Delay - Number of milliseconds to delay between sending each successive ALL ON/OFF command (default = 1000)

ConfigDelay - Number of seconds to delay after running the device config route - used with ForceSetup (default = 10 seconds).

UseSetTarget - This will turn the specified devices on or off using the SetTarget call rather than broadcasting the ZWave ALL ON/OFF commands.

0 - Off. Use ZWave ALL ON/OFF (default)
1 - On. Use SetTarget

ReverseOnOff - Changes the behavior of the ALL ON/OFF switch, reversing its behavior (i.e., SetTarget = 0 will turn on devices, etc.) ( 0 = normal mode, 1= reverse mode).

Here are the functions that you can use:

(Called using: [tt]urn:acp-plugin-org:serviceId:ACP_Service1[/tt] )
AllOff - will send the ALL OFF command
AllOn - will send the ALL ON command
GetStatus - will return the value of Status (1=on, 0=off)
ToggleState - will “toggle” the switch to the opposite of its current state. If the switch is on, then it will turn off, etc.

(Called using: [tt]urn:upnp-org:serviceId:SwitchPower1[/tt])
SetTarget - used in the same manner as the SetTarget function for a normal light. (0 = turn off, 1= turn on)
GetStatus - will return the value of Status (1=on, 0=off)
GetTarget - will return the value of the Target state variable (always seems to be 0). (Included since it shows up when querying the SwitchPower service as an item)

I’ve noticed that you often have to wait a bit before the ZWave ALL ON or ALL OFF command will work. The values that you use to configure your device depends on what it supports.

Hopefully someone finds this useful.

Let me know what bugs you find.

Oops: I mixed up ALL OFF and ALL ON in the SendData command. Fixed!



  1. I realized that I had the wrong ServiceId in the .json file. I was not using SwitchPower for the events list. I just updated the .json file now to use the correct ServiceId.

  2. There was a small problem with the checking on startup that prevented logging of all the devices and the status they were set to. This has been fixed.

  3. Part of the problem with reusing code, you sometimes miss something when you are too “close” to the subject. There was one variable that I forgot to change the name of in the switch status function. It is fixed now.

Version .02:

I have added the ability to send multiple ALL ON/OFF commands when using this plugin.

By setting the OnCount and OffCount variables, you can have the plugin send successive ALL ON/OFF commands. I have found that this helps with the problem I noted above with devices sometimes ignoring the ALL ON/OFF command.

The Delay variable defines the amount of time to wait between sending each successive ALL ON/OFF command. This code currently does not check for an invalid value in this variable, so I would recommend not using a value less than 1 or one larger than 1000.

Version .03:

I fixed the SetTarget function, making the plugin now act like a light switch. I’ve tested this with HomeWave and it works like it should.

Calling it with:

Will now return:

{ "u:SetTargetResponse": { "OK": "OK" } }

The SetTarget function will not immediately call the function to send the ALL ON/OFF command. Instead, it updates the Status variable, and then using luup.call_timer, it will queue appropriate ALL ON/OFF command to be called 3 seconds later.

I found that, when the plugin is setup to send multiple ALL ON/OFF commands, the delay caused by calling the ALL ON/OFF routine directly results in the command being called multiple times. This was due to the change in the Status variable not being caught, and the delay making the application think the command failed or timed out.

A new variable called StartupConfig is now available. Setting this to 0 will prevent the device configuration routine from running at startup. By not having the config routine run at startup, you can now have multiple ACP Plugin devices, all setup to control different groups of lights.

If you set this to 0, then you must set ForceSetup to 1. The plugin will check to make sure you haven’t set both to 0, preventing you from shooting yourself in the foot.

An example of how you would set this up

Suppose you had the following devices:

4 - Living room lamp #1
5 - Living room lamp #2
6 - Living room lamp #3
10 - Front Porch Light
11 - Back Porch Light
14 - Bedroom table lamp #1
15 - Bedroom table lamp #2

You want to control your lamps by the location they are in, having them controlled by a ACP Plugin device. To do this, you would create three ACP Plugin devices, and set the devices variable to:

Living room:


Outside lights:


Bedroom lights:


You would also set each plugin’s ForceSetup to 1 and StartupConfig to 0.

In theory, this should:

  1. Re-configure your ZWave devices, so only those you want to respond will (you need to include ALL ZWave devices that respond to the ALL ON/OFF command)
  2. The ALL ON/OFF command will be sent.
  3. Your configured devices will turn on or off.

Version .04:

I’ve come to realize that due to either limitations of the Vera3, ZWave or both, that trying to:

  1. Use multiple instances of this plugin, with StartupConfig=0 and ForceSetup=1, may not produce the results expected. In fact, it is likely that without ConfigDelay set to something around 30 seconds, that your devices will not even respond to the ALL ON/ALL OFF command broadcast.

  2. Trying to run this plugin with the ALL ON/OFF command right after reloading/startup will not do anything. You have to wait about 20 seconds before your devices will respond.

  3. Any type of activity (Vera/plugins or ZWave devices/network) can cause the ALL ON/OFF command to not work/be ignored.

(ConfigDelay is a new variable in this version)

So, that being said. I’ve added some new features to this plugin that will allow you to turn devices on /off using calling the [tt]SetTarget[/tt] service of each ZWave device.

I’ve added a new variable called UseSetTarget, that when set to 1, will use [tt]SetTarget[/tt] to turn your devices on/off. The parameters passed in the Devices line will act the same using either the ZWave ALL ON/OFF or SetTarget modes of control.

(Note that sometimes Vera may show in the logs that all the SetTarget calls have been passed, but it will hang momentarily before all your devices respond.)

Since the SetTarget command requires device IDs, and I really didn’t want to break any configuration options from the previous versions, I’ve implemented function that maps device IDs to the ALTIDs specified in the Devices variable. Turning on VerboseDebug will allow you to see some of this mapping in action.

I’ve also modified what the AllOn/AllOff function calls do. They now just call SetTarget with the appropriate value (0 or 1).

And there are some changes/cleanup to the code as well.

Version .05:

There are just more general cleanups of the code. I didn’t realize that I have not been using service and serviceId when defining my services, instead I was using device. I’ve fixed this now.

<serviceType>urn:acp-plugin-org:service:ACP_Service:1</serviceType> <serviceId>urn:acp-plugin-org:serviceId:ACP_Service1</serviceId>

Looks like I will need to check my other plugins for the same error. Not sure how that creeped in, but I found it using this on my Vera: http://<VeraIP>:3480/data_request?id=invoke

That was when I realized that the :device: should be :serviceId:

I have added two more functions:
GetTarget and ToggleState

Support for the ReverseOnOff variable has also been added. This will allow you to change how to switch acts, effectively setting it to act the opposite of what you specify with SetTarget. I added this just for completeness, since each individual ZWave light switch in the system should already have this defined if it was installed backwards, etc.

Here is what I am using to get this to work on my system:

I have a ZWave network of 17 devices (mostly power switches, with a few dimmers and a receptacle). I don’t want all these devices to respond to the ALL ON or ALL OFF command, so my devices variable is:


This is telling everything but the dimmer in my kitchen and the switch in the dining room to ignore the ALL ON/OFF command. Those two devices are setup to respond to both ON and OFF commands.

My system works only when the dashes are included in the SendMode command (at least it did when I was testing this out, I’ve since tweaked the code, so I may be able to change this.) I have SendMode set to 1.

Everything else is using the default values.

Now, when using the ALL ON or ALL OFF, I’ve noticed that some of my devices don’t always respond (mainly the dimmer in my Kitchen and the switch in the Dining Room). I have found that if I let the system just sit, no events, etc. that the devices are more likely to respond.

If I use the ALL ON or ALL OFF command, and then say, go trigger something like turn a light on using the web interface or at the switch itself, the command will no longer work. I will have to wait a short while before I can use it again.

I assume that this is due to me trying to send data directly on the ZWave network, and the system is busy handling other events, so my request is dropped or ignored.

Something else I have noticed, unlike when I hit the on button on the control panel, the dimmer in the kitchen seems to ramp up and down differently than what I have it set for (I changed it to 1 second). Using the normal ON/OFF, the light comes on fast and ramps down fast. Using the ALL ON/OFF, the ramp speed seems to be closer to the default of 3 seconds. It is a GE/Jasco dimmer.

Has anyone tried playing/using this yet?

Using v.02 of this plugin, setting OnCount and OffCount to 10, and Delay to 1000 helps with any devices ignoring/not responding to the ALL ON/OFF commands.

It might be overkill, and I have a feeling that I’m flooding/causing the ZWave equivalent of a broadcast storm on the Zwave network, but it is working.

Let me know if anyone else using this plugin finds this feature useful.

I’ve found that setting the SendMode to 0, so it does not include the dashes in the command, usually gives me better results.

I wonder if there is a difference between sending the command with and without dashes?

Probably an obscure bug in Vera?

How does the device mask work in the all on/off command being sent? Is the mask included in the Z-wave command? If so, one could set up multiple masks (one for each room for example)

I’ve installed the plugin and it’s working just fine.

I have also tested HomeWave against this plugin. The App sees the device as a binary switch, and correctly shows the status of the switch. However I am not able to control the plugin from the app. The following command (standard for binary switches) is sent:

The result is: ERROR: No implementation.
The Implementation file of the plugin needs code that responds to these incoming service requests.

Right now, it is an all or nothing type configuration. If you don’t include a device in the Devices variable, then it will respond based on what its previous setting was (which I found normally seems to be respond to both the ALL ON and ALL OFF commands.) When you run the plugin, it individually configures each device you specify in the Devices variable using low level ZWave commands. When you click on the ALL ON/ALL OFF buttons, only the ALL ON/OFF command is sent using the same low level ZWave commands.

You could do multiple rooms by creating multiple plugins and configuring each to your liking (you’d have to configure ALL of your devices in each plugin though), and then setting the ForceSetup variable to 1, so the config is sent when the ALL ON or ALL OFF command is run. Any devices left out of the plugin will respond based on their current setting.

Not the best way, but for now it works. As time goes on, I will look at adding features like grouping, etc to it.

[quote=“intveltr, post:6, topic:176592”]I’ve installed the plugin and it’s working just fine.

I have also tested HomeWave against this plugin. The App sees the device as a binary switch, and correctly shows the status of the switch. However I am not able to control the plugin from the app. The following command (standard for binary switches) is sent:

The result is: ERROR: No implementation.
The Implementation file of the plugin needs code that responds to these incoming service requests.[/quote]

Hmm, I must have messed something up. I did try to implement a SetTarget action, but I may have it on the wrong device (not handling it for the SwitchPower device).

I just checked, I did define it on the wrong device. My SetTarget isn’t responding on the SwitchPower device, but the ACP_Device:

This does work:

Since this is my first plugin that attempts to implement something like this, I appreciate the feedback. I will be able to make the changes to this sometime later this week.

After installing your patch, the plugin now works correctly with HomeWave (and should work with all other mobile apps) :slight_smile:

With multiple Plugins and the ForceSetup … is it any faster than just sending a SetTarget to each individual grouped device ?

This seems like it would only be fast if you have one group.

Good question.

I have not tested using this vs sending a SetTarget to grouped devices, mainly because I haven’t grouped any devices together yet (no need).

I added ForceSetup in case someone wanted to have multiple plugins, but with how strange the ALL ON/OFF command acts (there are and can be significant delays), there is no guarantee that this isn’t just a useless feature.

I just uploaded a new version of the plugin, version .04.

I’ve either hit a limitation of the Vera, ZWave, my setup, or a combination of the three. I’ve found the following problems:

  1. If you try to use this plugin right after the Vera has done reloading, nothing will happen. You have to wait about 20 seconds before the ALL ON/OFF command being broadcast on the ZWave network will be acted on by your devices.

  2. If you setup multiple plugins, set ForceSetup=1 and StartupConfig=0, it is likely that your devices won’t respond to the ALL ON/OFF command that is broadcast. I’ve attempted to mitigate this by adding in a new variable called ConfigDelay, that may let you do this but with the tradeoff of having to set the delay to something at or above 30 seconds.

Like I said, I don’t know if this is a limitation of my setup, Vera, ZWave or a combination of the three. It may be that I just found a dark corner/limitation of Vera and its ZWave support. I may also be completely overlooking something obvious that needs to be set to have the ALL ON/OFF broadcast command work 100% of the time.

So, I’ve added a new feature that will let you toggle whether to use the ZWave ALL ON/OFF command or SetTarget to turn your lights on/off.

I just made some changes to the plugin, and caught an error in my D_ file and urn that I was using.

I was using the following in my D_ file:


I’m not sure how I didn’t catch this sooner. Luckily there seems to be no checking by the Vera’s internal routines to make sure you are using :service: and :serviceId: for these lines, so it just executed whatever I told it. (I was also using for my serviceId line in my I_ file urn:upnp-org:device:SwitchPower1, which matches the definition in the D_ file.)

I have not yet tested this change to see if it fixes the problems/strangeness I was having with the ZWave ALL ON/OFF command. I will have to test later on, once my wife is done with what she is doing (she won’t like me plunging her into darkness during my test).

I was looking through the VSwitch code, and noticed that there was support to set the ReverseOnOff variable on the HaDevice1 service, effectively making your SetTarget calls work in reverse. I added support for this in (but as part of ACP_Service1), since it seemed like just something to do (it serves no real function other than making it easier to flip the behavior of all your lights that you define, without having to go back and change the configuration variable.)

[quote=“SOlivas, post:1, topic:176592”]I present to you:
All Control Plugin v.05

The theory behind the operation/function of this plugin is, if a Z-Wave device supports and has been configured to respond to the ALL ON or ALL OFF Z-wave command, then you can control those devices with a single push of a button.

I used the Binary Light device for the interface, with the buttons labeled “All On” and “All Off”. It should function as a master light switch.[/quote]

Can I get a dumbed down version, LOL.
How is this different then a Scene?
I read somewhere that it should be faster (which isn’t my problem turning things off) But how?
Does it still send all off commands even if the device is already off? Is this a bad thing?

I currently use a Multiswitch and PLEG to shut down lights under the action and also to check for garage door open and gate open to only send a on/off command (since only has one button for both) to the gate and garage door if they are open. But the other 50 so devices I send an off command. Seems like a waist if 90% of them are already off. But I don’t want to write PLEG for each one to check and only send if ON.

Is it a bad thing to send off commands to 50 devices? How is the above plugin/switch help?