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

[phjr99 (Peter Halicky)]

I have a couple of POPP door/window sensor I just bought and want to configure them in OH.

Short story first:
The device isn’t supported in 2.4.0, so I have done some hacking and I have added the pope700982_0_0.xml file from 2.5.0-SNAPSHOT to the zwave binding 2.4.0 jar file. The device is now recognized nicely by OH2.4.0 and I can edit most of its settings. The problem is, I need to add the controller to the lifeline association group. When I do that in PaperUI or in HABmin, it doesn’t work. I have increased zwave binding logging and this is what I see there when I do the change:

2019-08-02 11:35:49.336 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update received
2019-08-02 11:35:49.365 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored binding_cmdrepollperiod to 1500 (BigDecimal)
2019-08-02 11:35:49.366 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_10_2 to 0 (BigDecimal)
2019-08-02 11:35:49.368 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored group_4 to null (null)
2019-08-02 11:35:49.370 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_7_1_wo to 255 (BigDecimal)
2019-08-02 11:35:49.381 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update set group_1 to [controller] (ArrayList)
2019-08-02 11:35:49.384 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Unknown association group 1
2019-08-02 11:35:49.388 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored group_3 to null (null)
2019-08-02 11:35:49.390 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored group_2 to null (null)
2019-08-02 11:35:49.393 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored wakeup_node to 0.0 (BigDecimal)
2019-08-02 11:35:49.396 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_11_2 to 0 (BigDecimal)
2019-08-02 11:35:49.401 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_12_1 to 1 (BigDecimal)
2019-08-02 11:35:49.406 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_13_1 to 0 (BigDecimal)
2019-08-02 11:35:49.407 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_14_1 to 0 (BigDecimal)
2019-08-02 11:35:49.418 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored action_failed to false (Boolean)
2019-08-02 11:35:49.420 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored wakeup_interval to 3600.0 (BigDecimal)
2019-08-02 11:35:49.421 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored action_remove to false (Boolean)
2019-08-02 11:35:49.423 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored binding_pollperiod to 86400 (BigDecimal)
2019-08-02 11:35:49.424 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored action_heal to false (Boolean)
2019-08-02 11:35:49.426 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_1_1 to 0 (BigDecimal)
2019-08-02 11:35:49.427 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_2_1 to 0 (BigDecimal)
2019-08-02 11:35:49.429 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_8_1 to 0 (BigDecimal)
2019-08-02 11:35:49.430 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_9_2 to 0 (BigDecimal)
2019-08-02 11:35:49.431 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_3_1 to 7 (BigDecimal)
2019-08-02 11:35:49.433 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_4_1 to 0 (BigDecimal)
2019-08-02 11:35:49.434 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_5_1 to 0 (BigDecimal)
2019-08-02 11:35:49.435 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored node_id to 32 (BigDecimal)
2019-08-02 11:35:49.437 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 32: Configuration update ignored config_6_1 to 2 (BigDecimal)

Notice the line that says “Unknown association group 1”. Any idea what that means? Does it mean the xml definition for the sensor thing is faulty? I got stuck at this point, having no idea how to figure this out on my own.

Long story for the patient ones:
I knew what I was going into when I was buying the device, I was aware it’s not supported on 2.4.0; I thought: hey here’s my chance to contribute. Ultimately after a lot of research on these forums I found that it’s already supported in latest 2.5.0-SNAPSHOT, so I gave that a try. Finding the binary was a bit tricky, as most forum posts refer to an old froggy repository/build system, but finally I found it. (The URL is at https://ci.openhab.org/ in case someone has the same problem as me)

I was able to get 2.5.0-SNAPSHOT working and I got the device detected. But then the same problem hit me - I was unable to set the lifeline association group. Thinking this is some sort of a bug either with OH2.4 vs binding from 2.5 not getting along, or just a 2.5 bug as such, I finally went back to the 2.4 version of the binding and did the surgical work of patching the 2.4 binding with the new thing definition.

[Bruce_Osborne]

Do you have a link to the device in the database? It may be an error there. I am slowly working through correcting many of them.
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list

[phjr99 (Peter Halicky)]

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

[Bruce_Osborne]

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.

Zigbee and zwave manual install script

A number of people have run into trouble performing manual installs of the Zigbee and Z-Wave bindings. A manual install (dropping the jar into addons) is rarely needed, but some people prefer a manual install over apt-get, or want to use a stable OH release with a recent Zigbee or Z-Wave binding. Here is a script that will hopefully make it easier to install, upgrade, and uninstall these bindings, and prevent some of the common issues. Who would benefit from this script: Anyone wanting to tes…

[phjr99 (Peter Halicky)]

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

[Bruce_Osborne]

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.

[chris (Chris Jackson)]

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.

[phjr99 (Peter Halicky)]

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.

[chris (Chris Jackson)]

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.

[phjr99 (Peter Halicky)]

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?

[chris (Chris Jackson)]

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).

[phjr99 (Peter Halicky)]

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)

[chris (Chris Jackson)]

@phjr99

I can’t find a XML file

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

[phjr99 (Peter Halicky)]

@chris

This probably indicates that the initialisation is not complete

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

[chris (Chris Jackson)]

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.

[chris (Chris Jackson)]

@phjr99

Well… there is this line in the log:

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.

[phjr99 (Peter Halicky)]

@chris

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.

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.

[chris (Chris Jackson)]

@phjr99

Both nodes 26 and 30 are quite far from the controller (probably the farthest), which possibly could cause the high traffic

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.

[phjr99 (Peter Halicky)]

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.

[chris (Chris Jackson)]

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.