Danfoss LC-13 battery life

[Kaz Librowski]

I have a Danfoss valve installed in my z-wave network, and it is working to the extent that I can set the setpoint and read the battery level.

This would be sufficient for me if it were not for the fairly rapid battery drain.

If I believe the battery readout, it is using up around 1% per day, so it should last approx 100 days, as opposed to the 2 years advertised (it was a lot worse, but seems to have settled down with the 1.7 snapshot).

The Danfoss manual specifically says that if the controller is not permanently available (e.g. it's a stick on a PC that is switched off), then battery life will suffer.

So from this I infer that there is some sort of handshaking going on, because if the valve just broadcast its "i'm awake" message every 5 mins or so without caring about a resonse, then the presence or absence of the controller would be irrelevant.

Is this right, and if so, then where can I get hold of the z-wave handshake protocol so that I can do some debugging? Anyone know?

The alternative explanation is that this level of battery drain is normal given the default wake-up period, and that if I want the advertised 2 years, then I need to:

a) Set the wakeup period to be much longer

b) Rely on the in-built schedule that the valve supports (but which OpenHab doesn't allow me to set)

Does anyone have experience with the battery drain on the LC-13 device?

[morten...@gmail.com]

This definitely has something to do with the wakeup period.

I have set mine to wakeup every 1800 seconds, which seems to preserve the battery pretty well.

My valve has been running for 14 days, and is at 91 percent. Due to some setup problems I know it used a lot more battery the first couple of days.

My take is that this setup will last 200+ days or so. But again battery devices are very dependent on signal quality and usage, that it is difficult to forecast.

I guess z-wave manufactures are suffering from the same ideal measurement policy as car manufactores regarding gasoline consumption.

What is your wakeup period set to?

Best regards

Morten Attermann Holst

[Kaz Librowski]

Hi Morten,

Thanks for the feedback. My wakeup period is set to 300, which I believe is the default. I certainly haven't altered it myself.

Of course, I'd expect that extending this wakeup period would extend the battery life, for obvious reasons, but it would also reduce the responsiveness of the valves to control signals. 1800 (if it is in seconds) is a 30 minute lag, which is quite a lot.

I had two reasons behind my question:

1) I read somewhere (can't remember where now) that other (non-OpenHab) systems get a longer life out of the same valve.

2) The Danfoss instructions explicitly state that if the controller is switched off, battery life will suffer.

Putting these two together, I've come up with a hypothesis that there might be some handshake protocol involved, which goes along the lines of

a) Wake up

b) Send a message to the controller

c) Wait for the appropriate response from the controller

d) If no response, or wrong response, panic and send another message etc. (This is where the battery drain would come in)

What's interesting is that although you have your wakeup period set to 6 times longer than me, you are not projecting 6x longer battery life. I appreciate that this is not an exact science, but nevertheless it suggests that something else might be going on here as well.

[morten...@gmail.com]

I am not enough into the basics of what the controller is doing, but i am pretty sure that it does not go to sleep. If it did where would the motion/door detection send it's messages for turning on lights etc.

Point d) could also be due to poor signal to the controller either direct or through an other device.

Do you have any constantly powered z-wave devices near your valve? And do you see them as neighbours to your valve?

Do you really need to be able to controll the device that often (300 seconds)?

[Kaz Librowski]

I think what Danfoss are saying is that IF the controller is switched off (for example, it is a stick plugged into a PC that is turned off at night) THEN the Danfoss valve battery life will be affected. This suggests it must be expecting some sort of response from the controller.

I haven't seen this warning on any other battery based z-wave devices, such as PIR detectors. I think they just broadcast their signals and don't much care if anyone is around to hear them or not, so in their case battery life would be unaffected.

I'd like to learn a bit more about this. Has anyone got any pointers to some specs?

[Chris Jackson]

What happens is that at every wakeup period, the device will wake up and send a bunch of data. It sends its status (setpoint, battery and schedule if I remember correctly), and then sends a wakeup notification to alert the controller (ie openHAB) that the device can accept messages.  These messages are normally ACKed by the controller so that the device knows the messages are received. If the controller is not turned on, then the device will repeat this "a number" of times (I don't know how many), and this is probably the issue that Danfoss are talking about (but that's an educated guess). Clearly therefore if the controller is off, and we send these message 2 or 3 times, this is likely to reduce the battery life by about this multiple.

I don't know what the Danfoss is doing, but as far as I know it's not doing anything special - it doesn't seem to support too many command classes, it has no configuration, so I don't think it's got a magical handshake unless they are doing something special. If I remember correctly, they support the manufacturer_proprietary class, which means they can do 'magical' things of their own and it won't be documented, and it can do basically anything. If they are doing something that means they need to talk to 'special' Danfoss software, then this could be an issue (but I doubt this is an issue as it would effectively make it only usable within a Danfoss system rather than within any zwave network).

However, I don't think that this issue is specific to openhab here - if I do a quick web search of "Danfoss battery life" I get a lot of hits from Vera, Zipato, Domotocz, as well as openhab. It seems there are many "problems" with the battery on these units...

I don't have any of these so I can't do any experiments. I would say that if Danfoss don't require their own software to be running in the controller, then probably openhab is doing the same thing as other systems. If there is a need to have special Danfoss software for some reason, then that's a different story and we'd need someone to try and reverse engineer this command class to work out how it works so we can implement it...

Just my thoughts - I'm happy to help debug anything if someone has any thoughts or logs or whatever....

Cheers

Chris

[Kaz Librowski]

Thanks Chris,

I've found where I saw the hint that the problem is likely openhab related:

https://github.com/openhab/openhab/issues/2187

The key phrase is "I was using razberry pi with z-wave.me before and they lasted almost a year. So it somehow has to do with openhab I cannot however figure out what..."

I think your explanation of the retry issue is probably spot on, but since I am using a controller that is always on, the question is why would it have to retry? I'm wondering whether there is a timing issue involved? I.e. if the ack isn't received within a (very) short time, the Danfoss panics? I fear this could be very hard to debug. Is there some way to determine that all incoming messages have been acked?

My controller is a Raspberry Pi, which isn't the fastest device. I'll try moving it onto a Raspberry Pi 2 and see whether that improves matters. If it does that would suggest that OpenHab isn't sending acks fast enough.

 

[Chris Jackson]

I've found where I saw the hint that the problem is likely openhab related:

https://github.com/openhab/openhab/issues/2187

The key phrase is "I was using razberry pi with z-wave.me before and they lasted almost a year. So it somehow has to do with openhab I cannot however figure out what..."

The problem with drawing a conclusion from one email, is that there is often more than one thing that changes at the same time, and the cause of the actual issue is therefore not clear, but people draw conclusions that may not be correct.  As I said, a quick search on the net came up with a lot of hits for other controllers that also have problems with Danfoss batteries.... I'm not saying there's not an issue with OH - I'm just saying that we should be careful when drawing a conclusion like this based on one persons experience...

 

I think your explanation of the retry issue is probably spot on, but since I am using a controller that is always on, the question is why would it have to retry?

RF link quality is the main one, but this is very difficult to quantify. Lots of things will impact how far apart devices can be for good communications - distance, walls, wall thickness, other devices, microwave ovens, antenna orientation between the two ends... Also, just because it works fine in one direction doesn't mean the return link will have the same reliability... Unfortunately there's no good way that I've yet found to establish this - I keep thinking about adding a method to do a load of pings to a device to gather some statistics - the log analyser post processes this information and will flag if retry rate is high, but it's not especially scientific unfortunately.

 

I'm wondering whether there is a timing issue involved? I.e. if the ack isn't received within a (very) short time, the Danfoss panics? I fear this could be very hard to debug. Is there some way to determine that all incoming messages have been acked?

I don't think there's any way of knowing this since the communications is between the device and the controller - openhab doesn't get visibility of the protocol level communications. All we can tell is that at the higher layers we are getting responses to requests we make. In the scenario I mention above, the Danfoss will send a message, the controller will respond to it, and the controller will then send the message to openhab. If the message sent by the Danfoss to the controller (ie stick) gets lost, or if the ACK from the controller back to the Danfoss gets lost, the Danfoss will probably retry. In either case, openhab will not know and there's no way that I know of to find out.

 

My controller is a Raspberry Pi, which isn't the fastest device. I'll try moving it onto a Raspberry Pi 2 and see whether that improves matters. If it does that would suggest that OpenHab isn't sending acks fast enough.

I don't think this will matter - as above, the acks are not from openhab - they come from the stick.

There is one area where OH does have some impact on the power used, and that is with the sending of the 'I've got no more messages to send' message. What happens here is that openhab sends the go to sleep message 2 seconds after it's sent its last message. This delay is there to allow the system to respond in a timely way. For example, if a device sends an update, and you have a rule that responds to that update, then you want the device to stay awake long enough for the system to respond, and any additional messages get sent before it goes to sleep. If we don't have this, then any messages to be sent to a battery device is always 1 wakeup period behind - this might not matter too much if you have a 5 minute wakeup, but for most devices the wakeup is a LOT longer than this in order to improve battery life.  

It might be possible to reduce it to 1 second, or maybe a bit less even - this might help a little. I could either make it configurable, or I could make it a range dependant on the wakeup interval - a shorter  'go to sleep' time might be acceptable when we're waking up every 5 minutes, but I know some people only have a wakeup of 1 day, so we want to make sure everything gets through in this period.

I'm not convinced this will make a huge difference, but it's worth a try as I might be wrong when we have such a small wakeup period. Also, when I implemented this, my thought was that most people had a longer wakeup time (1 hour minimum).  I might do a quick battery life analyses to see if this is likely to make a difference...

Chris

 

[Chris Jackson]

I've done a quick analyses of expected battery life based on a bunch of assumptions on the number of packets transmitted, and the current consumed for TX/RX/sleep (of 25mA, 10mA and 0.1mA respectively). This doesn't account for things like moving motorised valves or battery return factor, conversion efficiency or lots of other things, but it gives an idea of what we might be able to improve by playing with the timer in openhab by looking at the relative values...

The bottom line is that from a protocol perspective alone, there is a significant advantage in reducing the sleep time when using a 5 minute wakeup - you can increase from 1.36 to nearly 2 years by reducing from 2 seconds to 0.5 seconds. If the wakeup period is 1 hour, then the increase isn't as dramatic (2.16 to 2.25 years), and the difference between 1 hour and 1 day wakeup is minimal.  So, from this, we can say that there is a significant gain to reducing this time where the wakeup period is low.

Anyway... What this tells me (from the protocol perspective) is that I should look at reducing the time when the wakeup period is short as it will likely help significantly. I'll have a think about how to implement this.

However, I know the first response I'm going to get is - "this analyses is wrong as I only get 1 month" (or whatever) :). 

I think this should give an idea of what could be achieved for a simple battery device if its well managed and designed. Of course in the case of the valve motor, this will adversely impact the battery life - I don't know how many times this is moving per day - if it's only a few times then it probably doesn't make a lot of difference - if you're changing the valve position every 5 minutes to control the temperature, then that's a different story and we could expect that to have a big impact on the life (potentially around 1 to 2 months based on my quick analyses and assumptions)... 

Battery quality is another issue that can have a dramatic impact - a good AA battery can have a capacity of 2500mAH (or more!), while a cheap rechargeable might be 600mAH.

The fact that people are only getting 1 month as opposed to the ~1 year that I see below may indicate more "severe" issues than just the protocol. If I use myspreadsheet and work backwards to get 1 month, it tells me that we'd have to have the device awake about 50% of the time, or transmitting every second or two. Again, treat these numbers as an indicator as this analyses is rough, but it gives an idea of what would need to be happening to get this battery life.

Anyway.... That's a bit of a brain dump with some food for thought (maybe not too specific to Danfoss). It would be interesting to know how often the valves are operating in these devices though as that's something I'm unclear of...

Chris

(I hope this formats ok...)

Battery capacity	2000	2000	2000	2000	2000	2000	mAH
Wakeup period	300	300	3600	3600	86400	86400	seconds
Receive duration	2	0.5	2	0.5	2	0.5	seconds
Average current	0.17	0.12	0.11	0.10	0.10	0.10	mA
Battery life (days)	494.59	700.34	788.34	820.35	831.36	832.78	days
Battery life (years)	1.36	1.92	2.16	2.25	2.28	2.28	years

[Kaz Librowski]

This is very interesting. I presume the receive duration is currently set quite high to allow for messages to get through in multi-hop/noisy scenarios?

I'm going to whack up my wakeup period to 3600 and see whether that yields an improvement roughly in proportion to what you've calculated.

Good point about the batteries. Manufacturer supplied batteries are typically really cheap affairs, so maybe that's a large part of the problem.

[Chris Jackson]

On Tuesday, 17 March 2015 15:40:56 UTC, Kaz Librowski wrote:

This is very interesting. I presume the receive duration is currently set quite high to allow for messages to get through in multi-hop/noisy scenarios?

No - the 2 seconds is solely to allow openhab to do it's stuff... This is the time that the binding waits for any outstanding messages before telling the device to go to sleep. Previously, this timer didn't exist, and it has the drawback that if there's anything new to send as a result of a received message, we had to wait for the next wakeup period. So, any rule would always be one wakeup period behind. Another issue was during initialisation when we receive a message from the device, and the stage increments, each increment had to wait for the next wakeup... (maybe I'm not explaining that so well?).

The 2 seconds was simply based on the fact that I didn't think it mattered if it was 1 second or 2 seconds - that was based on my assumption at the time that most people were using 1 hour wakeup period, where this is broadly true - with a 5 minute wakeup, it seems it's more of an issue. The time needs to be long enough for the processing of incoming packets, and any rules to run before the device goes to sleep. On something like an RPi, this might take a bit of time, so 2 seconds seemed reasonable...

Anyway, I'll look to reduce it...

Cheers

Chris 

[Chris Jackson]

I've reduced the 2 second timer down to 1 second. This seems to be working fine in my configuration after a few days - hopefully it's still ok on slower machines (I think it should be). I might look at something a bit fancier at some stage (ie based on the wakeup period) or make it configurable, but this ought to help...

Chris