Z-Wave Hook Question - Queued Commands?

Is there a Z-Wave hook that can be intercepted when a Z-Wave command is queued as a device is sleeping?

I would like to intercept a queued Z-Wave command when, for example, the Indigo UI is used to update a Thermostat set point.

[matt (support)]

Not currently, but let me think about how we might be able to expose that functionality.

Thanks. :

Matt, one suggestion that may resolve the need for QueuedCommand visibility... What I would like is to simply be notified when my battery powered Z-Wave devices are awake (primarily to my locks) so that my plugIn can send a command when the device is receptive for a command. I notice that sending a z wave command to a lock while it is sleeping stalls Z Wave communication for several seconds (for all devices it appears)... this causes me to miss (or delay) commands from motion sensors. I would be happy to queue my commands up myself and send them when I'm notified that the device is awake, or, if you could give us a method to send a z wave command to a device only when it is awake, you can queue them yourself - though I think the former is more flexible.

Option 1
Currently you detect wake condition when you have a device parameter update command waiting (I see this frequently on the motion sensors)... When you know the device has transitioned to wake, send an event to subscribed listeners to indicate the device being awake. We can have a deviceUpdated event that indicates the device is now awake (and also when it is asleep I suppose). This is my favorite option because I feel it is probably less impact on your side, and gives me greater control.

Option 2
Similarly, if you want to do the command queuing yourself, you can expose a flag as follows...
resultCode = indigo.insteon.sendRawExtended(self.theIndigoDevice.address, theCommand, waitUntilAck=atWake) # atWake flag as opposed to ackWait (or similar mechanism)
resultCode = indigo.insteon.sendRaw(self.theIndigoDevice.address, theCommand, waitUntilAck=atWake) # atWake flag as opposed to ackWait (or similar mechanism)

This is my less favored approach because it will cause us plug in developers to ask you to support queue control including dequeuing, ordering etc... the former way puts the burden on us, the plug in developers with probably less change on your end.


I can prototype this in an ugly way by requesting a meaningless parameter change request, then watch the log for its effect, then send my actual desired command at that time (assuming the device is awake for a few seconds), but I don't know how your code is structures and how much burden this would add to the system (so I won't). Currently, Im just living with the 30 second timeout (where motion sensors are delayed, or abandoned) while a command is trying to be delivered to a lock (that it will never receive).

I think this would be a great feature that resolves a number of battery powered device issues...

Unless, of course the very likely case that I am missing something obvious.

I thought most locks were FLiRS devices which means they aren't asleep in the same way a normal battery device is. This means they can respond almost instantly to a command from Indigo.

The Eurotronic Spirit thermostat is a FL1RS device and I have noticed tat occasionally that Indigo tales a few attempts before contact is made which can stall the Z-Wave network.

As I understand it, Indigo responds to a wakeup from a device instantly and as quickly as possible in order to put it to sleep again in order not to waste battery power. I think advising a plugin, and for the plugin to respond with the required commands would be too slow.

I still want to see the QueuedCommand visibility as it is requested.

Thanks for the info... I'll do some debugging - I verified that my Yale Z Wave locks support FLiRS protocol. I must have another problem in my network, inclusion, or a relay device... as I get 30 second Z Wave stall every time I even just click on the GetStatus button in Indigo. In a 12 core Mac Pro server.

Back to your original topic. I had the same need years ago, so I wrote my own plugin to manage my own command queue. I meter out one command at a time to indigo (for all of my 465 devices), wait for the command response event, take appropriate action based on good or bad result, then send the next command out. Since Im managing my own queue, I add subtract reorder and change my commands at will.

If you can't wait, I can share with you what I have done. I believe its as efficient as it can be while still being a plug in.

All that said... Like you, if command queue management features show up in Indigo, I would likely switch to the built-in methods for efficiency. So +1 on the queue Hook.

[jay (support)]

for all of my 465 devices

How's that? Z-Wave has a device limit of 232 devices...

re:
gsbrewer wrote:
for all of my 465 devices

How's that? Z-Wave has a device limit of 232 devices...
---

haha sorry... that is insteon switches, dimmers, and i/o controllers combined with z wave multi sensors and locks, plus a few nest thermostats for good measure.

Unfortunately, I provided all the detail in a previous draft, but when I hit submit, it sent me to login again, and upon return my draft was gone. The second version was much more terse - probably good for everyone's sake