All devices on Vera, be they Z-Wave or otherwise, are based around services, and services define behavior (actions you can perform on the device) and data (state variables containing persistent data about the device). For example, pretty much any switch that is capable of on/off, whether it’s Z-Wave or ZigBee or WiFi or just virtual, and whether it’s a dimmer or just a plain switch, implements the “SwitchPower1” service (short for it’s full ID urn:upnp-org:serviceId:SwitchPower1. That service defines a SetTarget action which you can use to turn the switch on and off. It also defines two variables, Target which is the goal state for the device, and Status is the last known state of the device. When you want to turn a switch on (such as when you flip the control in the Vera UI), a SetTarget action is sent to the Vera device, which generally does two things: set the Target variable to the target given in the action, and send the command to the device to go to the right target state. At some later point, the device responds or is polled and its status is fetched, and hopefully its status is then the same as the goal/target state.
The point of this is that all switches that can do on/off are treated exactly the same way in Vera–you send a SetTarget action to the Vera device. The device implementation, the driver if you will, figures out what needs to be done to make that happen. If it’s a Z-Wave device, Z-Wave commands will be generated. If it’s WiFi, it may issue a request to an API or send a packet on a socket already opened. But it doesn’t matter to you. All you need to know is that you called the SetTarget action.
So, in Reactor, you have Acitivities, and specifically there you will find “Device Action” actions. When you create a Device Action, you first choose a device. Once it knows what device you are targeting, Reactor will populate the action list with all of the defined actions that device supports. You then need to choose the right one, and provide any additional arguments. Some well-known actions have simplified interfaces. For example, when you select a switch for a Device Action, you’ll see a “Turn on/off” action to choose at the top of the menu–you don’t need to know anything about what service it’s in. Below the “common” actions are all of the possible actions, so the list is comprehensive for the device.
And in this way, Reactor communicates with Z-Wave and non-Z-Wave devices in the same way, without any need for it, or you, to differentiate. As my old mentor used to say “don’t tell it, it won’t know.”
As for the Alexa question, the only way Reactor would know anything about an Alexa command is it would see the commanded light’s state changing. It would not know why. This is a limitation of Luup–when you watch a device, it will tell you it’s changing, but not why/what caused it.
