We have an ACT HomePro ZTH200 Z-Wave Remote Controller.
This device is capable to send an All-ON or All-OFF command to the entire Z-Wave network.
The response from the Z-Wave network is almost immediately, within 1 second all devices configured to join the All-OFF and/or All-OFF turn on or off.
Even the devices, the Remote doesn’t know they exist, respond to the All-ON or All-OFF.
In the manual for the Fibaro Double Relay Switch it says that the All-ON or All-OFF is usually initiated by a Remote Control, using a system wide command.
For the Vera we use a Scene to turn all the wanted devices on or of at once, but this is slow, turning the devices on or off one by one, sometimes even “forgetting” to switch a particular device.
Would it be possible to have Vera initiate the system wide All-ON or All-OFF like the Remote does?
So it looks it would be possible using SendData from Lua or so.
From the http://wiki.linuxmce.org I copied the data strings send by the ZTH200 to initiate an All-ON or a All-OFF:
Pressing “all units on” on the ZTH200:
41 03/28/08 15:50:58.553 0x1 0x8 0x0 0x4 0x4 0xef 0x2 0x27 0x4 0x39 (#######‘#9) <0xb70f4b90>
41 03/28/08 15:50:58.854 0x1 0x8 0x0 0x4 0x0 0xef 0x2 0x27 0x4 0x3d (#######’#=) <0xb70f4b90>
What are the parameters for SendData? Where is it documented?
From the zwave spec:
3.4.5 All Switch Off Command
The All Switch Off Command can be used to inform a switch that it should be turned off.
7 6 5 4 3 2 1 0
Command Class = COMMAND_CLASS_SWITCH_ALL
Command = SWITCH_ALL_OFF
From the LinuxMCE wiki:
All the known classes
...
COMMAND_CLASS_SWITCH_ALL 0x27
...
Seems that SWITCH_ALL_OFF is 0x04, and SWITCH_ALL_ON is 0x05, then.
void SwitchAll::Off
(
)
{
Log::Write( "SwitchAll::Off (Node=%d)", GetNodeId() );
Msg* msg = new Msg( "SwitchAllCmd_Off", GetNodeId(), REQUEST, FUNC_ID_ZW_SEND_DATA, true );
msg->Append( GetNodeId() );
msg->Append( 2 );
msg->Append( GetCommandClassId() );
msg->Append( SwitchAllCmd_Off );
msg->Append( TRANSMIT_OPTION_ACK | TRANSMIT_OPTION_AUTO_ROUTE );
GetDriver()->SendMsg( msg );
}
We have the data; we just need to know hot to send it in LuaUPnP.
Copy with pride, see the [tt]DSS[/tt] source code … Be warned that there is no elegant way to catch the Z-Wave response message(s). [tt]SendData[/tt] should use a callback handler to return the Z-Wave response messages to the caller.
Combining the DSS source code and this reference: http://wiki.micasaverde.com/index.php/ZWave_Debugging (see “-Luup update”)
you don’t need a node id, and this should work, to set node 5 to 20% (suspect that’s a typo for 50% actually):
I should stop being such a lazy troll and actually read through the z-wave docs to see what the different bytes are. I know 0x13 is for “send data”, followed by the ID of the node, then 0x3 0x26 for Command Class 0x26, 0x1 for set level, followed by the level. I’m not sure about the initlal zero, or the 4 and the 1 following.
EDIT: oh, verbose logging. Never thought of that. Let me see if that tells me anything.
41 01/13/12 17:20:26.937 0x1 0xa 0x0 0x13 0x5 0x3 0x26 0x1 0xa 0x4 0x1 0xc8 (#\n####&#\n###) <0x2b68f680>
42 01/13/12 17:20:26.975 0x6 (#) <0x2ba8f680>
42 01/13/12 17:20:26.976 got ACK -- not expected send: (nil) exp -1 got -1 <0x2ba8f680>
I’m guessing that 0x1 0xa ss some kind of routing, and 0xc8 is the checksum. Not sure what else that tells me.
Have to use the raw Data=‘…’ form; presumably there’s some nodeID validation when using Node=‘…’, Data=‘…’.
Apparently (but perhaps not surprisingly) [tt]0xff[/tt] is the broadcast node address, not [tt]0xef[/tt] as the ZTH200 trace suggests?
Have to prepend ‘[tt]0 0x19[/tt]’ when using the raw form, not ‘[tt]0 0x13[/tt]’ as the wiki suggest. ([tt]0x13[/tt] is the [tt]SendData[/tt] API, but by using the [tt]SendData[/tt] Luup call, I think that’s not what you need to provide. The [tt]0x19[/tt] is taken from other outbound Z-Wave comms tracing.)
The reason I’m this “optimistic” is because the SendData action expects the node ID as the input.