Z-Wave device POPP 700982 (Door/Window sensor) - Unknown association group 1

Looking at your issue, there are a couple of reasons for this sort of thing.

  1. The device isn’t fully configured - the binding downloads the device information from the device, and if it’s not received a list of all the command classes and their configuration, then it may not be configurable, and you will get this sort of error.
  2. The device doesn’t report its services correctly. This is sort of the same as the first issue - the binding still doesn’t know all the device information, so the error is the same, but in this case initialising the device doesn’t help. If this is the issue, then there are workarounds in the database to resolve it.

Can you post the XML file for the device (from the userdata/zwave folder)? A debug file from the initialisation may also help.

1 Like

For initialisation log, is it enough to remove the thing in OH and then re-add? Or do I need to exclude and then include it from the network?

Deleting the thing won’t really help since the low level zwave stuff is pretty much independant. There are a couple of options that should get what I need.

  1. Delete the XML file I mentioned above and restart the binding.
  2. There might be a “Reinitialise” option in HABmin or PaperUI that you can also use (this can depend on the current state of the device though).

Initialization log attached, look for node 32. I can’t find a XML file in {userdir}/zwave - I have files there all the way up to node 31, but no node 32.

zwave.log (208.1 KB)

This probably indicates that the initialisation is not complete as the XML is only written at certain points during the initialisation.

Well… there is this line in the log:
NODE 32: Device initialisation complete.

The log doesn’t show the device initialisation, but it does show other problems with your system…

The above is a short part of the log - this shows that most messages are received multiple times - this happens from multiple devices as well. This will likely be causing problems with the general operation of the network and can be caused by a couple of things -:

  1. incorrect configuration of associations. If you have configured devices to send the same information to the controller in multiple groups, then you’ll see this. For newer devices, only the lifeline is required.
  2. Problems with the network. If the response from the controller is not making it back to the devices to say that the message is received, the device will resend it. This can really congest the network.

This may or may not be contributing to the issue with this device, but it certainly won’t be helping.

Unfortunately that message is not well written. There is no initialisation of the device in the log - in fact there is no communication with the device in this log.

This message should say that the handler configuration is complete - it isn’t really linked to the device itself.

Both nodes 26 and 30 are quite far from the controller (probably the farthest), which possibly could cause the high traffic - also those are power plugs which report very often their state (30s). On the other hand, everything seems to be working well from perspective of the user.

I did this now:

  1. remove the device from the network (was a bit tricky to find how to activate exclusion mode on the controller)
  2. add the device again
  3. upon first adding, the device was showing as undetected/unrecognized (this happened to me before with other battery devices too)
  4. removed the thing from OH, re-added and now voi-la - the device was recognized
  5. went to settings to set lifeline association to controller - only to find it was already there!

I just did the rest of the configuration and it’s working fine and reporting the status.

I guess the problem started when I included the device with zwave 2.4.0 - which didn’t recognize it. Anyway, problem is now resolved. If you’re interested, I have DEBUG logs for steps 2-4.

It shouldn’t though. There is something wrong here and I would really suggest it should be fixed or I think you will have problems. Everything is being received many times from these devices - note that is also happens with node 5.

Node 5 is another power socket. Do you have any suggestions how to diagnose the problem? This node also has no other associations other than lifeline with the controller.

It’s not super easy to diagnose with a sniffer. I would probably suggest to see if there is an “obvious” common point between these three nodes for starters. Eg does it look like they might all route through one device, and then is that device maybe a little too far from the controller? Place a mains device in this gap to see if it helps - it might be a bit of trial and error…

My guess is that somewhere along the route, the ACK isn’t being received by one of the devices, so the preceding device is sending a retry, which is also not being acked. This repeats a few times and it either gets the response or gives up, so the retries stop. If so, it also likely means that commands from the controller to these devices might also be living on the edge and could also be unreliable.

This is what my network map looks like. Seems like all the nodes in question talk directly to the controller.

About sniffing - is there a way to do this? I believe I have the hardware needed for it (a SDR receiver), but I’m not sure if there’s any software support for sniffing and decoding z-wave traffic.
EDIT: looks like there are some resources for sniffing out there (using rtl-sdr dongle), I’ll keep it as a last resort.

Except node 5 …

Unfortunately this shows neighbours, and not routes - it’s not possible to tell what links are good quality and what ones aren’t.

Yes, Silabs have software that can be loaded into a dongle to act as a sniffer - it’s called Zniffer and tehre is a recent discussion about it on the forum.

Here.

Right - I missed that node 5 is not direct neighbor of the controller.

For sniffing I found this and want to give it a try: https://github.com/andersesbensen/rtl-zwave
Will also look at zniffer, but looks like that means buying more HW.

You can flash and use pretty much any controller, but be sure you have the original firmware if you want to turn it back into a controller. I asked Aeon Labs for the gen5 zstick firmware and they sent it to me, so I’ve been using mine as the zniffer. The RSSI is really low, but that might be a hardware issue (I’d retired it a couple years ago).

I stumbled upon this thread when searching for help concerning inclusion of the Popp door / window sensor. In the meantime I was able to include it successfully so would like to offer a solution here for others looking for help.

As mentioned above the sensor is not supported under 2.4; I chose the easy way and waited for 2.5 to be released. After (seemingly successful) inclusion no xml file was written and the sensor did not react when opening / closing the window. As Chris explained above the ‘Device initialisation complete’ message does not signify successful inclusion. The trick is to wake up the sensor really often after inclusion in order to get the interview completed. I probably woke it 30 - 40 times, all in direct range of the controller. Unfortunately, the manual instructs to click the tamper switch once to wake up the device. I found that a triple click is required in order for the controller to continue the interview which is clearly visible in the logs. I do not know whether the manual is wrong or my specific controller (ZWave.me UZB stick) reacts differently from others. According to the manual the triple click is supposed to put the sensor into inclusion mode. In any case, it helped me to get the sensor fully included.

I had that happen on a totally different device & brand and support determined the manual was in error.

I’ve added that information to the device overview page.

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/1009

1 Like