Danfoss Living Connect

[peterb]

Hallo Zusammen,

ich bin gerade dabei erste Schritte mit FHEM auf einem Raspberry zu machen. Das Einbinden einer HUE Bridge und die Presence Funktion laufen prima. Als nächstes ist die Heizungssteuerung drann. Und hier gibt es Probleme.

Mein Setup:

- RaspberryPi mit Aeon ZStick 2
- Danfoss Living Connect (014G0012)
- Everspring Temperatur- und Feuchtigkeitssensor ST814

Die Z-Wave Komponenten sind alle verbunden, und die Kommunikation klappt prinzipiell (Batterie Status kann bspw. ausgelesen werden).

Was nicht geht, ist das Auslesen der (Temperatur) Werte aus dem LivingConnect und dem Everspring Sensor. Das setzten der Werte beim LivingConnect demnach auch nicht. Was ich glaube verstanden zu haben ist, dass autocreate die verfügbaren Klassen ausliest, ohne das diese von FHEM auch angesteuert werden müssen. Dies würde in 10_ZWave.pm eine Definition voraussetzen.

Ist das korrekt? Oder habe ich es nicht richtig verstanden. Falls es gehen sollte, wäre ich für einen Hinweis dankbar!

Viele Grüße

Peter

[rudolfkoenig]

> Ist das korrekt?

Nein. Autocreate legt die Geraete an, mit evtl. passenden FileLogs.

Das Problem ist vermutlich, dass die problematischen Geraete bestimmte Klassen implementieren, die in FHEM (noch) nicht implementiert sind. Die in FHEM implementierten Klassen sind dokumentiert: http://fhem.de/commandref.html#ZWave , die vom Geraet implementierten Klassen sieht man in den automatisch angelegten FHEM Attribut classes.

Die Implementierung neuer Klassen in FHEM erfordert vermutlich keine Programmierung sondern "nur" die Ergaenzung der %zwave_class Datenstruktur in fhem/FHEM/10_ZWave.pm, das wiederum erfordert aber Doku studieren und etwas Zeit.

[peterb]

Ich glaube, wir meinen dasselbe. Auf jeden Fall habe ich mich mal etwas schlau gemacht:

Auf ein requestSetpointVal erhalte ich folgende Antwort:

01 0C 00 04 00 03 06 43 03 01 42 08 34 CD

Interessant sind hier die Hex Werte 10 - 13, also:

01 42 08 34

01 steht für Heating (00 für cooling)

42 ist eine Bitmaske, binär 01000010
Die ersten drei Bits 010 stehen für eine Genauigkeit von 2 Stellen.
Die nächsten zwei Bits stehen für °C (01 für °F).
Die letzten drei Bits 010 bedeuten, der Wert steht in zwei Bytes, nämlich

08 und 34 --> ergibt 2100, also
21,00°C

Jetzt bräuchte ich einen Tipp, wie ich die 10_Zwave.pm anpassen muss.

Meine Vermutung:

THERMOSTAT_SETPOINT      => { id => '43', },

wird zu:

THERMOSTAT_SETPOINT                 => { id => '43',
    get   => { Setpoint     => "02" }, },

Die 02 ist laut OpenZwave das Kommando für ThermostatSetpointCmd_Get. Soweit so gut, einen Rückgabewert bekomme ich noch nicht, weil der Parser noch fehlt. Und habe ich tatsächlich keine Idee was da rein muss...

Peter, für Hilfe dankbar

[rudolfkoenig]

Wo kommen deine Daten fuer requestSetpointVal her?

Das Zwave Modul macht keinen Unterschied zw. Antworten auf get und spontanen Meldungen des Geraetes, beides wird mit parse verarbeitet. Dein get Eintrag ist vermutlich korrekt, zusaetzlich ist noch ein parse notwendig, in etwa so (natuerlich ungetestet :)

parse => { "03(..)(..)(....)" => 'sprintf("temperature: %g %s %s", hex($3)/(10**(int(hex($2)/32)), hex($2)&8 ? "F":"C", $1==1 ? "heating":"cooling")' },

Man koennte ueberlegen eine Funktion zu bauen, um die Werte schoener auswerten zu koennen.

[peterb]

Ich teste gerade mit OpenZwave und einer Demoversion von Indigo. OpenZwave finde ich ja prinzipiell sehr interessant, allerdings weiß ich nicht wie aktiv daran noch gearbeitet wird.

Zu meinem Setup: In 10_Zwave.pm habe ich jetzt folgende Änderung eingebaut:

THERMOSTAT_SETPOINT      => { id => '43',
get => { ThermostatSetpoint => "02" },
parse => { "03(..)(..)(....)" => 'sprintf("temperature: %g %s %s", hex($3)/(10**(int(hex($2)/32)), hex($2)&8 ? "F":"C", $1==1 ? "heating":"cooling")' },},

Die Abfrage taucht in der Weboberfläche auf, ein abgeschicktes "get ThermostatSetpoint" löst im FHEM Logfile folgenden Eintrag aus:

ZWave get ZWave_THERMOSTAT_5 ThermostatSetpoint

Aber es gibt keinen Rückgabewert. Bei Verbose = geschwätzig sieht es schon etwas anders aus:


2013.09.06 08:55:02 2: ZWave get ZWave_THERMOSTAT_5 ThermostatSetpoint
2013.09.06 08:56:10 5: ZWDongle/RAW: /0122000400051c8f0106038003ff06430301420834044608007f0281050246040284077c
2013.09.06 08:56:10 5: SW: 06
2013.09.06 08:56:10 5: ZWDongle_Read ZWDongle_0: 000400051c8f0106038003ff06430301420834044608007f028105024604028407
2013.09.06 08:56:10 4: ZWDongle_0 APPLICATION_COMMAND_HANDLER 05 (1c8f0106038003ff06430301420834044608007f028105024604028407)
2013.09.06 08:56:10 4: ZWave_THERMOSTAT_5: Unknown message (UNKNOWN 1c8f0106038003ff06430301420834044608007f028105024604028407)

Die Abfolge 01 42 08 34 taucht in den Zeilen auf, exemplarisch in der ersten Zeile bold markiert. Um sicherzugehen, dass es sich nicht um ein zufälliges Statustelegramm handelt, habe ich am Regler die Temperatur um ein Grad auf 22° erhöht, und eine neue Abfrage abgeschickt:

2013.09.06 09:26:31 2: ZWave get ZWave_THERMOSTAT_5 ThermostatSetpoint
2013.09.06 09:26:39 5: ZWDongle/RAW: /0122000400051c8f0106038003ff06430301420898044608007f028105024604028407d0
2013.09.06 09:26:39 5: SW: 06
2013.09.06 09:26:39 5: ZWDongle_Read ZWDongle_0: 000400051c8f0106038003ff06430301420898044608007f028105024604028407
2013.09.06 09:26:39 4: ZWDongle_0 APPLICATION_COMMAND_HANDLER 05 (1c8f0106038003ff06430301420898044608007f028105024604028407)
2013.09.06 09:26:39 4: ZWave_THERMOSTAT_5: Unknown message (UNKNOWN 1c8f0106038003ff06430301420898044608007f028105024604028407)

Hurra! Es taucht jetzt 01 42 08 98 auf, also 0898 (hex) = 2200 (dez.).

Der Parser kann aber anscheinend noch nicht mit den Nachrichten umgehen. Außerdem ist mir unklar, warum es drei unterschiedliche Telegramme gibt. Also die Zeilen beginnend mit 0122, 0004 und 1c8f. Ich gehe davon aus, dass die Zeile "ZWDongle_Read ZWDongle_0: 0004...." die Antwort ist, aber warum wird die darauf folgende Zeile mit "Unknown message" markiert, und was ist die erste Zeile beginnend mit 0122?

Die Battery Abfrage liefert auch keinen Rückgabewert. Im Log steht:

2013.09.06 09:42:25 2: ZWave get ZWave_THERMOSTAT_5 battery
2013.09.06 09:42:33 5: ZWDongle/RAW: /0122000400051c8f0106038003ff06430301420898044608007f028105024604028407d0
2013.09.06 09:42:33 5: SW: 06
2013.09.06 09:42:33 5: ZWDongle_Read ZWDongle_0: 000400051c8f0106038003ff06430301420898044608007f028105024604028407
2013.09.06 09:42:33 4: ZWDongle_0 APPLICATION_COMMAND_HANDLER 05 (1c8f0106038003ff06430301420898044608007f028105024604028407)
2013.09.06 09:42:33 4: ZWave_THERMOSTAT_5: Unknown message (UNKNOWN 1c8f0106038003ff06430301420898044608007f028105024604028407)

Der Parser Suchstring 03 80 03 steht allerdings im Log (s.o.).

Irgendeine Idee was ich ausprobieren könnte? Hoffentlich sind das jetzt nicht zuviele Fragen auf einmal :)

Gruß

Peter

[rudolfkoenig]

Bitte solche Tests immer mit der neuesten Version von FHEM (Stichwort update) durchfuehren, damit haette man sehen koennen, dass es sich um ein MULTI_CMD handelt, damit verpackt ZWave mehrere Nachrichten in eine. Ich habe MULTI_CMD jetzt implementiert, und auch THERMOSTAT_SETPOINT/parse+get eingecheckt, es ist per update morgen ab 8 verfuegbar, vorher nur per SVN.

Die unten aufgefuehrten Kombi-Nachrichten enthaelten jeweils 6 Einzelne:

Code Auswählen Erweitern

battery: 255 %
temperature:  22.0 C heating
Unknown message (CLIMATE_CONTROL_SCHEDULE 044608007f)
Unknown message (CLOCK 028105)
Unknown message (CLIMATE_CONTROL_SCHEDULE 024604)
wakeup: notification

Um die unbekannten Nachrichten auch zu sehen setzt man am besten verbose 4 fuer das ZWave-Geraet.

[peterb]

Super! Der SVN Checkout funktioniert:

==> ZWave_THERMOSTAT_5-2013.log <==
2013-09-06_14:09:25 ZWave_THERMOSTAT_5 battery: 255 %
2013-09-06_14:09:25 ZWave_THERMOSTAT_5 temperature: 21.0 C heating
2013-09-06_14:09:25 ZWave_THERMOSTAT_5 wakeup: notification

Allerdings frage ich mich, was ich für Batterien habe :)

Ich werde jetzt mal versuchen, wieweit ich mit dem Set Kommando komme...


1000 Dank erst mal

Gibt es übrigens irgendwo ein Dokument, wo die ZWave Befehlssequenzen erläutert sind? Ich habe jedenfalls nichts gefunden.


Gruß

Peter

[rudolfkoenig]

Mwn nicht offiziell. Aber wenn man nach SDS11060 sucht...

[peterb]

Das war hilfreich, vielen Dank dafür!

Ich habe jetzt eine Ergänzung für die 10:_Zwave.pm, und zwar lässt sich der Setpoint wie folgt setzen:

  THERMOSTAT_SETPOINT      => { id => '43',
    set   => { setpoint    => "01%02x%02x%02x",},...
    get   => { setpoint => "02" },
    parse => { "064303(..)(..)(....)" => 'sprintf("temperature:%0.1f %s %s", '.
                 'hex($3)/(10**int(hex($2)/32)), '.
                 'hex($2)&8 ? "F":"C", $1==1 ? "heating":"cooling")' }, },

Der erste Parameter im Set Befehl ist der SetpointType (1 für Heating), der zweite die Bekannte Bitmaske wie im Posting vom 29 August dargestellt, der dritte der Wert selbst.

In der FHEM Eingabemaske würde mann dann einsetzen:

"1 1 20"

Also, Heating (01), Wert steht in einem Byte mit 0 Nachkommastellen in C, und den Temperaturwert selbst (20°C).

Das klappt bei mir, allerdings setzt das die Kenntnis über den Aufbau der Bitmaske voraus. Besser wäre es ev. die Bitmaske in der 10_Zwave fest zu definieren?

Viele Grüße

Peter

[rudolfkoenig]

Ich schlage setpointHeating / setpointCooling vor mit jeweils ein Parameter. Wenn es sich rausstellt, dass es zu wenig ist, kann man weiter nachdenken. Lieber einfach, als unnoetig kompliziert.

[peterb]

Das sehe ich auch so. O.K., ich bastel mal einen Ausdruck zusammen, und poste diesen.

Zum Danfoss selbst mal eine Frage:

Ich finde das Gerät insgesamt ja sehr gut verarbeitet, es sieht auch optisch ganz ansprechend aus, nur es funktioniert nicht zuverlässig...!

Zunächst einmal hat Danfoss eine ClimateSchedule Klasse implementiert, die angeblich zukünftig wieder entfallen soll, da unzuverlässig. In einem Forum wurde empfohlen vor der Inklusion im Controller diese Klasse zu deaktivieren, dann die Inklusion durchzuführen. Dadurch deaktiviert der DLC sie angeblich auch. Das müsste ich mal ausprobieren.

Viel schwerwiegender ist allerdings, dass das Gerät regelmäßig in den "Panic Mode" geht. Z. B. weil es den Controller nicht findet, oder ein ungültiges Telegramm erhalten hat. In diesem Falle versucht es wohl permanent eine Antwort vom Controller zu erhalten, und funkt die Batterien innerhalb weniger Tage leer. Ich habe noch keine richtige Strategie, wie ich das eruieren kann. Falls jemand hier von dem Problem schon mal gehört hat, wäre ich für eine Nachricht dankbar.

Gibt es bspw. ein Telegramm "Alles ist gut mit Netzwerk"? Ich habe jedenfalls nicht gefunden...

Und den Danfoss Support kann man getrost als nicht existierend beschreiben. Jedenfalls antworten die nicht.


Viele Grüße

Peter

[rudolfkoenig]

> ... vor der Inklusion im Controller diese Klasse zu deaktivieren, dann die Inklusion durchzuführen

Entweder ist das fuer FHEM nicht relevant, oder es muss noch implementiert werden, ich habe aber z.Zt. noch keine Ahnung wo und wie :)

> Gibt es bspw. ein Telegramm "Alles ist gut mit Netzwerk"?

Nicht das ich wuesste, allerdings unterstuetzt FHEM auch noch nicht das manipulieren der Zwave-Netzwerk-(Re-)Organisation. Ich wuerde "verbose" fuer das ZWave Geraet und das Dongle auf 5 setzen, und versuchen es in Panic-Mode zu versetzen. Dann muesste man sehen, wonach es schreit.

[jody]

Hallo fhem'ler

Ich bin seit kurzem auch Bestitzer eines Danfoss Living Connect Z Thermostats. Das pairing mit fhem hat ohne Probleme funktioniert, nur leider weiß ich jetzt nicht wie ich eine temperatur setzten kann.

Die kommunikation mit dem Thermostat funktioniert auch nicht, ich kann nichtmal den Battery Status abfragen.

Bin euch für jeden Tipp dankbar.

Vielen Dank

Jody

[rudolfkoenig]

Welche Klassen wurden denn erkannt?

[jody]

Hallo Rudolf,

folgende classes wurden erkannt:

Code Auswählen Erweitern


attr ZWave_THERMOSTAT_4 classes BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD