General Category > Ideas/Feature requests
Sensor Polling or Negative Response
multisystemelectronics:
A remote sensor is coupled to the host object and adapted to detect a target object... :)
d.kiran:
--- Quote from: SecureComp on January 05, 2016, 04:52:31 pm ---In fact, with the SDK or the new WS API, pretty easy to do. It will be a battery killer, but it will work. Can even set an adjustable polling interval.
--- End quote ---
@SecureComp, how do you use the WS API to poll a device though? I see only GetDeviceIndex and that gets it from the Almond not the device itself.
rpr69:
--- Quote from: d.kiran on May 31, 2016, 12:09:06 am ---@SecureComp, how do you use the WS API to poll a device though? I see only GetDeviceIndex and that gets it from the Almond not the device itself.
--- End quote ---
Same here, I've read the API pretty closely, and I don't see the capability to poll a device directly.
SecureComp:
Think of it as "virtual" polling.
Naturally you'll be getting the response from the Almond, you're communicating at the application level.
No you won't talk directly to the device but you can throw something at the device and get an expected response. The info will vary from device to device obviously. Think of it as a PING ECHO RESPONSE REQUESTED kind of thing. Now what you throw at the device will matter.
For example, if you want the status of a Light that is On, you can't just check and see if the light is on as reported by the Almond. You would send a DIM adjustment level to lower it 1%, no real impact on your lighting situation, and you should see an INDEX of the MULTI LEVEL SWITCH transition from 255 to xxx. That confirms the communication from the Almond to the device and from the device back to the Almond. So you have to actually ask a device to do something or do something to the device as the case may be.
Other devices, such as the Home Energy Monitoring systems have configurable reporting features and regularly report power stats and you can kick an exception is there hasn't been a report over a given time.
Splunk really helps you analyze logs and events to get a look at what's happening but you can also just watch the sockets on the Almond via a web browser to get an idea.
So how about a specific request from your end. What device would you like to poll and how often? If I happen to have that device, I'll walk you through the process. I have CREE light bulbs which is an easy thing because you can set the DIM level without toggling the State of the device. I have about a dozen or so of other types of devices.
Now if you want to go low level and actually watch the ZWave or Zigbee comms, that's more of a challenge but doable. Much easier to do off the Almond actually on a separate device like a Pi w/ a compatible radio and I'd set something up on GitHub for the effort.
SecureComp:
I'm thinking, based on the original topic of this thread, the primary concern is with the following types of devices;
Motion Detectors
Door/Window Sensors
Locks
Siren
Glass Break Sensor
The main issue with these devices is they are awake only during an event or during the standard wake up event that is programmed in the firmware and can be as much as 2 hours between wake ups.
But take a Door Sensor.
What about sending a Tamper FALSE message to the device as a virtual polling action. Not so great because what if it was Tampered? Well if it was, it should have reported it immediately or you have other issues. So your polling could first check the last recorded Tamper State and then send a Tamper False state. But does that message get sent to the device immediately or is it just queued and sent during the next comm initiated by the device itself either during the next event or the next wake up?
And of course there's the whole battery thing.
And it's not that simple. I shouldn't have picked the door sensor as an example because it is a binary switch. But go ahead and give me a list of sensor and I'll see what I can come up with.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version