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

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

The database device looks OK to me. Many people, including me, have used the script to update the zwave binding. I am running a snapshot binding on 2.5M1.

Any suggestions then? Would it be interesting to see the debug log of the current 2.5.0-SNAPSHOT zwave binding?

I have not heard of anybody patching a 2.5 snapshot device into a 2.4 jar.
@sihui, @chris, or @5iver could give better advice.

It should be ok, but there are no guarantees. The XML format is the same, but as the XML configures the code, if there are code changes relating to the device you are using that are configured through the database, then it may not work.

I’ve not looked at this device so this is a general statement.

1 Like

OK, so I’ll go back to zwave binding 2.5.0-SNAPSHOT bleeding edge and get the DEBUG log again - will report back here.

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.