[patch] Danfos Living Connect Z support (014G0012)

[GoogleCodeExporter]

Hello,

Attached is a patch to improve support the Danfoss Living Connect Z Thermostat 
(014G0012).

Apparently, the main difference with the previous Living Connect is that the 
base for setpoint description is 0 and not 1 (without the patch, the setpoint 
is incorrectly identified as Cooling 1 instead of Heating 1 and does not work).

I also needed to disable the BASIC command class as the thermostat does not 
respond to it and that creates unnecessary timeouts.

Finally, I disable the climate schedule and clock command classes which have 
been reported elsewhere to be unstable (although this is apparently not 
strictly necessary for correct operation with the THERMOSTAT_SETPOINT command 
class, so you may want to ignore that part).

With the patch, I can read and set the setpoint and the thermostat is stable: 
after initial setup, reported battery level did not drop after one week of 
continuous operation.

Tested with Aeon Z-Stick 2 in SUC mode and inclusion through a minimote.

Regards,

-sbi

Original issue reported on code.google.com by stephane...@gmail.com on 20 Apr 2013 at 10:46

Attachments:

• patch-zthermostat.txt

[GoogleCodeExporter]

Thank you! I was dealing with this (014G0012 v2.51) as well. I will try your 
patch tonight.

Is the minimote + Z-Stick in SUC mode really needed? So far I have no minimote, 
just the Aeon stick... and the inclusion was really painful. What minimote are 
you using?

Kind regards and thank you!
Jorge

Original comment by jorg...@gmail.com on 22 Apr 2013 at 8:24

[GoogleCodeExporter]

The minimote I mentioned is an older Aeon one (now 
http://aeotec.com/small-z-wave-remote-control).

As SUC is mentioned explicitly in the Danfoss manual, I assumed it was safer. 
And since my valve is not close enough to the machine with the Z-Stick, I had 
to include it indirectly through the minimote. I assume it's not necessary if 
the valve is close enough to the Z-Stick. 

Some experts around here might clarify or correct me on this topic.

In the meantime, the battery dropped 1% after 8 days, so it looks more or less 
consistent with advertised the 2 years lifespan.

Original comment by stephane...@gmail.com on 22 Apr 2013 at 4:05

[GoogleCodeExporter]

Are there any incompatibles with this patch to previous versions of this device?

Original comment by glsatz on 22 Apr 2013 at 4:06

[GoogleCodeExporter]

As far as I can tell by reading the forum, the previous version of the device 
as a different id and is configured in danfoss/living.xml. So this patch should 
be safe in that respect.

Original comment by stephane...@gmail.com on 22 Apr 2013 at 4:08

[GoogleCodeExporter]

Hi,

I've just applied your patch and the Danfoss Living Connect Z (Danfoss Z 
Thermostat 014G0012 Application Version: v2.51) is working fine here, I can 
set/read the "Heating 1" setpoint now :)

The only flaw I have seen so far is the Danfoss going into panic mode (alarm 
bell and antenna icon flashing in display which means "not connected", which 
means it will run out of battery in ~ 24/48 hours) if I restart open-zwave. 
After open-zwave has started, the radiator valve "reconnects" if I do what 
Danfoss describes as "Testing the connection" (http://goo.gl/0T6zN section 4.2)

Long story short, so far if I restart my raspberry (and therefore open-zwave) I 
will have to manually "reconnect" each Danfoss device. Not nice.... 

The Z-Stick is not in SUC mode, don't know if that would make any difference. 

Bottom line: your patch works great, a bit disappointed on Danfoss Living 
Connect Z

Thanks!!!

Original comment by jorg...@gmail.com on 22 Apr 2013 at 8:59

[GoogleCodeExporter]

Hi Jorge,

Good to see it works for you. 

I also experienced panic mode when the server stopped. I still need to do more 
tests to see if SUC mode helps.

Out of curiosity, which software do you use on the raspberry to control the 
valve?

-sbi

Original comment by stephane...@gmail.com on 23 Apr 2013 at 8:10

[GoogleCodeExporter]

Pertaining to the above lines:

  <!-- we don't want the valve's climate control schedule: unreliable -->
  <CommandClass id="70" action="remove" />
  <!-- we don't want the valve's clock: not needed without climate control schedule -->
  <CommandClass id="129" action="remove" />

Are these removal actions necessary? Removing functionality for all users of 
the device is heavy handed unless they are broken and non-responsive. Thanks.

Original comment by glsatz on 23 Apr 2013 at 2:43

[GoogleCodeExporter]

Hi,

Command classes 70 and 129 are responsive. On the z-wave.me forum they were 
reported as unreliable, and they are quite difficult to program compared to 
THERMOSTAT_SETPOINT ;).

But you are right, since they are responsive, it's better to leave them enabled 
by default.

-sbi

Original comment by stephane...@gmail.com on 23 Apr 2013 at 5:29

[GoogleCodeExporter]

reference to the discussion about the climate schedule command class:
http://en.z-wave.me/content/disable-climate-schedule-control-command-class-fallb
ack-default-support-danfoss-living

Original comment by stephane...@gmail.com on 23 Apr 2013 at 6:13

[GoogleCodeExporter]

@Jorge,

I confirm the valve goes into panic mode when ozw is stopped, even if the 
Z-Stick is in SUC mode.

When restarting ozw, the valve communicates again with ozw and seems to work 
normally, but it remains in panic mode and draining battery.

I've read hints that it should be possible to recover from panic mode by 
sending commands (hence without physically manipulating the valve), but I don't 
know how.

-sbi

Original comment by stephane...@gmail.com on 23 Apr 2013 at 6:17

[GoogleCodeExporter]

Add in r658. Thanks for taking the time to research and include this patch.

Original comment by glsatz on 23 Apr 2013 at 8:36

• Changed state: Done

[GoogleCodeExporter]

@sbi Thank you for testing. I will keep trying to recover from panic mode 
without manually interacting with the valve. The only thing that come to my 
mind is forcing a neighbour update...?

Or just open the valve, keep the engine and put an arduino for controlling it. 
I'll probably lose the display but it will just work.

Original comment by jorg...@gmail.com on 23 Apr 2013 at 9:17