Setting ZWave config params on battery powered devices

[gduprey]

Howdy,

 

I have a number of battery powered Zwave devices that require configuration parameters to be set or sometimes, view current values for verification.  Before I switched to the ISY, I was using a Vera and while there was little to love about it, it was very easy to see all custom config params and values, set the appropriate values and then just wake them up and the Vera would notice the params changed and program them all in.  The vera also kept a local copy of the most recent parameter so you could review them without having to query the device.

 

As much as I love the ISY, I find the process for setting the config parameters very cumbersome.  Having to switch the combo box for each param #, then query the device, then wake it up, then set a value, press Set and wake it up again to take effect for each parameter is complex and error prone.  

 

Do I really have to do this for each config parameter? 

 

More importantly, is there a way I can just set all of the config parameter values in the admin console and they use the 'Set' command once?  Or do I absolutely have to do the "set param #, press the query button, wake up the device, set the value, press the set button, wake up then device" and repeat that for each of the 12 different parameters I have to set for each of the 20 battery devices I have?

 

Just looking for a consistent and efficient way to set and verify these somewhat arcane parameter values.

 

Gerry

[cyberk]

I too have been having problems with config parameters. If you find a solution, please let me know

 

 

Sent from my iPhone using Tapatalk

[MWareman]

It would be useful to know the devices.

 

Devices (like locks etc) that support beaming should not need waking. Control only devices (like remotes) may be the biggest culprit here. I do agree, a better workflow for battery devices is needed (essentially allow changes to be queued and sent in a single wake).

[gduprey]

Generally climate sensors (temp & humidity).  They have a number of parameters that have to be set and you have to wake them up.
 

That said, even for things you do not have to wake up (like locks), the current "drop-down - query - value - set" process is still less than ideal - a form or sheet based method showing all current values, letting you edit some and then push them all would be ideal.

 

That said, just being able to batch up a bunch of changes and hit Set once to send them all over once the device is awake would be great!  

 

If I turn off the "write to battery devices" option and then make a bunch of changes to parameter values, will they'll all be queued to send when the "write to battery devices" button is turned on?

 

Gerry

[Chris Jahn]

Hi Gerry,

 

In the 4.x.x branch, you are limited to the Configuration parameter popup.  In the 5.0.X branch, you can now use program actions to set configuration parameters.  This way you can write a program containing all the parameters you want to update, and you just to need to wake up the device and run that program to update the device.

[gduprey]

Thanks for the update!

 

On a related note, if I use the REST interface to send a bunch of zwave config commands at once, will they properly queue up?  Or do I need to space out the REST commands to give time for each to complete?

 

My thinking right now (since I'm under 4.x for my main house) is to write a REST script to configure the devices (like my climate sensors, that have 6 parameters to configure), then run the script and right then, wake the device up.

 

Would that work?

 

Gerry

[Chris Jahn]

Hi Gerry,

 

Yes you can REST to do this.

 

Although the ISY processes one Z-Wave request at a time, it does not queue them.  Therefore, if you send a bunch of requests they will wait for others to finish or if it takes to long the pending requests will time out.

 

I sent these instructions to a customer recently, I thought I should share it here on the forum:

 

http://forum.universal-devices.com/topic/20049-setting-z-wave-configuration-parameters-using-your-browser-rest/

[gduprey]

Thanks -- that works.  Wrote a script that knows what settings I want for each type of device (climate, lock, thermostat, etc) and then either sets or gets params.  So run the command, wake up the device and it works reliably.

 

Gerry

[gduprey]

Hmm -- one thing I'm seeing is that the REST command to set a parameter value seems to return a status 200 "success" regardless of whether the device was successfully set or not.  In fact, I removed the batteries from a unit and sent the command and after a bit, it reported success (via REST).  Attempts to query the device did fail unless the device was woken up, but setting always "worked" (even when it didn't/couldn't).

 

Is there a bug in the REST stuff that assumes a /rest/zwave/node/config/set/[param]/[value]/ always works?

 

Gerry

[cyberk]

@gduprey , i have very little experience with the network module and what it can do. Would you mind chatting with me privately so that I can pick your brain? I'm thinking that using the module could solve some of my more complicated automation needs.

 

 

Sent from my iPhone using Tapatalk

[gduprey]

I don't mind helping out if I can, but honestly have rarely used the network module (though I have it).  I have a full-time linux server that interfaces with the ISY and bridges all my HA stuff together and use it to issue wget and other commands.  But again, I can certainly try -- it doesn't look that difficult to adapt things too.

 

Gerry

[Chris Jahn]

Hmm -- one thing I'm seeing is that the REST command to set a parameter value seems to return a status 200 "success" regardless of whether the device was successfully set or not.  In fact, I removed the batteries from a unit and sent the command and after a bit, it reported success (via REST).  Attempts to query the device did fail unless the device was woken up, but setting always "worked" (even when it didn't/couldn't).

 

Is there a bug in the REST stuff that assumes a /rest/zwave/node/config/set/[param]/[value]/ always works?

 

Gerry

 

The only foolproof way knowing the value changed to what you want is to query it right afterwards.  I'll add a low priority item to the list to add a 'verify' option on the Set, so that it immediately queries it and returns the values after it is set. 

[gduprey]

The only foolproof way knowing the value changed to what you want is to query it right afterwards.  I'll add a low priority item to the list to add a 'verify' option on the Set, so that it immediately queries it and returns the values after it is set. 

 

Hmmm - no way to even know if the ZWave set command was accepted?  The odd thing is the query command definitely detects not being able to contact the device.  It doesn't just return a bogus value, but a failed status when the device is not awake/alive and a value otherwise.  Set just always says it works - even when the target isn't even powered up.  

 

It would be nice if the set command reported failure if unable to contact device, recognizing that once you can contact the device, there is no way to prove the device actually stored the value short of querying it immediately after.  But at least at a high level, you'd know the device had a chance to work vs outright inaccessibility/failure.

 

Gerry

[mwester]

I have a suspicion that the issue here is that the REST command is more properly defined as a command to "submit" or "queue" the parameter change, rather than a command to actually perform the change -- thus the 200 response indicates only that your submission or request was accepted, but you'll have to check later to see the outcome.

 

I base my supposition on the fact that z-wave is a dongle-based solution, so the round-trip time to get the parameter submitted, and confirm receipt, and return a response could be very lengthy -- many seconds.  And as such, keeping the REST session active (in the face of many other ongoing connections and activities) can be very expensive, and not something commonly done for embedded devices.

 

An alternative solution might be to have the response include a unique key or ID that you could poll for later on to determine the success/fail of the request.  There would have to a time limit (so if you didn't poll, the ISY would be free to discard the key and its associated response data so as to free up memory.  I use a similar technique in parts of Polyglot where this same issue is encountered due to the async nature of the comms internally.

[gduprey]

Howdy,

 

Well, my experience with this so far is the REST commands stalls until it either times out or the set command completes.  For a timeout (worst case scenario), the REST command "hangs" until the approximately 15 second time-out occurs before returning.  I can see the ZWave activity and watch the logs to back this up.  

 

More importantly, since the set params ZWave commands are sent when you issue the REST command and they don't queue (per Chris's post earlier in the thread), the REST request has to be synchronous.  I've created scripts using this to set up to 12 parameters for a certain device and you can see them all execute in sequence -- each REST request completing in sync with the ZWave activity and then the next one being sent.

 

Finally, the query parameter command is also synchronous as you receive the result back when the command completes (either an error or the actual values).

 

So, all said, I'm pretty sure (empirically) that the REST commands for SET and QUERY are synchronous with the ZWave commands.  

 

As such, it should be possible to respond with a failure code if the SET request cannot be completed -- at least as a "target device never responded" (which is about all you can hope for).

 

Gerry

[mwester]

Ok - thanks for the details.  I retract my hypothesis!  

[Chris Jahn]

Hmmm - no way to even know if the ZWave set command was accepted?  The odd thing is the query command definitely detects not being able to contact the device. 

 

We can detect whether the message was received or not, but unless you do a query you don't know for sure if the value changed.  The reason you get a comm error on Query is we expect the value back (and if we don't its an error), but on Set we just expect the message to be sent.

 

I'll have a look, we should be able to report a comm error if the Set message didn't reach its target.