Danfoss Living Connect

Begonnen von peterb, 18 August 2013, 19:37:07

Vorheriges Thema - Nächstes Thema

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:
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
Cubietruck
CUL SlowRF
CUL Homematic
ZWave

rudolfkoenig

Welche Klassen wurden denn erkannt?

jody

Hallo Rudolf,

folgende classes wurden erkannt:


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
Cubietruck
CUL SlowRF
CUL Homematic
ZWave

rudolfkoenig

Den Vorschlag von peterb (siehe oben) THERMOSTAT_SETPOINT, set Befehl, mit 3 Parameter habe ich noch nicht eingebaut, weil ich es fuer nicht benutzerfreundlich halte, und auf meinem Vorschlag kam noch keine Reaktion.

Die komfortablere Klasse CLIMATE_CONTROL_SCHEDULE scheint Danfoss selbst nicht zu moegen, siehe Kommentar von peterb.

matze86

Hallo Zusammen,

ich bin relativ neu in fhem und zwave und hatte mit dem "Danfoss Living Connect Z" das gleiche Problem wie Jody.
Hauptproplem war nicht die fehlende set Möglichkeit (Jetzt weiß ich ja dass das noch nicht eingebaut ist.) sondern das der Living Connect auf keinerlei get Befehle reagiert hat.

Dem "Danfoss Installation Guide" kann man entnehmen, dass nach dem Include ein "set WakeupInterval" notwendig ist.
Also habe ich aus fhem ein "set WakeupInterval 300 1" und ein "set WakeupInterval 1 300" (Interval 300 Sekunden auf NodeId 1. Die Reihenfolge der Parameter war mir nicht klar) ausgeführt. Natürlich nicht direkt nacheinander sondern dazwischen mit Test ob es geht.
Beides hat nicht funktioniert.

Also hab ich z-cloud installiert. (Anleitung: http://code.google.com/p/z-cloud/wiki/WikiRaspberryInstallationHowto)
Über z-cloud ein erneutes "Interview" des Danfoss ausgeführt und nachdem das fertig war, das WakeupInterval 300 an Gerät 1 gespeichert.

Danach funktionieren alle get Befehle in fhem.


@peterb:
Mich würde interessieren ob du den Danfoss zuvor schon in einer anderen Software included hast.
Wenn nein dann hab ich vermutlich etwas falsch gemacht.
Wenn ja dann hat fhem evtl. ein Problem beim setzten des WakeupInterval. Das funktioniert bei mir jetzt auch noch nicht.

@rudolfkoenig:
zum Thema: Benutzerfreundlichkeit beim THERMOSTAT_SETPOINT Befehl
Ehrlich gesagt sehe ich fhem sowieso nicht als "benutzerfreundlich" im klassischen Sinn. Was ich aber keineswegs negativ finde.
Ich mag die hohe Anpassbarkeit und dafür muss man zwangsläufig etwas tiefer einsteigen.
Egal ob ein oder drei Parameter. Wichtig finde ich eine gute Dokumentation der Parameter, so das man als Neueinsteiger eine Chance hat.


Viele Grüße
Matthias

peterb

Hallo Matthias,

der "set WakeupInterval 300 1" Befehl nach der Inklusion ist das "Geheimnis". Vorher scheint der DLC nicht ansprechbar zu sein. Ehrlich gesagt weiß ich nicht mehr, ob ich den DLC unter fhem inkludiert habe. Aktuell funktionieren die WakeUp Set Befehle aber.

Ich habe tatsächlich auch z-cloud probiert, allerdings nur zu Testzwecken. Für einen Betrieb ist das meiner Meinung nach ungeeignet. Außerdem habe ich Indigo (Mac User) ausprobiert, bin aber nicht wirklich überzeugt. Schlußendlich ist OpenZwave mit dem ControlPanel (http://code.google.com/p/openzwave-control-panel/) recht praktisch. Man muss nur unter MacOS noch einen Treiber für den Aeon Stick installieren, den es auf der Seite des Herstellers gibt (da gibt es auch eine Windows Version). Dann ist das für Testzwecke ziemlich gut. Und man kann auch auf die Log's zugreifen, was bei zcloud so nicht geht.

Zu den Parametern:
Derzeit ist das so, dass man beim Set Befehl "1 1 20" eingeben muss, wenn man einen Setpoint von 20° haben will. Die beiden ersten Paramter kann man tatsächlch wegfallen lassen, verliert dadurch aber Funktionalität. Wirklich nicht besonders user friendly. Da ich gerade ziemlich in meinem Job eingebunden bin, hatte ich noch keine Zeit für einen alternativen Vorschlag. Die Tage aber sicher...

Übrigens hat der DLC ja noch so eine schöne Unart. Und zwar überschreibt er den aktuellen Setpoint Wert mit den Werten seines ClimateSchedule Plans. Das war für mich bisher zweitrangig, weil ich den DLC überhaupt erst mal ans laufen bringen wollte.

Wo wir beim Thema sind: Der Danfoss Support hat sich tatsächlich bei mir gemeldet. Angeblich sei alles in Ordnung, wenn nur der Controller nach jedem WakeUp ein "Go to Sleep" senden würde. SUC Modus des Controllers vorausgesetzt.

Testen konnte ich das noch nicht, allerdings ist mein Stick im SUC Modus.

@rudolfkoenig:
Sendet fhem denn nach jeder Kommunikation so einen Befehl an Batterie betriebene Devices?

Gruß

Peter

rudolfkoenig

Nicht das ich wuesste und ich muesste es wissen :)

Falls ein Geraet die WAKE_UP Klasse hat, dann werden set/get Befehle erst gesammelt, und in das WakeUp hash gepackt (was bei list device sichtbar sein sollte). Falls eine Nachricht von so einem Geraet kommt (ueblicherweise wakeup:notification) dann wird das erste aus der Liste rausgesendet. Da ueblicherweise darauf gleich eine Antwort kommt, wird die Zweite aus der Liste gesendet, usw.

Vermutlich muesste FHEM ein WAKE_UP_NO_MORE_INFORMATION Telegramm zum Schluss senden.

peterb

Könnte man das denn einfach implementieren?

Eine Erweiterung für die 10_Zwave könnte so aussehen:

  WAKE_UP                  => { id => '84',.
    set   => { wakeupInterval => "04%06x%02x" },
    set   => { NoMoreInformation => "0408" },
    get   => { wakeupInterval => "05" },

Die dritte Zeile habe ich ergänzt (0408).

Jetzt müsste man an sich "nur" bei jeder Warteschlange für Batterie betriebene Geräte jeweils diesen Befehl aufrufen ;)


rudolfkoenig

Habs eingebaut als
   set   => { wakeupInterval => "04%06x%02x",
               wakeupNoMoreInformation => "08", },

und auch in der Doku erwaehnt.

Die "richtige" Loesung habe ich als TODO aufgeschrieben, falls sie jemand sonst implementiert, bitte melden.

matze86

Hallo Rudolf,

von welcher Doku sprichst du? Ich kenne nur die fhem commandref.

rudolfkoenig

Diese Datei meinte ich auch. Ich habe es unten in 10_ZWave.pm eingebaut und eingecheckt, und daraus wird morgen frueh ein commandref.html generiert und auf fhem.de hochgeladen.

SonKevi

Hallo,
möchte mich gerne mehr mit dem FHEM-Server auseinandersetzen.
Doch vorher eine Frage:

Ist es möglich, mit folgender Hardware, die Temperaturfühler von Danfoss Living Connect (014G0158) auszulesen?

Meine Hardware:
Raspberry mit Z-Wave Aeon Labs USB-Stick S2
Danfoss-Funk-System:
Hauptregler 014G0100
Zentralpanel 014G0151


Temperaturfühler 014G0158

Mx112

Probier's aus. Sollte prinzipiell laufen. Raspi hab ich selbst am Start ein ein Kollege von mir den S2. Zum Danfoss gab es hier auch schon den ein oder anderen Thread.


Gesendet von meinem iPhone mit Tapatalk
FHEM 5.5 SVN - FB7390 FRITZ!OS 06.03 - RaspberryPi - Z-Wave - FBDECT

hschmitt

Zitat von: rudolfkoenig am 15 September 2013, 17:29:49
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.
Hallo Rudolf,
ich habe mal die beiden Ausdrücke zusammengebaut:
    set   => { setpointHeating => "010101%02x",                               
               setpointCooling => "010201%02x"},

setpointHeating habe ich mit meinem Danfoss Living Connect getestet und es funktioniert. setpointCooling ist ungetestet, aber sollte so funktionieren. Die Funktion erlaubt zur Zeit aber nur die Angabe ganzer Zahlen, obwohl der Danfoss auch halbe Grade kann. Für mich sind ganze Gradzahlen allerdings ausreichend.
Kannst Du den Code so einchecken?

hschmitt

Hier der Patch als svn diff.
Ist das so in Ordnung oder soll muss ich etwas anders machen?

hschmitt

Rebase des vorherigen Patches auf die aktuelle SVN Version 5700.

hanske

Hallo,

funktioniert den nun der Raumthermostat von Danfoss Living Connect (014G0158) mit Fhem?
Ich würde einen Report der Ist- und der Sollwerte erwarten wollen.

Danke
Raspberry Pi (Wheezy), Aeon Labs Z-Wave USB Stick 2, HM-USB Adapter, EBUS 2.0 mit Wemos
diverse HM und Z-Wave Geräte