General Category > Ideas/Feature requests
Websocket sensors?
bear9rpp:
websocket version as in websocket variant, or websocket equivalent.
I understand we cannot have all kinds of sensors because I too agree it is an overkill. Only general support is needed, and I agree a binary device is a good start and likely covers 80% of the use cases
I was using temperature as an example, I'm basically looking for a way to report a readout from a virtual device, that's all. I understand there are existing temp sensors out there, but if I have a RaspPi temp sensor node, I can communicate back to Almond as a virtual device and have it considered as part of the rule set. (I know that with a bit of translation logic on the Pi side, the same can be done by interpreting the temp locally and communicate back to Almond as a binary device)
SecureComp:
ok, now I think I understand what you want, thanks
matt:
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.
SecureComp:
Basic answer is yes.
The creating of the device definition is straightforward enough.
There has to be an additional identifier to key the I/O a different route.
It's the I/O which is the big deal and requires not insignificant effort on the part of Securifi to route appropriately.
And no, you'd need that all ACK NACK thing working, can't blow it off imho.
But there's more than one way to skin a cat.
In fact, if I were doing the initial s/w dev, I'd have had a debug option to check messaging before handing off to the zigbee/zwave stuff. And if i had that I'd dump it to a file and processing file is no big deal...just saying. 8)
d.kiran:
--- Quote from: SecureComp on June 01, 2016, 11:32:25 pm ---In fact, if I were doing the initial s/w dev, I'd have had a debug option to check messaging before handing off to the zigbee/zwave stuff. And if i had that I'd dump it to a file and processing file is no big deal...just saying. 8)
--- End quote ---
I would think Securifi already has this part. Debugging stuff like routing and messaging is difficult if you don't have the ability to stub out either endpoints.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version