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:
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.
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.
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.
Looking at your issue, there are a couple of reasons for this sort of thing.
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.
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.
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.
Delete the XML file I mentioned above and restart the binding.
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.
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 -:
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.
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:
remove the device from the network (was a bit tricky to find how to activate exclusion mode on the controller)
add the device again
upon first adding, the device was showing as undetected/unrecognized (this happened to me before with other battery devices too)
removed the thing from OH, re-added and now voi-la - the device was recognized
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.