Battery Drain - Danfoss - Pulling every few seconds

I have included only one device on the setup for this. I finished also network heal of my Zipato network. In Netherlands is already cold and I cannot stay without heating.

Plan:

  1. Stop Openhab2 and use Z-way server to check if the device behaves the same. I also enabled debug log for Z-way server. I also installed the software of zwave.me for first time on my RaspberryPI. I do not know if drivers included.
  2. Stop Z-way and start again Openhab2 and check behaviour.
  3. Exclude device / Downgrade from 2.4.0M4 to 2.3.0 (stable) and do the test again.
  4. Install AEONTEC Z-stick and repeat the above (will be here on tuesday).

Z-way server works without this drain issue and proper wakeups, device lost no battery during night.
Moving back to openhab2 and will check behaviour

If you can work out what is different, I’ll be happy to look at it, but so far from what I’ve seen, OH is not sending anything abnormal to put the device into this mode.

Maybe the device automatically does this if it doesn’t receive some sort of message within some time - this would be very non-standard behaviour, although given Danfoss have their own software, maybe they don’t care too much for the standards here?

It is also that Danfoss was new at Z wave that period (2012) and therefore issues can be
I will attach a log on What is Z-way updates.

But I suspect one of the details was the Clock.
This is one of the transactions with z-way https://pastebin.com/mw3CpSPk
And a second one https://pastebin.com/gBNUG6dt

Putting the Device on openhab server it began after a while to perform the same dancing!

Can it be that device needs an Clock update or a scheduling setting to be set once a while to keep it sane?

Previous post has the debug part of Z-way, pretty small… I think some commands mentioned there.
Also While the device is on endless loop (8sec) wakes. If I change the wakeup interval from 300 to 301… it stops./
Therefore some of the commands/info send to the device everytime it wakes fixes the loop. Like setting a time/clock or setting the interval on every wake.

Possibly - I’m not sure as there’s no documentation as far as I’m aware on what this requires to keep itself happy.

It’s a lot of guesswork here and it would be good to find out properly - ie get a statement from the manufacturer of the device as to how to use their device. Maybe you can contact Danfoss to get a statement from them on what needs to be done?

That will not be easy from danfoss, as not easy to also find their contact . I will try the generic ones.

I will also try to find from Z-wave.me or Zipato a debug log of Commands sent on every execution to compare them (would that help?)

Maybe, but they should have a user manual that says how to use their product. If I look at products like Fibaro or Aeon, they have such a thing. Given that this device seems to require very specific functions to make it work, I would think that it should be documented somewhere?

Yes, we can try and reverse engineer, but it would be much better to actually know what is needed. We’ve tried this in the past, and clearly have not been successful and it takes a lot of time to do.

I am now testing with 2.3.0 Version of Z wave binding. if this is stable, will it help to find the differences? Because I saw no crazy issues for the last two hours with it.

There should not be any difference, but if you can find the difference, then please let me know. My guess at the moment is that this is related to a high level issue - eg not sending some sort of command such as time. However, that’s a guess, and if it is the case, then 2.3 will be the same.

I find these two GET commands sent to device on every wake:

2018-10-29 16:41:54.703 [DEBUG] [.ZWaveThermostatSetpointCommandClass] - NODE 2: Creating new message for application command THERMOSTAT_SETPOINT_GET (Heating)
2018-10-29 16:41:54.704 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling zwave:device:1668227521b:node2:battery-level
2018-10-29 16:41:54.706 [DEBUG] [rnal.converter.ZWaveBatteryConverter] - NODE 2: Generating poll message for BATTERY endpoint 0
2018-10-29 16:41:54.707 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 2: Creating new message for application command BATTERY_GET

this doesn’t happen on 2.4 version

I think this must just be down to your configuration - the binding doesn’t do this itself. If you have channels configured, and polling enabled, then these GET requests will be sent - it should be the same on 2.3 and 2.4.

I just added the device on Channels as it was not on any channel. It is stable for 3 hours on 2.3.
If it stays stable after adding channels… I think of moving to a clean 2.4.0M4 install and try again.

If the issue returns, what do you suggest?

In 2.4, did you have the same setpoint channel configured? Was polling configured? If so, then 2.4 should do the same thing that you saw in 2.3.

If not, then I’d like to see a log of the initialisation of the binding, and also the polling from the device.

I will leave it for another 4 hours. using the default
Polling: 30Minutes
Wake: 300Sec as device.

Device also is not initializing easily, I have to wake it like 5-6 times, and then force one link too. both versions.

I will pull out logs from both to compare / check.

You need to make sure that the channels are linked to items, otherwise it will not do any polling.

I have setup a fresh install and hard reset controller and the danfoss… now letting it work for a bit at 2.3.0
I kept debug log from the beginning which start with the inclusion. and next is to reset and setup the 2.4.0M4 again from scratch.

Will upload both later tonight.

@chris

Here are the logs

openhab2.3.0.log and openhab2.4.0.log

Same behaviour, only with 2.4.0 - After clean install… Even bootstraping new Raspberry image

I have an idea of what is up. Give me some time to work this through (over the next week).

@Chris
Thank you for your help till now an patience. Sure IF you want me to test some custom build ping me.