Isn't a device just a set of properties (like a struct basically)? It seems like it would be simple to be able to add a device in the same fashion as a devicelist. You could use existing devicetypes and devicevalue-types, or arguably create arbitrary ones (as a combination of any existing devicevalues).
{
"cmd":"adddevice",
"data":
{"devicename":"ContactSwitch #1","friendlydevicetype":"ContactSwitch","devicetype":"12","location":"Default","devicevalues":
{"1": {"index":"1","name":"STATE","value":"true"},"2":{"index":"2","name":"LOW BATTERY","value":"0"},"3":{"index":"3","name":"TAMPER","value":"true"}}}
}
or:
{
"cmd":"adddevice",
"data":
{"devicename":"BinarySwitch
#2","friendlydevicetype":"BinarySwitch","devicetype":"1","location":"Default","devicevalues":{"1":{"index":"1","name":"SWITCH BINARY","value":"true"}}}
}
For me, I basically want it to be a data store that interacts with rules/scenes and sends action notifications. I think the only thing that would be different would be it would be internally tagged as a "virtual" device, which instead of interacting with the zigbee/zwave stack, would send out the request on the websockets/sdk, and update values according to responses it received.
At the simplest level, it could just update the information store when a setdeviceindex action is presented (from A+ apps or WSs), and notify about the change, hoping that is actually done by the 3rd party connections in response to the notification. More complete would be to have a request/response WS/SDK API, e.g. "deviceindexrequest" and "deviceindexresponse" (not great names, but off the top of my head) where it would ask for the change to be made, and then receive confirmation that the change was made (as I assume happens internally with the zigbee/zwave stack).
But of course, having a virtual binary switch would be a great improvement on what is there now, this is just me giving a more full request than my multiple other feature requests for the same change.