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
> 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 (//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.
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
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.
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
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.
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
Mwn nicht offiziell. Aber wenn man nach SDS11060 sucht...
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
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.
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
> ... 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.
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
Welche Klassen wurden denn erkannt?
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
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.
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 (//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
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/ (//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
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.
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 ;)
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.
Hallo Rudolf,
von welcher Doku sprichst du? Ich kenne nur die fhem commandref.
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.
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
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
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?
Hier der Patch als svn diff.
Ist das so in Ordnung oder soll muss ich etwas anders machen?
Rebase des vorherigen Patches auf die aktuelle SVN Version 5700.
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