Z-Wave the public standard

ZIP Gateway and a couple of nodes waking up but not working correctly



I’m implementing some software that uses the ZIP gateway. It’s working fine now for some nodes, but I have a couple of devices for which I do not get a wakeup notification. One of them is a wall controller with four switches, one of them is a motion sensor. I do get notifications from them, though, both button presses and alarms, also battery notifications. I use the wakeup notification to first learn the command class versions devices support, then to send ‘get’ (or whatever I have in the queue) packets to them.

Without the wakeup notification a good part of the functionality is not exposed (except what works through regular notifications) which is kind of bad :frowning:

I tried to ‘fake’ a wakeup by considering as a signal for wakeup also a battery notification (which I do receive, at least for one of the nodes). This does not work, apparently the node is back to sleep at the moment I receive the battery notification.

Here is a part of the zip gateway log which I consider relevant, from the moment the node (in this case, the wall controller - id 33) wakes up, it starts with the wakeup packet received by the gateway (but it’s not forwarded as other packets to my listener):

634511953 ApplicationCommandHandler 33->1 class 0x84 cmd 0x07 size 2
634511953 Node was last awake at 634511 the clock is 634511 the interval should be 4080
634511953 Wakeup notification received ahead of time
634511953 Sending 1->33, class: 0x84, cmd: 0x5
634511954 Sending with scheme 7
634511954 New sessions for src 1 dst 33
634512486 Security0 transmit timeout
634512486 SendRequest timeout waiting for 0x84 0x 6
634512486 We now have 3 frames in the mailbox - sending
634512486 zw.scheme: 255
634512487 create_bridge_association of temporary type
634512487 Re-using oldest temporary association with virtual nodeid 31
634512487 Sending 31->33, class: 0x0, cmd: 0x2
634512487 Sending with scheme 255
634512517 unsolicited_senddata_callback status 0
tcpip_ipv6_output: nbr cache entry stale moving to delay
634512518 Done sending mailbox item status is 0
634512519 Sending first attempt
634512519 zw.scheme: 255
634512520 Sending 31->33, class: 0x84, cmd: 0x5
634512520 DTLS for Classic node
634512520 Sending with scheme 255
634512555 Route change
634512555 unsolicited_senddata_callback status 0
634512555 queue_send_done to node 33 queue 1
634512557 Sending first attempt
634512557 zw.scheme: 255
634512558 Sending 31->33, class: 0x80, cmd: 0x2
634512558 DTLS for Classic node
634512558 Sending with scheme 255
SerialAPI: Got RESPONSE frame while sending....
SerialAPI: Retransmission 1 of 0xa9
634512684 ApplicationCommandHandler 33->31 class 0x84 cmd 0x06 size 6
634512684 bridge_virtual_node_commandhandler Handled
634512709 unsolicited_senddata_callback status 0
634512710 queue_send_done to node 33 queue 1
634512711 Sending first attempt
634512711 DeMangled src 33 dst 31:0
634512711 Packet from Z-wave side (nodeid: 33) to port:46503 IP addr: fd00:a622:3f5d:4590:2ec3:7ede:d3f1:b445
634512712 queue_send_done to node 33 queue 1
634512719 ApplicationCommandHandler 33->31 class 0x80 cmd 0x03 size 3
634512719 bridge_virtual_node_commandhandler Handled
634512721 Sending first attempt
634512721 DeMangled src 33 dst 31:0
634512721 Packet from Z-wave side (nodeid: 33) to port:46503 IP addr: fd00:a622:3f5d:4590:2ec3:7ede:d3f1:b445
634512721 queue_send_done to node 33 queue 1
634514722 DTLS: Session timeout
lipaddr: fd00:ab45:754f:c15d::0021 lport: 41230
ripaddr: fd00:a622:3f5d:4590:ba27:ebff:fed3:5eb5 rport: 41231
634514722 DTLS: Closing DTLS connection
lipaddr: fd00:ab45:754f:c15d::0021 lport: 41230
ripaddr: fd00:a622:3f5d:4590:ba27:ebff:fed3:5eb5 rport: 41231
634515721 No more info for node 33 putting to sleep
634515721 Sending 1->33, class: 0x84, cmd: 0x8
634515721 Sending with scheme 7
634515721 New sessions for src 1 dst 33

What could be the cause of not receiving the wakeup and how could that be fixed?

Thank you,


A zipgateway will intentionally not forward WAKE_UP_NOTIFICATIONs to the unsolicited destination. Instead, it delivers any messages that may be queued in its mailbox for the Z-Wave node that sent the notification. If you have messages that you’d like delivered to a node when it wakes up, send them as if the node were always listening. zipgateway will attempt to deliver the message (in case the device happened to be awake) and if it can’t, it’ll let you know with a Z/IP Packet that has its NAK and NAK WAITING flags set. If zipgateway knows about that node’s wake up interval, the Z/IP Packet will also have an “Expected Delay” header extension, where it’ll let you know how long it thinks the message will be queued for before the receiving node wakes up. Finally, zipgateway will also periodically send Z/IP packets back to you letting you know about your queued message’s status.

If you’re interested in learning about the device just after it was included, zipgateway intentionally delays the WAKE_UP_NO_MORE_INFORMATION message after an inclusion to give you time to do this. Just query the device as if it were always listening. In the rare event that the device does fall asleep before you query it, you can still queue your queries to the Version Command Class in the mailbox and they’ll be sent out and processed when the device wakes up - other than a potentially long delay, the outcome will be the same.

It’s important to use the mailbox judiciously when building a Z/IP client. In current versions of zipgateway, there’s limited space for the mailbox, and it’s shared across all Z/IP clients that communicate with it. There’s also overhead involved in sending the periodic “message still queued” notifications, so it’s best to try and keep the number of queued messages down to a minimum. It’s not an optimal solution, and any opinions you have on the subject are welcome :smile:

It’s typically a bad idea to query battery devices each time they send out a WAKE_UP_NOTIFICATION, as this adversely affects their battery life. Chances are that any information you’d be interested in either hasn’t changed, or was already sent out as a notification by the device upon change. The way zipgateway handles communication to sleeping devices with a mailbox discourages this approach.

It’s also worth mentioning that, as you already noticed, you can’t assume other frames from a node as an indication that its awake. Most battery-based devices will intentionally not stay awake after sending REPORTs to preserve battery life, instead only waking up at their programmed intervals or when manually triggered to do so.



Thank you, this is valuable information to me!

Nevertheless, I was mislead to think that I will receive such wakeup notifications (they are unsolicited, after all), especially since I do receive them for a thermostat, at least.
It’s probably because it’s packet together with some other notifications that come at the same time, in a ‘multi cmd’.

Yes, if the device is included I can rely on it being awake for a while, but it can be the case that the devices are already included and still my project needs to find out things about the devices (like the command class versions already mentioned).

Obviously there is no intention to get them each time the device wakes up, but only once (the versions are also saved in a database, so they wouldn’t be sent again if already known).

Is there a way to disable the mailbox on the gateway and if yes, would I receive wakeup notifications?

Thank you!


Interesting to hear about a WAKE_UP_NOTIFICATION nested in a MULTI_CMD. zipgateway doesn’t do any inspection on these packets, but it sounds like it should. As far as I know, there’s no restriction preventing this scenario.

The mailbox functionality can be either enabled, disabled, or passed on to an external destination (with zipgateway acting as a proxy). You can configure which option in the zipgateway.cfg file with the ZipMBMode parameter. zipgateway’s man page lists the options as:

    0 -> Disable Mailbox
    1 -> Enable Mailbox
    2 -> Mailbox Proxy Forwarding.

The setting can also be changed using the Mailbox Command Class once the zipgateway is up and running.

I haven’t tried it myself, but I have a feeling that disabling the mailbox won’t forward the wake up notifications to the unsolicited destination, but rather discard them. You could configure zipgateway to act as a mailbox proxy and have your application act as a mailbox service. The Command Class spec. document I linked above does a good job at describing what the frame flow will be in this situation in section Still, implementing all the features of a mailbox service sounds like a lot of work compared to just using the standard mailbox functionality.

For the case you describe, when your project joins an existing network that has already been setup, you could always just queue the messages you want sent to the sleeping nodes in the mailbox. zipgateway will send them out when the devices wake up - your UI could also instruct the user to manually wake up the devices if the information is needed immediately. From a user perspective, the end result is the same as if you had taken the role of being the mailbox service in your project, but without all the implementation work on your end.



I’ll try to disable the mailbox (using the mailbox command class) to see if in such case I’ll receive wakeup notifications.
It looks to me that they should be sent, or else there would be no way of communicating with the battery devices with a disabled mailbox (except receiving notifications).

I’ll try and I’ll see if it works.

Relying on the mailbox service will modify quite a bit the logic of the project… I didn’t even think yet of how much that means. Yes, a mailbox proxy also means quite a bit of change :frowning:

I was really surprised that wakeup notifications are not forwarded, after all they are quite useful information - even with the mailbox active one could avoid filling it with commands and send them only at device wakeup.

Thank you,



Just as a quick info: disabling the mailbox seems to enable sending the wakeup notifications.
I’ll have to test it more and probably change the app logic a little, but this is a good thing if it works :slight_smile:

Thank you,


By disabling the MB I also got WakeUp:Notification to my code for a day. But then it stopped, probably when I tried to fix something else. And now I cannot get it to work again. Was there something else than setting: ZipMBMode=0 in the config? Did you set ZipMBPort or ZipMBDestinationIp6 to something?


From the little coding I have done with Z/IP I first thought that using the built in Mailbox functionality would save us a lot of development time. But after trying to use it I felt the opposite, hopefully because I have misunderstood it. The main problems I see:

  1. it seems I need to keep a live connection to the mailbox for it to keep my messages, ack every 10 minutes (our DTLS code closed the connection after 2-3h and devices usually sleep for much longer than that)
  2. Even if I manage to keep the connection alive, how do I know which response is connected to which mailboxed request? I started on keeping track of sent commands but when I was done I kind of had more or less implemented a fully functional Mailbox in my code (except I cannot get the WakeUp:Notifications).

Have I misunderstood how to use the built in Mailbox?

Best regards