Issues interviewing Aeotec Door Sensor 7 & Aeotec Door Sensor 7 Pro

[jdiegmueller]

All--

Wanted to run this by the community:

In my environment, I have a Hubitat Elevation hub which acts as my primary controller. zwavejs2mqtt is currently running on a Pi 4B with an Silicon Labs UZB-7 operating as a secondary controller. I have a hunch the secondary controller role of the zwavejs2mqtt may be the issue here

When zwavejs2mqtt interviews mains-powered devices, that obviously works. zwavejs2mqtt finds the device, adds itself as a second association to Group 0/lifeline, and away we go.

When zwavejs2mqtt interviews the Aeotec Trisensors (battery-powered/sleepy device), it works as long as I hold down the magic button for ~3 seconds to get it in to listening mode while zwavejs2mqtt is attempting to interview it (as expected). Sometimes it takes me a couple of wakeups to get it fully interview, but it works. The Trisensor sends a Node Info broadcast (node 255) which the secondary controller is able to see -- and as part of the interview process, zwavejs2mqtt again adds itself as a second association to Group 0/lifeline so future wakeups are multicast to both controllers.

My issue is with Aeotec Door Sensor 7 & Aeotec Door Sensor 7 Pro. I simply can't get these guys to be successfully interviewed by zwavejs2mqtt. The big difference I observe from the equally-sleepy Trisensors referenced above is that the wakeups from the door sensors do not send a Node Info broadcast, and I suspect(?) the result of this is that zwavejs2mqtt never sees this and hence never tries to interview it. I expect that were I to include the door sensors to the zwavejs2mqtt controller, zwavejs2mqtt would be able to successfully interview it since the wakeup notification would then be singlecast to the door sensor.

Any suggestions for how to work around this? Perhaps a more forceful "INTERVIEW NOW" command which would ignore the fact it's a sleepy device and try anyway?

Thanks for any insight.

[robertsLando]

This needs logs to be debugged

[jdiegmueller]

This needs logs to be debugged

I can certainly do that, but I'm a little unclear how to collect anything useful since it appears zwavejs2mqtt has no idea the node has woken up so it never interviews it.

Regardless, I stopped zwavejs2mqtt, deleted all log files, and then restarted it. I then went to one of my Aeotec Door Sensor 7 Pros (node 27) and hit the wakeup button a few times. I don't see anything happening with zwavejs2mqtt (node 30), but I do see plenty of activity between the Hubitat Elevation hub (nodes 1-5 & node 8 if I understand correctly) in a Zniffer trace of this happening. I never see anything to/from node 30.

Here's what I collected, but I'm certainly happy to be steered on what would be useful:

• [http://ftp.nevosi.com/publicwebspace/zwavejs2mqtt/zwavejs2mqtt.log]
• [http://ftp.nevosi.com/publicwebspace/zwavejs2mqtt/zwavejs_11449.log_2021-05-20.log]

And here's a look at the Zniffer capture:

Thanks for any insight on this.

[jdiegmueller]

Ok, I made some progress on this:

I think my hunch about needing a Node Info to be broadcast for the secondary controller to see it is spot on. I figured out that if I trigger an exclusion request, the node will broadcast exclusion requests. Because these are broadcast, the secondary controller (and hence zwavejs2mqtt) sees it as being Awake and is able to complete the interview process.

While I do see activity to/from them, now, it does appear they get incorrectly identified:

• Aeotec Door Sensor 7 (ZWA011): Detected as ZWA008 (the previous generation of this sensor)
• Aeotec Door Sensor 7 Pro (ZWA012): Not identified. The web interface suggests it is discovered as Manufactur 0x0371, Product 0x0102, Product Code 0x000c.

I'm happy to provide any data that would allow for better identification of these devices. Thanks!

[robertsLando]

I think it may be a device configuration problem or else. CC @AlCalzone and @blhoward2

[blhoward2]

I haven't gotten to those yet as they are in my very last pile. The ZWA011 should show unknown. What is your deviceID and deviceType? The ZWA012 is expected to show up that way...it should still work fine without the label.

[AlCalzone]

I have a hunch the secondary controller role of the zwavejs2mqtt may be the issue here

zwave-js currently assumes that it is the primary controller. There's additional functionality needed to act as a secondary controller, but there are other more pressing issues I have to sort out first. Like you already figured out, nodes that don't tell us that they are awake won't be interviewed. This is usually not an issue if zwave-js is the primary controller.

As for the mis-identification: @blhoward2 is working on adding the new Aeotec devices. They should be working though, except for the interview that takes a while, since they are using Transport CC for some commands without checking for controller support.

[jdiegmueller]

Yes, makes complete sense about the controller bit; my understanding is that this project is fairly new, so it makes perfect sense it's further down the list.

My intention at this moment is to leave the Hubitat hub as my primary controller and only use zwavejs2mqtt to send multicast Zwave messages, as I've have been talking about in the other Github Discussion. Do you see any issue with doing that? Seems to be harmless so far, but figure there's no harm in asking.

Thanks again.

[AlCalzone]

Should be possible - but to be honest, I'm not experienced with multi-controller setups. If it works, I see no problem.