Battery Devices are not working properly with the new Z-wave binding (snapshot or M8)

The Battery devices are acting in a strange way, which I cannot understand. There are always commands Pending or waiting the device to wake. Only happens on the new 2.4 binding

Danfoss LC12 - Battery Drain due to some issue (Extensively discussed)
Danfoss LC13 - Waiting messages till next waik. I have to manualy press the middle button every 10 seconds to receie an temperature update
POPP Thermostat As LC13

Today’s issue is the Sensative Strips, they do not fully communicate, I never receive open/close door If I can successfully pair them.

failed Sensative inclusion:

If you provide a full debug log showing the problem that you’re having, I will take a look. Please do not filter the log.

@chris here is a log when I try to wake the device and it clearly doesn’t update any value… but also stucks with a waiting command Until Expires or I use the special magnet to wake the sensative strip

node 26 is the door sensor.

Also all my Z-wave devices lac of controller called Lifeline(in some) which report back state.
I think is typically parameter 1.

at Thermostats I cannot set/ store this one.

@chris here another example of messages 5 of them been aborted due to timeout.
This happens also with the Danfoss ones, and my Zipato 4in1 binary. Basically all my battery devices.

These doesn’t happen on 2.3 or other software with the same module.

Dear Chris,
Thank you for your valuable time.

Here another 2 tries of Including the same strip (After factory reset). This strip is node 41 and 42.

Sensative Guard Strip
Log is big enough you can download part of it (4mbyte) in this url:

Sorry - I will try and look at the logs when I can - at the moment I’m accessing my internet through a system that is blocking pastebin and googledrive :frowning:

No worries!!! you are doing a Great job making our automation projects simple.

Here is an alternative url: (uploaded )

I would like also access to DB updates.
I have a new Neo coolcam device ( I need to test the latest one with new parameters. and split the 0003:108D As I found issues with parameters too.

Additionally is there a guide (which files to touch, restarts if needed etc), in order to modify device xml locally and work out how the device really works?

Please create an account on the database site and open a ticket so that I know your username.

I did this. Thnx!

About testing new device parameters, or adding custom on our local system is it possible?

I suspect that mentioned sensor is coming with the wrong manual. which has misleading parameters

I did use the z-way server which allows to use custom configuration parameters, and my device has parameter 11. which needs to be split.

If you can send me some way in Openhab where I can ask device for specific parameters (using number) that would help me to debug and work my way on helping updating the databases.

FWIW, I was looking at similar issues when I was finally shifting everything in my house to OH from Homeseer and discovered two things in 2.4 – first, that status indicator is often wrong. I don’t know if its a UI issue or a binding issue, but it often says PENDING long after its been updated. And second (and I think this is just a documentation issue), as far as I can tell the OH binding doesn’t set itself in any associations, so you have to remember to manually do it every time you add something. Most other Z-wave systems seem to have a tag in their metadata that tells the system which associations to set the controller into automagically.

Once I realized that PENDING was wrong a lot of the time and remembered to go and update the associations, all my devices – including my battery ones I’d been struggling with – eventually started working reliably.

I’ve found restarting the binding will often clear up the PENDING mismatch, but my network takes almost an hour to do the startup refresh on and during that time pretty much nothing works, so I try to not do it very often.

Config parameters doesn’t connect with associations. I found out these are set in the Database.
But for the rest I agree