I'd like to change the wake up interval on my Zooz ZSE29 outdoor motion sensor.
The manual says:
"The sensor’s wake-up interval is set to 4 hours by
default to save battery life. Use the Wake Up Command
Class to adjust the interval (in seconds, working in 600s
intervals, with 600 as min and 86400 as max values)."
On my unit, the actual wake up interval seems to be 12 hours (43200 seconds).
I've done parameters, but no actual z-wave commands.
The driver is possibly setting that. The golden standard for Hubitat seems to be 12 hours and some drivers will set it when the device is configured.
You might be able to change it, and the driver may or may not change it back at some point.
If you use PC Controller, you can build the command in there and then copy and paste the hex string to the "Advanced" input box hidden on the device page.
You would also want to send a get after setting it, to confirm it took.
You will need to wake the device up right before you send it as well.
Otherwise, this is something I wanted to add to my zwave scanner / toolbox driver. I also want to make it detect a battery device and then queue up commands so you can get stuff ready then wake it up afterwards. Not sure when that will happen though.
Is there some sort of button on it for joining excluding etc..usually pushing this will get the device to wake up. Or try removing and reinserting the battery.
To add to the above, is there a reason you want to do this? I'm sure you're aware that it doesn't impact normal operation of the device, only listening for commands from the hub, which would be unusual for a sensor-only device.
The question (topic title aside) is how to set the wakeup interval, which this won't change.
I think the device tip was a good one.
I found 43200 in the advanced driver I was using and changed it to the minimum, 600.
I'm waiting 10 minutes now to see if it wakes up and reports on battery.
My genius plan is to plug this into the TalentCell battery which is backing up the hub to check on the battery. Too low, then shut down hub.
Of course, it uses precious power, lol. Even if it would work.
I've had the hub (only) on the TalentCell since 9 pm, and it's still showing all the lights lit.
We had a two hour power outage earlier today, and the hub worked excellent. Sequence was (propane conservation-I'm cheap in some ways): Power out-standby gen on-power out- portable gen on-power out-utility power on. If the hub were to be powered down and up that number of times, something would've gotten corrupted, I bet. So, backup is worthwhile.
From looking at the logs under normal operation, I think it only sends battery % reports when it wakes up. Will it send a battery report if it gets low? I have no idea. There's no mention of it.
Maybe get a ring extender to report more reliably or one of these if in usa.
When I'm home, I know when the power goes out, lol.
However, when I'm running on the portable generator I wouldn't know if utility power came back, unless I heard the snap of the transfer switch.
So, what I did this morning was to hook up an Ecolink contact switch to an end switch in the transfer switch. Closed=utility, Opened=generator. It went to Closed and I got a notification and an ordinarily unused light went on. Hubitat for the win, lol.
same idea as the above kit.. it is basically an ecolink with a plug.
FWIW, any commands you want to send to a sleeping Z-Wave device can be sent while the device is asleep; they get queued in the Z-Wave controller so you don't need to wake it up first. If you do manually awaken it (either by activating its sensor or by pushing a button if it has one), you must do it within (at least) 10 seconds or it will return to sleep.
Otherwise when a sleeping Z-Wave device awakens on its own (due to a reportable event like motion or contact, or due to its preconfigured wakeup interval) it sends a notification to the controller telling it that it's awake and able to receive commands. If it woke up because it had an unsolicited event to report, it would send that info first, then stay awake to listen for whatever the controller needs to send it.
Normally after the controller sends queued commands it will send a 'Wake up No More Info' command (gotta love the backwards Z-Wave terminology) telling the device that it can return to sleep; if the device doesn't hear anything after 10 seconds has elapsed, it will return to sleep anyway.
Do some battery powered devices break out of the pre-arranged wake up interval to report on a low battery?
I'm sure it depends on the device but it would make sense to send battery reports at periodic intervals (though it may not be necessary to send them more frequently than the wakeup interval).
I'm not sure what Z-Wave does at the hub level (on any hub/controller), but on Hubitat, this queuing is recommended to be implemented as a driver function (i.e., something that listens for the Wake Up Notification from the device, sends whatever is pending, and then sends Wake Up No More Info). I don't think I've actually seen it work any other way, e.g., if you try the Basic Z-Wave Tool to set a parameter and don't wake the device up first (though I'm guessing Z-Wave itself will retry for a relatively short time).
Maybe this is what you meant--just wanted to clarify that it may depend on the driver, even if any well written driver should make the difference immaterial.
Agreed, I believe you have to implement the queueing at the driver, the hub does not queue commands for a battery device AFAIK, it just fires them out into the void.
True; if the driver didn't implement queueing it could be a horserace in some scenarios to manually activate a device and ensure sure the command gets sent within the 10 second window (which seems to be a spec requirement for non-FLIRS devices).
My take on all this comes from this SiLab's doc Z-Wave Sleeping Nodes - latest - Z-Wave Silicon Labs based on the description of how 'Reporting Sleeping Slaves' operate. It does describe a 'Mailbox' service providing the queuing function but says it's part of the 'Z/IP Gateway reference design' so probably isn't considered a base function (in which case the driver would need to support it).
Like most things Z-Wave, figuring out how it works seems to be best done by experimentation...
Well, it's been 48 hours on battery only. A little while ago, z-wave routines weren't working. Zigbee fine. Nothing strange on Hub Info. Unplugged the motion sensor, worked fine again. Kind of shows the fragility of these things. Still have 3 of 4 lights lit on the TalentCell. USB output reads 5.08 volts. Restored driver to original. Excluded the test motion sensor. I'm going to let this thing run until it dies. I'll just look at the voltage manually once in a while.
60 hours on battery only, including those 15 hours with the now-disconnected motion sensor. Still at 5.09 volts and 3 of 4 leds lit on the TalentCell. Automations running normally.
Well, it's been 3 days, 5.08 v, 3 of 4 leds.
3.5 days. 2 of 4 leds lit now. 5.09v.