I have a couple of Z-Wave temperature sensors in my house that are battery operated and so spend most of their time sleeping. When they’re sleeping they will occasionally wake up to send new readings to Home Assistant, but won’t check to see if their configuration parameters have been changed.
However, I want to change their parameters over the course of the day: I want them to be more sensitive to temperature changes during the day, and less sensitive at night (in order to save battery power and get readings when I really care about them).
To accomplish this, I put four things together:
- First, I used old-style groups to create two groups: one static list of the target devices I want to keep updated, and one dynamically populated list of the target devices that actually have updates pending.
- I used the awesome custom scheduler component and custom scheduler card to call a script with different parameters at certain times according to the schedule.
- I used that script to iterate over the target Z-Wave devices, setting their parameters and adding them to the pending updates group to indicate that they need to be updated.
- I used an automation that triggers when the Z-Wave devices report a measurement. The automation pings them before they go back to sleep, thereby causing them to check in and retrieve their new parameters. (And of course, then the automation removes them from the pending updates group.)
The details are rather long and complicated for a forum post, so I wrote it all out in great detail on my blog.
The result isn’t terribly modular, but it should be a good example/guide on how to do this generally for others who want a similar setup.
Any thoughts/comments/suggestions are welcome! Bonus points if you can figure out how to combine all of this down to a single AppDaemon script or make it into a Blueprint. 
1 Like
Pinging a battery node has no effect. Since it’s sleeping, it won’t receive the command. The battery powered nodes will only wake up according to their wake up interval, or if you physically wake them.
That’s definitely true in general, but at least with these particular Z-Wave devices they apparently stay awake for a second or two after they report a measurement.
That’s where the automation comes in–it triggers when they report a measurement, and manages to ping them before they have a chance to go to sleep again. (At least with these particular devices, they respond to the ping and get their configuration parameters before going back to sleep, too.) The automation also tells them how long to wait before another forced wake-up, based on the next time the schedule says the parameters should change.
So there is a “Wake up on demand” functionality for newer devices that supports waking up the device to send commands (e.g. configuration settings), using the Supervision CC. If the device is reporting with Supervision CC, the driver can wake it immediately. The aerq sensors are new 700-series devices, so they very well could be using that. The driver debug logs should show that, do you happen to observe that?
Either way, the ping seems superfluous. Do you see it actually making a difference?
I haven’t seen the Supervision CC, but maybe I’m missing it? Here are the logs for when the sensor checks in (as scheduled), the automation triggers a ping, Home Assistant sends the new parameters to the node, and the node goes back to sleep:
Subscribed to Z-Wave JS Log Messages…
2022-07-04T19:04:28.876Z SERIAL « 0x010c00040015063105012a02ab52 (14 bytes)
2022-07-04T19:04:28.881Z CNTRLR [Node 021] [Multilevel Sensor] Air temperature: metadata updated [Endpoint 0]
2022-07-04T19:04:28.885Z CNTRLR [Node 021] [~] [Multilevel Sensor] Air temperature: 68 => 68.3 [Endpoint 0]
2022-07-04T19:04:28.888Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:28.890Z DRIVER « [Node 021] [REQ] [ApplicationCommand]
└─[MultilevelSensorCCReport]
type: Air temperature
scale: Fahrenheit
value: 68.3
2022-07-04T19:04:28.897Z SERIAL « 0x010c000400150631050502004295 (14 bytes)
2022-07-04T19:04:28.898Z CNTRLR [Node 021] [Multilevel Sensor] Humidity: metadata updated [Endpoint 0]
2022-07-04T19:04:28.900Z CNTRLR [Node 021] [~] [Multilevel Sensor] Humidity: 65 => 66 [Endpoint 0]
2022-07-04T19:04:28.902Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:28.903Z DRIVER « [Node 021] [REQ] [ApplicationCommand]
└─[MultilevelSensorCCReport]
type: Humidity
scale: Percentage value
value: 66
2022-07-04T19:04:28.916Z SERIAL « 0x010c000400150631050b2a0235c6 (14 bytes)
2022-07-04T19:04:28.918Z CNTRLR [Node 021] [Multilevel Sensor] Dew point: metadata updated [Endpoint 0]
2022-07-04T19:04:28.920Z CNTRLR [Node 021] [~] [Multilevel Sensor] Dew point: 57 => 56.5 [Endpoint 0]
2022-07-04T19:04:28.922Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:28.925Z DRIVER « [Node 021] [REQ] [ApplicationCommand]
└─[MultilevelSensorCCReport]
type: Dew point
scale: Fahrenheit
value: 56.5
2022-07-04T19:04:28.998Z CNTRLR » [Node 021] pinging the node...
2022-07-04T19:04:29.012Z SERIAL » 0x0108001315010025895c (10 bytes)
2022-07-04T19:04:29.017Z DRIVER » [Node 021] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 137
└─[NoOperationCC]
2022-07-04T19:04:29.020Z SERIAL « [ACK] (0x06)
2022-07-04T19:04:29.033Z SERIAL « 0x0104011301e8 (6 bytes)
2022-07-04T19:04:29.035Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:29.038Z DRIVER « [RES] [SendData]
was sent: true
2022-07-04T19:04:29.043Z SERIAL « 0x010700138900000361 (9 bytes)
2022-07-04T19:04:29.048Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:29.053Z DRIVER « [REQ] [SendData]
callback id: 137
transmit status: OK
2022-07-04T19:04:29.065Z CNTRLR [Node 021] The node is now awake.
2022-07-04T19:04:29.093Z CNTRLR « [Node 021] ping successful
2022-07-04T19:04:29.098Z SERIAL » 0x010c001315057004010102258a29 (14 bytes)
2022-07-04T19:04:29.100Z DRIVER » [Node 021] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 138
└─[ConfigurationCCSet]
parameter #: 1
reset to default: false
value size: 1
value format: UnsignedInteger
value: 2
2022-07-04T19:04:29.106Z SERIAL « [ACK] (0x06)
2022-07-04T19:04:29.111Z SERIAL « 0x0104011301e8 (6 bytes)
2022-07-04T19:04:29.113Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:29.115Z DRIVER « [RES] [SendData]
was sent: true
2022-07-04T19:04:29.123Z SERIAL « 0x010700138a00000263 (9 bytes)
2022-07-04T19:04:29.125Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:29.127Z DRIVER « [REQ] [SendData]
callback id: 138
transmit status: OK
2022-07-04T19:04:29.145Z SERIAL » 0x010c001315057004030102258b2a (14 bytes)
2022-07-04T19:04:29.147Z DRIVER » [Node 021] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 139
└─[ConfigurationCCSet]
parameter #: 3
reset to default: false
value size: 1
value format: UnsignedInteger
value: 2
2022-07-04T19:04:29.152Z SERIAL « [ACK] (0x06)
2022-07-04T19:04:29.155Z SERIAL « 0x0104011301e8 (6 bytes)
2022-07-04T19:04:29.156Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:29.157Z DRIVER « [RES] [SendData]
was sent: true
2022-07-04T19:04:29.171Z SERIAL « 0x010700138b00000262 (9 bytes)
2022-07-04T19:04:29.172Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:29.174Z DRIVER « [REQ] [SendData]
callback id: 139
transmit status: OK
2022-07-04T19:04:29.191Z SERIAL » 0x010d00131506700404028bcf258c6d (15 bytes)
2022-07-04T19:04:29.193Z DRIVER » [Node 021] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 140
└─[ConfigurationCCSet]
parameter #: 4
reset to default: false
value size: 2
value format: UnsignedInteger
value: 35791
2022-07-04T19:04:29.200Z SERIAL « [ACK] (0x06)
2022-07-04T19:04:29.209Z SERIAL « 0x0104011301e8 (6 bytes)
2022-07-04T19:04:29.211Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:29.214Z DRIVER « [RES] [SendData]
was sent: true
2022-07-04T19:04:29.219Z SERIAL « 0x010700138c00000265 (9 bytes)
2022-07-04T19:04:29.221Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:29.223Z DRIVER « [REQ] [SendData]
callback id: 140
transmit status: OK
2022-07-04T19:04:30.155Z SERIAL » 0x010a00131503700501258d2c (12 bytes)
2022-07-04T19:04:30.157Z DRIVER » [Node 021] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 141
└─[ConfigurationCCGet]
parameter #: 1
2022-07-04T19:04:30.160Z SERIAL « [ACK] (0x06)
2022-07-04T19:04:30.165Z SERIAL « 0x0104011301e8 (6 bytes)
2022-07-04T19:04:30.166Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:30.168Z DRIVER « [RES] [SendData]
was sent: true
2022-07-04T19:04:30.181Z SERIAL « 0x010700138d00000264 (9 bytes)
2022-07-04T19:04:30.182Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:30.184Z DRIVER « [REQ] [SendData]
callback id: 141
transmit status: OK
2022-07-04T19:04:30.196Z SERIAL « 0x010b0004001505700601010294 (13 bytes)
2022-07-04T19:04:30.199Z CNTRLR [Node 021] [~] [Configuration] 1: 2 => 2
2022-07-04T19:04:30.200Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:30.202Z DRIVER « [Node 021] [REQ] [ApplicationCommand]
└─[ConfigurationCCReport]
parameter #: 1
value size: 1
value: 2
2022-07-04T19:04:30.215Z SERIAL » 0x010a00131503700503258e2d (12 bytes)
2022-07-04T19:04:30.217Z DRIVER » [Node 021] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 142
└─[ConfigurationCCGet]
parameter #: 3
2022-07-04T19:04:30.220Z SERIAL « [ACK] (0x06)
2022-07-04T19:04:30.225Z SERIAL « 0x0104011301e8 (6 bytes)
2022-07-04T19:04:30.226Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:30.229Z DRIVER « [RES] [SendData]
was sent: true
2022-07-04T19:04:30.243Z SERIAL « 0x010700138e00000267 (9 bytes)
2022-07-04T19:04:30.244Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:30.247Z DRIVER « [REQ] [SendData]
callback id: 142
transmit status: OK
2022-07-04T19:04:30.253Z SERIAL « 0x010b0004001505700603010296 (13 bytes)
2022-07-04T19:04:30.255Z CNTRLR [Node 021] [~] [Configuration] 3: 2 => 2
2022-07-04T19:04:30.257Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:30.259Z DRIVER « [Node 021] [REQ] [ApplicationCommand]
└─[ConfigurationCCReport]
parameter #: 3
value size: 1
value: 2
2022-07-04T19:04:30.271Z SERIAL » 0x010a00131503700504258f2b (12 bytes)
2022-07-04T19:04:30.273Z DRIVER » [Node 021] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 143
└─[ConfigurationCCGet]
parameter #: 4
2022-07-04T19:04:30.276Z SERIAL « [ACK] (0x06)
2022-07-04T19:04:30.280Z SERIAL « 0x0104011301e8 (6 bytes)
2022-07-04T19:04:30.281Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:30.283Z DRIVER « [RES] [SendData]
was sent: true
2022-07-04T19:04:30.296Z SERIAL « 0x010700138f00000266 (9 bytes)
2022-07-04T19:04:30.297Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:30.299Z DRIVER « [REQ] [SendData]
callback id: 143
transmit status: OK
2022-07-04T19:04:30.309Z SERIAL « 0x010c0004001506700604028bcfd0 (14 bytes)
2022-07-04T19:04:30.312Z CNTRLR [Node 021] [~] [Configuration] 4: 35791 => 35791
2022-07-04T19:04:30.313Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:30.316Z DRIVER « [Node 021] [REQ] [ApplicationCommand]
└─[ConfigurationCCReport]
parameter #: 4
value size: 2
value: 35791
2022-07-04T19:04:31.321Z CNTRLR » [Node 021] Sending node back to sleep...
2022-07-04T19:04:31.340Z SERIAL » 0x01090013150284082590cb (11 bytes)
2022-07-04T19:04:31.342Z DRIVER » [Node 021] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 144
└─[WakeUpCCNoMoreInformation]
2022-07-04T19:04:31.344Z SERIAL « [ACK] (0x06)
2022-07-04T19:04:31.350Z SERIAL « 0x0104011301e8 (6 bytes)
2022-07-04T19:04:31.351Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:31.353Z DRIVER « [RES] [SendData]
was sent: true
2022-07-04T19:04:31.358Z DRIVER « [RES] [SendData] [unexpected]
was sent: true
2022-07-04T19:04:31.359Z DRIVER unexpected response, discarding...
2022-07-04T19:04:32.351Z CNTRLR Failed to execute controller command after 1/3 attempts. Scheduling next try i
n 100 ms.
2022-07-04T19:04:32.457Z SERIAL » 0x01090013150284082590cb (11 bytes)
2022-07-04T19:04:32.459Z DRIVER » [Node 021] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 144
└─[WakeUpCCNoMoreInformation]
2022-07-04T19:04:32.734Z SERIAL « [ACK] (0x06)
2022-07-04T19:04:32.745Z SERIAL « 0x0104011301e8 (6 bytes)
2022-07-04T19:04:32.748Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:32.751Z DRIVER « [RES] [SendData]
was sent: true
2022-07-04T19:04:40.787Z SERIAL « 0x01070013900103255c (9 bytes)
2022-07-04T19:04:40.789Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:40.792Z DRIVER « [REQ] [SendData]
callback id: 144
transmit status: NoAck
2022-07-04T19:04:40.803Z CNTRLR [Node 021] The node did not respond after 1 attempts. It is probably asleep, m
oving its messages to the wakeup queue.
2022-07-04T19:04:40.804Z CNTRLR [Node 021] The node is now asleep.
2022-07-04T19:04:42.853Z SERIAL « 0x01070013900103f48d (9 bytes)
2022-07-04T19:04:42.856Z SERIAL » [ACK] (0x06)
2022-07-04T19:04:42.859Z DRIVER « [REQ] [SendData]
callback id: 144
transmit status: NoAck
2022-07-04T19:04:42.864Z DRIVER handling request SendData (19)
2022-07-04T19:04:42.867Z DRIVER no handlers registered!
When I change a parameter when the node is just asleep, nothing shows up in the logs.
And yes, if I change a parameter and then omit the ping (and wait for the node to report a measurement), then I can verify that the configuration settings don’t change. The logs look similar, except everything after the line CNTRLR » [Node 021] pinging the node... is absent.
No, your device is not using Supervision, so the “wake up on demand” functionality isn’t involved.
So I was actually able to reproduce your scenario myself, by luck. Speaking with the Z-Wave JS developer, this behavior is unexpected, and he doesn’t think all devices behave this way. So, as you said, it would seem there are some devices that will awake fully when they report values, since that’s the only explanation (there’s always something new to learn about Z-Wave, which is why I’m asking these questions!).
Something that threw me off was that your device also sends temp/humidity reports during its wake up routine. That could have been an explanation, but your logs are not showing a Wake Up Notification.
The driver will not attempt to set config parameters when receiving a sensor report, because it is not expected that the device is awake. By sending the ping and getting a response, it causes the driver to recognize that the device is awake, and it processes any messages that are pending in its wake up queue, such as setting config parameters.
One thing that still confuses me, your log is showing two pings: one right after the sensor reports and before the config parameters are set and the second is at the end after setting the config parameters. Where does that first ping come from? I don’t see it in the automation you posted. The last ping does nothing, as the log message indicates. Ping commands are not queued. It’s the first ping that makes this work.
The driver will not attempt to set config parameters when receiving a sensor report, because it is not expected that the device is awake. By sending the ping and getting a response, it causes the driver to recognize that the device is awake, and it processes any messages that are pending in its wake up queue, such as setting config parameters.
Precisely–and to be honest, I half expected I was taking advantage of some undocumented accidental behavior.
That first ping is the very last action in the automation sequence
- service: zwave_js.ping
target:
device_id: '{{ trigger.device_id }}'
I don’t know where that last ping (WakeUpCCNoMoreInformation) comes from either. I assume it’s just the driver telling the node there’s no more information and it can go back to sleep, but I’m not sure why it’s waiting for a response. Maybe it’s a bug?
Ah, there isn’t a second ping, not sure where I got that from. Yes, the last failed command is the WakeUpCCNoMoreInformation message which tells the node to go to sleep right now (saves battery). Either the node already went to back sleep on its own, or it just ignored the message because it never sent a wake up notification message in the first place.
I think the ordering of the service calls was confusing me. You have the ping call after setting the config parameter. In the logs, the ping is first. What’s probably happening is that the set config parameter commands are (silently) queued because the device appears asleep. The ping has a high priority and is sent right away, before the queued messages are. Once the awake state is handled, it sends the queued commands.
Interesting scenario!
Also I was diving even more into the diagnostics for my Aerq sensors (via Settings > Devices > [the device] > three-dot menu in the “Device info” card > Download diagnostics), and it looks like these devices do indeed support the SupervisionCC. E.g. the following was in the diagnostics:
{
"id": 108,
"name": "Supervision",
"version": 1,
"isSecure": false
},
I can’t find any documentation on how I’d use it, though. I tried using the zwave_js.invoke_cc_api service, but I just don’t know what parameters to put in. (I managed to figure out that the command_class should probably be 108 and the method name should probably be either sendEncapsulated or sendReport, but I’m lost after that.)
You usually (not always) have to include it with S2 Security. Based on the logs, you’ve included without security. Or, maybe it just doesn’t use it… It’s not something you would control, unless by configuration parameter.
Example:
2022-07-05T00:15:43.995Z SERIAL « 0x012200a8000128199f03d100f12659a33e79b01ca76a334ca2d6e43bf97aeff2a (36 bytes)
a00c221
2022-07-05T00:15:43.997Z CNTRLR [Node 040] [~] [Notification] notificationMode: "push" [Endpoint 0] [internal]
=> "push"
2022-07-05T00:15:43.999Z SERIAL » [ACK] (0x06)
2022-07-05T00:15:44.001Z DRIVER « [Node 040] [REQ] [BridgeApplicationCommand]
│ RSSI: -62 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 209
└─[SupervisionCCGet]
│ session id: 5
│ request updates: false
└─[NotificationCCReport]
notification type: Access Control
notification status: 255
notification state: Window/door is open
2022-07-05T00:15:44.003Z CNTRLR [Node 040] [~] [Notification] Access Control[Door state]: 23 => 2 [Endpoint 0]
2
2022-07-05T00:15:44.021Z SERIAL » 0x011d00a90128119f03d900d4192da868e437533a78d1caf82500000000fbe9 (31 bytes)
2022-07-05T00:15:44.021Z DRIVER » [Node 040] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 251
└─[Security2CCMessageEncapsulation]
│ sequence number: 217
└─[SupervisionCCReport]
session id: 5
more updates follow: false
status: Success
duration: 0s
It allows the sensor to know that the application software received the command. For my smoke alarms, this allows the alarm to retry multiple reports if needed, to ensure the alarm is received.
The engineering doc for the AërQ sensor says it supports Wake Up CC V2, which does not support “wake up on demand”. Switching to S2 Security could affect the timing of things.