Battery Drain - Danfoss - Pulling every few seconds

[billias (Vassilis)]

For Some reason my Danfoss is eating batteries in a few days. After researching the problem I found on my Debug Log a problem which seems strange to me. Device begins with not reason (apparently) to wake every few seconds, instead of 900.

I am using the latest Z-wave binding from cd Jackson.

I suspected network healing, but this is not the reason. Device works after I set a new wakeup frequency for about 3 hours and then switches to crazy mode again.

Openhab: 2.4.0M4
Z-wave binding : latest from Jackson’s topic

[5iver (Scott Rushworth)]

Z-wave binding : latest from Jackson’s topic

Are you using the version of the binding included with M4, or did you download a jar?

[billias (Vassilis)]

Downloaded jar.

Also now (I was just browsing no changes) Device has no config on paper/habian ui. Strange behaviour. Reboot fixed it. - initialization finished

More info:
Danfoss V2.50 (Danfoss Z)

[5iver (Scott Rushworth)]

Downloaded jar.

From here?

OH2 Z-Wave refactoring and testing... and SECURITY

The latest version of the development binding dated 8th Sep 2018 is here. Toward the end of last year I spent some time doing some initial refactoring of the ZWave binding in OH2. This focussed on rewriting the way transactions work as this is an enabler for other areas of the code. At the same time I also restructured the different layers of the binding to make things cleaner, and done some changes to support a system of autocoding the command classes directly from the Z-Wave standard which s…

If so, it has been merged into the master branch.

ZWave binding updates

I have now merged the development version of the ZWave binding into master, so it will be available in the 2.4 snapshot version. If you are using the ZWave binding, please read this post as the binding contains some breaking changes so you will need to manually update your configuration. Firstly though - the major enhancements (there are tons more smaller updates) -: Security has been added using the S0 security class. This should allow all devices supporting security to be included into the…

The latest version is in the snapshot builds, but milestone M4 is not far behind. You should probably uninstall the binding (through Karaf), delete the jar, and install through Paper UI, Habmin, or Karaf. Then see if your issue persists.

[billias (Vassilis)]

Basically M4 should have the newer Binding (but not the latest)

[5iver (Scott Rushworth)]

Correct. M4 is close to the latest, and depending on how old your jar is, could be much newer.

[billias (Vassilis)]

M4 version has a problem I mentioned at another topic. Device never wakes, resulting to sleep for ever, and go offline/do not update.

[5iver (Scott Rushworth)]

Which version of the binding are you currently running? In your other post, you mention a snapshot version. In the Karaf console, run list -s | grep zwave, and post the result. Have you manually woken the device?

[billias (Vassilis)]

I did a manual wake on the device. And also My version now is the M4 one. Lets see if it breaks.

Should I file some bug for this difference (if M4 works and snapshot not?)

I will let it run for some hours and see.
Thanks for the suggestions @5iver

[chris (Chris Jackson)]

Device begins with not reason (apparently) to wake every few seconds, instead of 900.

Note that the binding will not poll the device unless the device wakes up. So, if you have the wakeup period set reasonably long, then this should not really be an issue. If the device is really waking every few seconds, then you need to change the devices configuration - not the binding polling period.

I’m not sure why the binding should poll every few seconds either though - unless you have the polling period set very low. If you have a debug log that shows the behaviour, then I’m happy to have a look at it.

[billias (Vassilis)]

Note that the binding will not poll the device unless the device wakes up. So, if you have the wakeup period set reasonably long, then this should not really be an issue. If the device is really waking every few seconds, then you need to change the devices configuration - not the binding polling period.

I’m not sure why the binding should poll every few seconds either though - unless you have the polling period set very low. If you have a debug log that shows the behaviour, then I’m happy to have a look at it.

I have device logs with M4 and with the Snapshot. Same behaviour. After some hours the device goes “crazy” and pulls constantly!

I have only one device, I will upload the logs which shows this behaviour.

When I set again a new Wakeup Interval, device starts behaving again.

[chris (Chris Jackson)]

I have device logs with M4 and with the Snapshot. Same behaviour. After some hours the device goes “crazy” and pulls constantly!

I’m not really sure what this means? What does “pulls constantly” mean? The device doesn’t normally “pull” (or poll?).

I’ll take a look at the logs when you upload them.

[billias (Vassilis)]

Sorry not pulls… Wakes! my mistake

Logs: https://drive.google.com/drive/folders/1GvwogHKfZ0e5r2xs8x7_O6gX17Xre8kP?usp=sharing

I didn’t know how to share them:
Openhab.log.7* - Snapshot zwave binding
Openhab.log - M4 version of Z-wave binding.

The openhab.log.7mini shows a smaller version of openhab.log.7

[chris (Chris Jackson)]

Sorry not pulls… Wakes! my mistake

Ah - ok - that makes more sense . If the wakeup is changing, I would keep an eye on the logs to see if something is changing it - eg maybe there is an issue with the UI and it is sending the period to a low value?

I’ll have a look at the logs…

[billias (Vassilis)]

Thank you, I couldn’t pin point something like that! but you can read them better than me.

The strange part, this happens always about 1-2 hours after I set the wake value, without having any interface running. Maybe the device waits every time to update it’s ‘wakeup interval’?

[chris (Chris Jackson)]

This definitely looks like a device config issue. The binding is not sending anything to the device other than the “go back to sleep” command, but the device seems to be waking up every 8 seconds.

My suggestion would be to set the wakeup period to something “normal” (normally I suggest 1 hour, but for this type of device you probably want something in the 5 to 15 minute range so that it has a better response for thermostat updates). Keep debug logging running, and hopefully, these updates should come in at the rate you have programmed. You then want to catch the point in the log where the device starts sending wakeup requests at the 8 second rate and then check the log between the previous couple of wakeups to see if the binding sent anything to change the wakeup period.

If there was a command sent, then we can try and work out where it came from. If the device is changing by itself, then I’m not sure I have a good suggestion on how to proceed .

[billias (Vassilis)]

Device accepts a maximum of 900sec (Danfoss Living connect Z LC-12)

The issue here is that devices “resets” or something similar happens.

Here are two points in time where device goes “crazy”
Using snapshot: https://pastebin.com/W9snL1tF (over night)

Using M4: https://pastebin.com/01bXM7dV (5 minute interval)

I Device works normally for

Also grepping the went to sleep

2018-10-28 09:52:56.620 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 09:53:04.870 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 09:53:13.204 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 09:53:21.411 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 09:53:29.731 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 09:53:37.972 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 09:53:46.241 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 09:53:54.493 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 09:54:02.751 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 09:54:11.072 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 09:54:14.950 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 09:54:23.215 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 09:54:31.466 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 09:58:55.985 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 10:03:47.821 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 10:08:39.591 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 10:13:31.359 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 10:18:23.115 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 10:23:14.856 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 10:28:06.601 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 10:32:58.356 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 10:37:50.082 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 10:42:41.916 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 10:47:33.729 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 10:52:25.471 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 10:57:17.276 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 11:02:09.105 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 11:02:17.407 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 11:02:25.622 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 11:02:33.926 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 11:02:42.135 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 11:02:50.389 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 11:02:58.693 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE

Second example from 15 minute wakeup interval, same behaviour.

2018-10-27 23:51:50.327 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-27 23:51:58.602 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-27 23:52:06.838 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-27 23:59:51.290 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 00:14:28.660 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 00:29:05.976 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 00:43:43.290 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 00:58:20.618 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 01:12:58.007 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 01:27:35.217 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 01:27:43.537 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 01:27:51.991 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 01:28:00.286 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 01:28:08.561 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 01:28:16.863 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE

When I update the wekup interval works for ~1 hour and then starts constantly pulling.
Device XML: https://pastebin.com/WurAfnW7

[billias (Vassilis)]

Comparing LC-12 with LC-13

I see Beaming not enabled on LC-12 ones (does it support this?)

[chris (Chris Jackson)]

2018-10-28 10:47:33.729 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2018-10-28 10:52:25.471 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE

I had a look at the log around this time and there is nothing that the binding is sending to change the device configuration. The only commands I can see at all are the “Go back to sleep” commands that the binding is sending when the device wakes. Either something else is changing the device configuration (which is pretty unlikely) or the device is changing config by itself.

I’m not sure what else to suggest really (sorry).

Device XML

One interesting point in here is the device reports that it can’t be set to a value below 60 seconds. This leads me to believe that the device has a problem as if something external was setting it to 8 seconds, it should reject it. So -:

Either -:

• the device has a problem in that it’s allowing other devices to set the wakeup to below 60 seconds, AND, another device is setting the wakeup to 8 seconds

or

• the device has a problem is is setting itself to 8 seconds due to a software or hardware issue

I see Beaming not enabled on LC-12 ones (does it support this?)

I’m not sure if it is supported, but this is not something that you can enable - these are reports from the device on what features it supports. If the device doesn’t support it, you can’t change this.

[billias (Vassilis)]

Should I reset and pair/bind again?