Danfoss Living Connect Z running low on battery

[pacaj2am]

Hello,

I have for a try one Danfoss valve, it works with Razberry, but battery is running quite fast.
On Valve there is flashing alarm and signal. I don't assume, signal is the porblem, because they are 3m separated. In log i can see some strange error about 0x46.

The ocmplete server log for one call is:

[2013-03-22 23:17:24.921] RECEIVED: ( 01 1C 00 04 00 06 16 8F 01 04 03 80 03 56 06 43 03 01 42 05 DC 04 46 08 00 7F 02 84 07 C3 )
[2013-03-22 23:17:24.922] SENT ACK
[2013-03-22 23:17:24.923] SETDATA devices.6.data.lastReceived = 0 (0x00000000)
[2013-03-22 23:17:24.923] SETDATA devices.6.instances.0.commandClasses.128.data.history.86 = 1363990644 (0x514cd874)
[2013-03-22 23:17:24.923] SETDATA devices.6.instances.0.commandClasses.128.data.last = 86 (0x00000056)
[2013-03-22 23:17:24.923] SETDATA devices.6.instances.0.commandClasses.67.data.1.size = 2 (0x00000002)
[2013-03-22 23:17:24.924] SETDATA devices.6.instances.0.commandClasses.67.data.1.precision = 2 (0x00000002)
[2013-03-22 23:17:24.924] SETDATA devices.6.instances.0.commandClasses.67.data.1.scale = 0 (0x00000000)
[2013-03-22 23:17:24.924] SETDATA devices.6.instances.0.commandClasses.67.data.1.scaleString = "grd C"
[2013-03-22 23:17:24.924] SETDATA devices.6.instances.0.commandClasses.67.data.1.val = 15.000000
[2013-03-22 23:17:24.924] SETDATA devices.6.instances.0.commandClasses.67.data.1.setVal = 15.000000
[2013-03-22 23:17:24.925] SETDATA devices.6.instances.0.commandClasses.67.data.1 = Empty
[2013-03-22 23:17:24.925] Node 6:0 CC MultiCmd: Received command, but CC 0x46 isn't registered. Creating it as not supported
[2013-03-22 23:17:24.925] Trying to create command for unknown CC 0x46
[2013-03-22 23:17:24.925] Error returned from _zway_cc_call_handler(zway, cmd, node_id, instance_id, len, &data[idx + 1]): Bad arguments
[2013-03-22 23:17:24.925] Node 6:0 CC Wakeup: Wakeup notification
[2013-03-22 23:17:24.925] SETDATA devices.6.instances.0.commandClasses.132.data.lastWakeup = 1363990644 (0x514cd874)
[2013-03-22 23:17:24.926] SETDATA devices.6.data.isAwake = True
[2013-03-22 23:17:24.926] Running wakeup handler for node 6
[2013-03-22 23:17:24.926] SETDATA devices.6.instances.0.commandClasses.132.data.lastSleep = 1363990644 (0x514cd874)
[2013-03-22 23:17:24.926] Node 6:0 CC Wakeup: Send node to sleep
[2013-03-22 23:17:24.926] Adding job: Wakeup Sleep
[2013-03-22 23:17:24.927] SENDING (cb 0x98): ( 01 09 00 13 06 02 84 08 05 98 F0 )
[2013-03-22 23:17:24.938] RECEIVED ACK
[2013-03-22 23:17:24.948] RECEIVED: ( 01 04 01 13 01 E8 )
[2013-03-22 23:17:24.949] SENT ACK
[2013-03-22 23:17:24.949] Delivered to Z-Wave stack
[2013-03-22 23:17:24.959] RECEIVED: ( 01 05 00 13 98 00 71 )
[2013-03-22 23:17:24.960] SENT ACK
[2013-03-22 23:17:24.960] Job 0x13 (Wakeup Sleep): Delivered
[2013-03-22 23:17:24.961] SendData Response with callback 0x98 received: received by recipient
[2013-03-22 23:17:24.961] SETDATA devices.6.data.lastSend = 14841356 (0x00e2760c)
[2013-03-22 23:17:24.961] Job 0x13 (Wakeup Sleep): success
[2013-03-22 23:17:24.961] SETDATA devices.6.data.isAwake = False
[2013-03-22 23:17:24.961] Sending the queue for node 6 into sleep
[2013-03-22 23:17:24.961] Removing job: Wakeup Sleep
[2013-03-22 23:17:43.846] Job 0x13: deleted from queue


in manual to Valve there is written, that controller should support SUC, can this help? If i try to introduce SUC, it fails

[2013-03-22 23:38:36.880] Adding job: Set new SUC/SIS
[2013-03-22 23:38:36.885] SENDING (cb 0x9d): ( 01 08 00 54 01 01 00 00 9D 3E )
[2013-03-22 23:38:36.896] RECEIVED ACK
[2013-03-22 23:38:36.907] RECEIVED: ( 01 04 01 54 00 AE )
[2013-03-22 23:38:36.908] SENT ACK
[2013-03-22 23:38:36.908] Job 0x54 (Set new SUC/SIS): Failed
[2013-03-22 23:38:36.908] Job 0x54 (Set new SUC/SIS): fail
[2013-03-22 23:38:36.908] Removing job: Set new SUC/SIS
[2013-03-22 23:38:55.796] Job 0x54: deleted from queue
[2013-03-22 23:38:59.793] Adding job: Set new SUC/SIS
[2013-03-22 23:38:59.796] SENDING (cb 0x9e): ( 01 08 00 54 01 01 00 00 9E 3D )
[2013-03-22 23:38:59.807] RECEIVED ACK
[2013-03-22 23:38:59.818] RECEIVED: ( 01 04 01 54 00 AE )
[2013-03-22 23:38:59.818] SENT ACK
[2013-03-22 23:38:59.819] Job 0x54 (Set new SUC/SIS): Failed
[2013-03-22 23:38:59.819] Job 0x54 (Set new SUC/SIS): fail
[2013-03-22 23:38:59.819] Removing job: Set new SUC/SIS


How could I introduce SUC? Does razberry has this functionality?

Thank you

Jan

[pz1]

Stay away from Danfoss LC as far as you can. It is a bad unreliable device that causes lots of problems with many softwares. The built-in daily temperature scheduler is seriously flawed, and afaik none of the home automation softwares have been able to use it for control. All off them manage schedules by themselves. Danfoss knows about the problems but is not really helping out. In their datasheets they still claim: living connect® is a electronic radiator thermostat. It can be controlled by either a Danfoss Link TM CC (Central Controller) or a Z-Wave certified controller This is just not true.
Not informing customers about the fragility of this device when operated outside the Danfoss world (and thereby confirming that it should not have gotten the Z-Wave compliance label) is i.m.h.o. not a correct business practice to put it mildly.

I leave it to the site owners to respond to the SUC issue. That seems to be possible, but it is at the cost of loosing the Network Wide Inclusion function

[pacaj2am]

It seems to me to work quite well.... I have in cron several time-updates and I have several thermometers (wireless RFM12B based) and I see it works pretty well.

What device should I use insead of danfoss?

Thank you

Jan

[PoltoS]

The blinking alarm on DLC means it is in panic mode and is asting batteries. The reason is that it was not able to find RaZberry once (while it was unpowered). A bug in DLC prevents it to restore from panic after succesful communication with the controller. So, only battery removal for 1 sec is a solution. Indeed, SUC/SIS support in RaZberry will solve the problem, so a downgrad to older SDK will help, but you will loose many other good functions - it is not possible to have all of them due to memory limit.

Plese wait a bit, there would be other thermostats soon.

[pacaj2am]

What functions will i loose if i downgrade? Will SUC help (will it prevent emergency state)?

The second part is - razberry is running all the time, there was no downtime. So i was surprised, it started to blink?

Thank you for reply.

I Made one test:
I disconnected battery for a while, flasshing of alarm and antena stopped. After hour and half i came back and it was flashing again. I checked the log and no packet was lost (I had every packet avery 5 minutes logged), but htis communication was little longer, cant the problem be here:

[2013-03-24 03:20:30.252] RECEIVED: ( 01 16 00 49 84 06 10 04 08 04 80 46 81 72 8F 75 43 86 84 EF 46 81 8F 13 )
[2013-03-24 03:20:30.254] SENT ACK
[2013-03-24 03:20:30.254] Node info received: 6
[2013-03-24 03:20:30.254] SETDATA devices.6.data.basicType = 4 (0x00000004)
[2013-03-24 03:20:30.255] SETDATA devices.6.data.genericType = 8 (0x00000008)
[2013-03-24 03:20:30.255] SETDATA devices.6.data.specificType = 4 (0x00000004)
[2013-03-24 03:20:30.257] SETDATA devices.6.data.deviceTypeString = "Thermostat"
[2013-03-24 03:20:30.257] SETDATA devices.6.data.nodeInfoFrame = byte[13]
( 80 46 81 72 8F 75 43 86 84 EF 46 81 8F )
[2013-03-24 03:20:30.258] SETDATA devices.6.data.lastReceived = 0 (0x00000000)
[2013-03-24 03:20:30.258] SETDATA devices.6.data.isAwake = True
[2013-03-24 03:20:30.259] Running wakeup handler for node 6
[2013-03-24 03:20:30.259] SETDATA devices.6.instances.0.commandClasses.132.data.lastSleep = 1364091630 (0x514e62ee)
[2013-03-24 03:20:30.259] Node 6:0 CC Wakeup: Send node to sleep
[2013-03-24 03:20:30.259] Adding job: Wakeup Sleep
[2013-03-24 03:20:30.271] SENDING (cb 0x0a): ( 01 09 00 13 06 02 84 08 05 0A 62 )
[2013-03-24 03:20:30.282] RECEIVED ACK
[2013-03-24 03:20:30.293] RECEIVED: ( 01 04 01 13 01 E8 )
[2013-03-24 03:20:30.293] SENT ACK
[2013-03-24 03:20:30.293] Delivered to Z-Wave stack
[2013-03-24 03:20:30.304] RECEIVED: ( 01 05 00 13 0A 00 E3 )
[2013-03-24 03:20:30.304] SENT ACK
[2013-03-24 03:20:30.305] Job 0x13 (Wakeup Sleep): Delivered
[2013-03-24 03:20:30.305] SendData Response with callback 0x0a received: received by recipient
[2013-03-24 03:20:30.305] SETDATA devices.6.data.lastSend = 23814116 (0x016b5fe4)
[2013-03-24 03:20:30.305] Job 0x13 (Wakeup Sleep): success
[2013-03-24 03:20:30.305] SETDATA devices.6.data.isAwake = False
[2013-03-24 03:20:30.306] Sending the queue for node 6 into sleep
[2013-03-24 03:20:30.306] Removing job: Wakeup Sleep
[2013-03-24 03:20:33.005] RECEIVED: ( 01 1C 00 04 00 06 16 8F 01 04 03 80 03 53 06 43 03 01 42 05 DC 04 46 08 00 7F 02 84 07 C6 )
[2013-03-24 03:20:33.007] SENT ACK
[2013-03-24 03:20:33.007] SETDATA devices.6.data.lastReceived = 0 (0x00000000)
[2013-03-24 03:20:33.008] SETDATA devices.6.instances.0.commandClasses.128.data.history.83 = 1364091633 (0x514e62f1)
[2013-03-24 03:20:33.008] SETDATA devices.6.instances.0.commandClasses.128.data.last = 83 (0x00000053)
[2013-03-24 03:20:33.008] SETDATA devices.6.instances.0.commandClasses.67.data.1.size = 2 (0x00000002)
[2013-03-24 03:20:33.008] SETDATA devices.6.instances.0.commandClasses.67.data.1.precision = 2 (0x00000002)
[2013-03-24 03:20:33.009] SETDATA devices.6.instances.0.commandClasses.67.data.1.scale = 0 (0x00000000)
[2013-03-24 03:20:33.009] SETDATA devices.6.instances.0.commandClasses.67.data.1.scaleString = "grd C"
[2013-03-24 03:20:33.009] SETDATA devices.6.instances.0.commandClasses.67.data.1.val = 15.000000
[2013-03-24 03:20:33.009] SETDATA devices.6.instances.0.commandClasses.67.data.1.setVal = 15.000000
[2013-03-24 03:20:33.010] SETDATA devices.6.instances.0.commandClasses.67.data.1 = Empty
[2013-03-24 03:20:33.010] Node 6:0 CC MultiCmd: Received command, but CC 0x46 isn't registered. Creating it as not supported
[2013-03-24 03:20:33.010] Trying to create command for unknown CC 0x46
[2013-03-24 03:20:33.010] Error returned from _zway_cc_call_handler(zway, cmd, node_id, instance_id, len, &data[idx + 1]): Bad arguments (-1)
[2013-03-24 03:20:33.010] Node 6:0 CC Wakeup: Wakeup notification
[2013-03-24 03:20:33.011] SETDATA devices.6.instances.0.commandClasses.132.data.lastWakeup = 1364091633 (0x514e62f1)
[2013-03-24 03:20:33.011] SETDATA devices.6.data.isAwake = True
[2013-03-24 03:20:33.011] Running wakeup handler for node 6
[2013-03-24 03:20:33.011] SETDATA devices.6.instances.0.commandClasses.132.data.lastSleep = 1364091633 (0x514e62f1)
[2013-03-24 03:20:33.012] Node 6:0 CC Wakeup: Send node to sleep
[2013-03-24 03:20:33.012] Adding job: Wakeup Sleep
[2013-03-24 03:20:33.012] SENDING (cb 0x0b): ( 01 09 00 13 06 02 84 08 05 0B 63 )
[2013-03-24 03:20:33.023] RECEIVED ACK
[2013-03-24 03:20:33.033] RECEIVED: ( 01 04 01 13 01 E8 )
[2013-03-24 03:20:33.034] SENT ACK
[2013-03-24 03:20:33.034] Delivered to Z-Wave stack
[2013-03-24 03:20:33.045] RECEIVED: ( 01 05 00 13 0B 00 E2 )
[2013-03-24 03:20:33.045] SENT ACK
[2013-03-24 03:20:33.045] Job 0x13 (Wakeup Sleep): Delivered
[2013-03-24 03:20:33.046] SendData Response with callback 0x0b received: received by recipient
[2013-03-24 03:20:33.046] SETDATA devices.6.data.lastSend = 23814359 (0x016b60d7)
[2013-03-24 03:20:33.046] Job 0x13 (Wakeup Sleep): success
[2013-03-24 03:20:33.046] SETDATA devices.6.data.isAwake = False
[2013-03-24 03:20:33.046] Sending the queue for node 6 into sleep
[2013-03-24 03:20:33.046] Removing job: Wakeup Sleep
[2013-03-24 03:20:49.228] Job 0x13: deleted from queue
[2013-03-24 03:20:51.919] Job 0x13: deleted from queue

[pz1]

FWIW, I have tested DLC for a year now (mostly with Z-Cloud), and indeed I have observed periods of a couple of weeks that it was stable. But to meet specifications for the device, the batteries should last 2 years of normal service. It is the long term that counts, and a radiator thermostat is an longer term investment (not consumer) device that you should not have to look at to often.

[pacaj2am]

what does it mean stable? Was there problem, that they were not changing temperature on schedule? Did you try RAM batteries?¨¨Thank oyu

Jan

[pz1]

1) The stability issue was that the device panicked and made the battery lost power quickly. From 100% to dead in slightly over 24 hours. This happened several times. I had periods of prolonged stability in the sense that the powerlevel stayed the same for several weeks. From the top of my head, the longest period was 3-4 weeks. BUT this stability coincided with the fact that I did not touch any thermostat settings in that period.
2) My major issue was that the built-in schedule does not work properly. I try to design my HA as autonomous as possible, so it still has the essential (safe) functionality if the central controller fails. To some extend my controller would act as a remote terminal to do the settings on the DLC. I think no one outside Danfoss has achieved that (Maybe Danfoss hasn't, as I never received an answer on such questions)
3) If I had programmed a temeperature cycle with different day/night temperatures, even after several weeks the DLC started assuming the new temperature 2-2.5 hours after the time I had specified. I this and other fora there are mixed experiences. Some people report behaviour as I see it, others report correct timings.

These three observations are part of what I called "unstable"
I did use Duracell PlusPower batteries
Pieter

[pacaj2am]

And what do you actually use? I don't see any other similar system.

Thank you

Jan

[PoltoS]

The communication seems to be ok. We don't know how DLC behaves exactly, but probably a single undelivered packet (due to RF problems) can cause a panic.

With 5.03 you will loose NWI (easy inclusion), ExplorerFrames (automatic network reorganization), random HomeId (no phantom devices after reset of the controller).