Should Z-wave drivers be sending wakeUpNoMoreInformation

Developers Coding Questions
,
1

Yes, that works as well.

FWIW, after a brief look at the ZWaveJS code, I did some quick testing. It appears to me that the underlying infrastructure handles the wakeUpNoMoreInformation on its own when the pending queue is empty for a period of time. So queueing wakeUpNoMoreInformation in the driver seems to interfere with the underlying infrastructure. I've removed calls to wakeUpNoMoreInformation from my drivers as a result. YMMV

1 Like
Zwave JS + Zooz ZSE41 not getting responses from Get requests
2

I am not coding any drivers around Zwave JS. Especially since it has been "re-written" (per changelogs) more than once if you count beta versions. So who knows what else will change. ZIP is apparently here to stay on anything less than C8 Pro. Staff has made it clear drivers should keep working as-is without changes as long as they use the standard command class code and not raw hex.

If certain things are now handled by Zwave JS that we used to have to do in the driver, then the Hubitat implementation of Zwave JS should ignore (or otherwise work around) those commands so the back end can handle it. I know there are multiple cases of this, supervision is another example. Zwave JS handles it all behind the scenes AFAIK, previously that all had to be coded out in every driver (if you wanted to implement it). IMO the platform should have been handling it all along anyway...

If we have to make changes to drivers to accommodate Zwave JS then, 1) they need to give us a way to easily check which gateway the hub is running from driver code, and 2) they need to officially announce breaking changes. Until those things happen my code stays written and working for ZIP.

5 Likes
3

I expect I would agree with you on other, larger items, but wakeUpNoMoreInformation is such a trivial optimization that simply removing it made the most sense to me. YMMV.

2 Likes
4

I split this conversation off into another thread so it did not derail the other users issue
I think this is an appropriate forums category...

Yeah probably not a hill worth dying on. Sort of a touchy subject right now, getting frustrating chasing issues with devices or drivers for people, only to find out it is due to Zwave JS quirks or bugs.

I found some info that a sleepy device should remain awake for at least 10s (but could be longer?) if you do not send the NoInformation back. It also sounds like possibly ZIP also has a built in time out where it will send it by itself anyway (More Information flag section). There is no official posted sleepy device zwave driver example, so unsure of what built in drivers are doing. @bertabcd1234 or @bcopeland any chance for an example driver for a modern z-wave sleepy device? Now I am curious.

Also found in that article that a S2 sleepy device when you send back the supervision report you can ask that it wakes up, which is kind of neat. So like a motion sensor for example, if you had config stuff queued up and it sent in a supervised motion report, when you reply to that supervisionGet you can set a flag telling it to wake up.

2 Likes
5

It does and that time is configurable.. But by sending noMoreInformation it will put the device to sleep faster thus saving battery.

We do.. Example supervision.. It's stripped out, but if used a fake response is sent back.. But noMoreInformation is useful.

No need to change anything.. The goal is for drivers to be universal ..

I do plan to add new features for ZWave-JS in drivers which will of course have a way to determine if it can be used.. One main thing I want to do is to give access to the complete device state (all stored command class values and all device data) which could be very useful for new inclusions and sleepy devices..

We use noMoreInformation

4 Likes
6

Now .. All that being said.. You can make ZWave-JS exclusive drivers.. I have experimented with that.. It can be much leaner than the traditional drivers because everything is already parsed out into json.. But I won't be doing that any time soon because not all hubs will be running it..

3 Likes
7

Thanks for the feedback.

Do you typically add an extra delay to that command or just plop it at the end of the list for the response to the wake up?

I was concerned with the device going back to sleep too quickly so I added an extra 'delay 1400' before it in my code, which then I think gets additional delays padded on both sides from the 'delayBetween' function also being used. So it ends up being around a 2 second delay for my drivers, between the last actual command and the noMoreInformation.

That's one thing I am actually liking with ST EDGE drivers. At times there is a lot less code needed because they have so much built into the platform.

2 Likes
8

I pop it at the end of my commands.. No delay..

2 Likes
9

Example from internal driver:

void zwaveEvent(hubitat.zwave.commands.wakeupv2.WakeUpNotification cmd) {
    if (logEnable) log.debug "${device.displayName} Device wakeup notification"
    List<String> cmds = []
    cmds.add(new hubitat.zwave.commands.batteryv1.BatteryGet().format())
    if (state.configUpdated) {
        cmds.addAll(runConfigs())
        state.configUpdated = false
    }
    cmds.add(new hubitat.zwave.commands.wakeupv1.WakeUpNoMoreInformation().format())
    sendToDevice(cmds)
}
3 Likes
10

Doesn't sendToDevice() insert a 200 or 300ms delay?

11

Yes.. Normal multiple command delay... Mine defaults to 300ms..

void sendToDevice(List<String> cmds, Long delay=300) {
    sendHubCommand(new hubitat.device.HubMultiAction(commands(cmds, delay), hubitat.device.Protocol.ZWAVE))
}

void sendToDevice(String cmd, Long delay=300) {
    sendHubCommand(new hubitat.device.HubAction(zwaveSecureEncap(cmd), hubitat.device.Protocol.ZWAVE))
}

List<String> commands(List<String> cmds, Long delay=300) {
    return delayBetween(cmds.collect{ zwaveSecureEncap(it) }, delay)
}

What @jtp10181 was talking about was a long delay after the last command and before noMoreInformation

3 Likes