Danfoss LC-13 (014G0013)

Begonnen von Didi65, 14 Januar 2015, 18:17:38

Vorheriges Thema - Nächstes Thema

cpi

Also ich kenne das Leid mit dem Danfoss LC13. Gleiches Fehlerbild auch am Razberry aufsteckboard mit fhem, 2-4 Stunden, dann Fehler E5 oder keine Anzeige mehr. Stromlos machen hilft in den meisten Fällen dann wieder, aber die Batterien sind dementsprechend fix leer weil das Thermostat immer wie wild zu funken scheint. Mit openhab (1.6/1.7) war es im Prinzip ähnlich.

Mit dem Razberry Interface und der (mMn bescheidenen) zwave.me Software lässt es sch zwar steuern und stürtze soweit ich mich erinnere auch nicht ab, ich hab es aber mit zwave.me nicht so furchtbar lang ausgehalten. Das Danfoss liegt jetzt im Regal und ich mache die Heizung per Homematic Thermostaten. Die können ja mittlerweile auch lüften erkennen und brauchen ja keinen Raumfühler mehr, die Kinder finden das drehen auch besser.

Didi65

Seit Gestern bin ich bzgl. der Danfoss LC-13 und dem Aeon Stick Series 2 mit Domotiga zugange - ohne Provokation läuft es bisher ohne E5 Ausfälle. Domotiga arbeitet mit 2 Schnittstellen die man auswählen muss, entweder openzwave oder RaZberry. Da ich keinen RaZberry habe, habe ich openzwave eingestellt. Somit sind auch die Grundbedingungen mit Fhem identisch.

openzwave - Aeon Stick - LC-13

Domotiga sagt, dass ihm die Konfiguration dieses Gerätes (LC-13) nicht bekannt ist. Parameterwerte können daher nur über die numerischen Parameterwerte eingetragen werden. Bei der Sendestatistik (Werte ab gestern Abend) sieht es so aus:

sent: 210
sentfailed: 54
retries: 69
received: 575
receiveddups: 0
receivedunsolicited: 520

das scheint mir zwar auch nicht so berühmt zu sein, aber wenigstens läuft es ....

Von der Sache, sieht es dann doch schon so aus, wie es der Typ vom Z-Wave Forum sagte. Bleibt mir noch die Frage, wie kann ich für Fhem etwas beitragen damit die Z-Wave Kompatibilität erhöht wird? Ich habe oft gelesen, dass die Konfigurationsdateien nicht vollständig sind. Was ist da noch zu tun, wie erfolgt die Einbindung? Gibt es eine Doku?

rudolfkoenig

Zitatwie kann ich für Fhem etwas beitragen
Wie ich das gestern geschrieben habe: die Kommunikation zwischen Programm und Geraet protokollieren. Entweder hat dafuer zwave.me eine Konfiguration (wie verbose 5 in FHEM), oder mit strace oder aehnliches.

krikan

@Didi65:
Wenn Domotiga Openzwave nutzt, solltest Du die gesuchten Logs in der Datei "OZW_Log.txt" finden. Stell die mal wegen der Kommunikation zwischen Gateway und LC13 zur Verfügung . Ich denke, damit kann man (ich nicht, aber vermutlich Rudi) etwas anfangen.

Didi65

#19
Wenn es nur diesen Log betrifft, hier ist er. Ansonsten gibt es in Domotiga sehr viele Logs die man anscheinend zusätzlich auswählen kann ....

Die Danfoss sind Node 6, 7 und 14

rudolfkoenig

Hmmm. Sie verwenden Optionen beim Senden (0x20, neben AUTO_ROUTE und ACK), wozu ich keine Doku habe. Ansonsten habe ich erstmal nichts auffaelliges gesehen, habe aber auch nicht ueber jedes Wort in den 420k meditiert. Waere es moeglich eine "stille" Stunde mitzuschneiden, also ohne manuelle Aenderungen oder Schaltauftraege?

Didi65

In Domotiga gibt es auch einen Bug (https://code.google.com/p/open-zwave/issues/detail?id=377) den möchte ich noch beheben, dann kann ich vielleicht auch den Log auf die Thermostate isolieren, damit das Log nicht so groß wird.

Didi65

#22
Die Thermostate laufen mittlerweile seit Freitag problemlos in Domotiga. Schaltungen werden derzeit nicht vorgenommen, mir kommt es in erster Linie mal darauf an, dass das System stabil läuft.

Ich habe 2 Stunden Protokoll rausgeschnitten in denen das System auf sich alleingestellt war, und als Excel Datei mit Filterfunktionen beigefügt. Ich denke, dass man sich in all den Daten mit der Filterfunktion einfacher tut, hoffe aber auch, dass nichts dadurch verfälscht wurde, denn ich habe das Koma als Trennung der Spalten benutzt.

Eine Anmerkung habe ich noch, sind die Thermostate einmal auf E5 gehen diese auch in Domotiga nicht wieder selbstständig in den "Normal-Modus".

rudolfkoenig

Das Excel Format hat mich davon nicht abgehalten, es nach .csv zu exportieren, um es bearbeiten zu koennen. :)
Eine aus mAn auf wesentliche reduzierte und vereinfachte Version ist folgendes:

00:34:12.368  Received: BAT LOW
00:34:12.388  Received: setpoint_heating:XX
00:34:12.400  Received: cc_schedule
00:34:12.414  Received: wake_up notification
00:34:12.415  Sending:  -  BatteryCmd_Get
00:34:12.441  Received: BAT LOW
00:34:12.461  Sending:  -  ClockCmd_Get
00:34:12.486  Received  Clock  report:  Monday  05:06

00:39:04.928  Received: BAT LOW
00:39:04.985  Received: setpoint_heating:XX
00:39:04.987  Received: cc_schedule
00:39:04.989  Received: wake_up notification
00:39:04.990  Sending:  -  WakeUpCmd_NoMoreInformation

00:43:57.442  Received: BAT LOW
00:43:57.462  Received: setpoint_heating:XX
00:43:57.475  Received: cc_schedule
00:43:57.490  Received: wake_up notification
00:43:57.490  Sending:  -  WakeUpCmd_NoMoreInformation

00:48:49.945  Received: BAT LOW
00:48:49.966  Received: setpoint_heating:XX
00:48:49.977  Received: cc_schedule
00:48:49.992  Received: wake_up notification
00:48:49.993  Sending:  -  WakeUpCmd_NoMoreInformation

00:53:42.420  Received: BAT LOW
00:53:42.445  Received: setpoint_heating:XX
00:53:42.453  Received: cc_schedule
00:53:42.468  Received: wake_up notification
00:53:42.468  Sending:  -  WakeUpCmd_NoMoreInformation

00:58:34.875  Received: BAT LOW
00:58:34.895  Received: setpoint_heating:XX
00:58:34.907  Received: cc_schedule
00:58:34.922  Received: wake_up notification
00:58:34.922  Sending:  -  WakeUpCmd_NoMoreInformation

01:03:27.345  Received: BAT LOW
01:03:27.368  Received: setpoint_heating:XX
01:03:27.377  Received: cc_schedule
01:03:27.392  Received: wake_up notification
01:03:27.392  Sending:  -  BatteryCmd_Get
01:03:27.418  Received: BAT LOW
01:03:27.437  Sending:  -  ClockCmd_Get
01:03:27.462  Received  Clock  report:  Monday  05:36


d.h. das Geraet sendet alle 5 Minuten Batterie, setpoint und cc_schedule Nachrichten, die mit "WakeUpCmd_NoMoreInformation" quittiert werden, und alle halbe Stunde wird vom domotiga ein BatteryCmd_Get und ein ClockCmd_Get abgesetzt bzw. vom Geraet beantwortet, allerdings diesmal ohne "NoMoreInformation".

- koennte jemand die von FHEM durchgefuehrte Kommunikation fuer 30 Minuten mit verbose 5 mitschneiden, in dem Fall, wo noch kein E5 angezeigt wird.
- bitte auch mit ein regelmaesiges Abfragen von irgendwelchen Werten testen, z.Bsp. mit einem
  define zAt at +*00:30 get DEVICE battery

Didi65

Hallo Rudi, hier nun die Fhem Kommunikation über etwas mehr als 30 min. Alles Verbose 5 und ohne E5 aber mit Abfrage nach Deinem Wunsch für den Node 7. Nodes Nummern sind analog Domotiga.

Wenn ich  mich recht entsinne, habe ich im Domotiga Forum gelesen, dass dieses Thermostat nicht mit jeder OpenZwave Version läuft. Wie ist das bei Fhem?

Didi65

Hallo Rudi, habe heute erstaunliches bemerkt!

define zAt at +*00:30 get DEVICE battery

hat bewirkt, dass das Thermostat online blieb! Den Befehl gleich für die anderen zwei Thermostate reingehämmert et voillá, kamen diese beiden ohne Zutun ebenfalls online. ;D Ich denke mir aber, dass das so nicht geplant war und nur ein workaround darstellen kann.

Trotzdem - schon jetzt vielen, vielen Dank für Deine Hilfe!!!

rudolfkoenig

Bin noch nicht sicher, wie das geloest werden soll:
- Eintrag im Wiki, dass man fuer solche Geraete ein at zu definieren ist
- Fuer dieses Geraet das im Modul intern realisieren
- fuer alle batteriebetriebene Geraete das Holen der Batterie aktivieren.

Meinungen, evtl. Doku-Hinweise?

krikan

Zitat- Eintrag im Wiki, dass man fuer solche Geraete ein at zu definieren ist
Erledigt http://www.fhemwiki.de/wiki/Z-Wave#Heizungsthermostat_LC-13_.28014G0013.29 -> zum Rest noch keine Meinung

@Didi65: Könntest Du bitte schauen, ob noch etwas im Wiki zu ergänzen/korrigieren ist und ggfs. mir mitteilen. Danke.

PNinBB

#28
Bin noch am Anfang mit FHEM und "kämpfe" momentan mit (bzw. gegen!) Danfoss Living Connect und Fibaro Motion Sensor.
Basis: RaZberry (Raspberry Pi B mit Debian Wheezy) und drei bestens arbeitenden Fibaro Roller Shutter FGRM222).
Ich habe verschiedene "offene" Plattformen ausprobiert: u.a. Z-Way-Server, Domoticz und FHEM.

Nun zu meinen Versuchen, Ergebnissen und Fragen:
Danfoss: Lt. Verpackung ist es ein LIVING CONNECT Z, 014G0012 mit "Speaks Z-Wave" - Logo, auch im Batteriefach. Habe in einigen Foren dazu auch gleichlautende Aussagen gefunden.
   * Tests mit dem z-way-server:
     + Thermostat wurde problemlos inkludiert (siehe Bild 2).
         Beachte: Gerät wurde als ,,Living Connect" richtig erkannt.
     + Werte wurden ausgelesen und dargestellt (siehe Bild 3).
     + Temperaturwerte konnten gelesen und gesetzt werden.
   * Tests mit Domoticz:
     + Thermostat wurde problemlos inkludiert.
     + Einfache Kommandos: Temperaturwert setzen und auch auslesen funktionierten.
     + Wurde allerdings nur als "utility"-Gerät erkannt und lies sich defacto nicht mit komplexeren Kommandos (Heizungsprogramm) steuern.
     + Habe letztendlich Domoticz aufgegeben, obwohl die Rollladensteuerung bestens funktionierte.
   * Tests mit FHEM:
     + Thermostat wurde problemlos inkludiert.
     + Wird aber m.E. nicht richtig erkannt.
     + Es wird ausgewiesen (siehe Readings im Bild 1).
          (//)
       - model: Danfoss Z Thermostat.
       - modelConfig: danfoss/z.xml.
     + In openzwave_manufacturer_specific.xml erkennt man:
         <Manufacturer id="0002" name="Danfoss">
           <Product type="0005" id="0003" name="Z Thermostat" config="danfoss/z.xml"/>
           <Product type="0064" id="0001" name="RA Plus-W Radiator Thermostat"/>
           <Product type="8005" id="0001" name="Living Connect Radiator Thermostat" config="danfoss/living.xml"/>
           <Product type="0005" id="0004" name="Living Connect Radiator Thermostat" config="danfoss/living.xml"/>
         </Manufacturer>
     + Aus dem Namen schliesse ich, dass die config eigentlich "danfoss/living.xml" sein müsste !!
     + Kann/Sollte ich das einmal in openzwave_manufacturer_specific.xml ändern ?
     + Gemäß Z-Wave Device Library (www.pepper1.net/zwavedb/device/426) kommt vom Gerät  aber:
         Manufacturer: Danfoss (0x0002)
         Product type ID: 0x0005
         Product ID: 0x0003
     + Diese Werte sind mit den Readings (s.o.) identisch.
     + Frage 1: von wo werden diese config-Dateien gelesen; in Domoticz sind sie lokal gespeichert.
     + Frage 2: Warum ist ,,STATE  ???" im Feld ,,Internals" nicht gefüllt ?
     + Im Abstand von 5 Minuten (wakeupIntervall 300) werden regelmässig lt. Logfile folgende Werte ausgelesen:
         2015-02-15_13:13:41 WZ_HZ battery: 84 %
         2015-02-15_13:13:41 WZ_HZ temperature: 12.0 C heating
         2015-02-15_13:13:41 WZ_HZ ccsOverride: no, unused
         2015-02-15_13:13:41 WZ_HZ wakeup: notification
     + Verändert man manuell am Thermostat den Temperaturwert, so wird er beim nächsten Wakeup korrrekt an den Controller übertragen und im Logfile ausgewiesen.
       Gerätelog:
         2015-02-17_10:11:17 WZ_HZ wakeup: notification
         2015-02-17_10:13:13 WZ_HZ battery: 77 %
         2015-02-17_10:13:13 WZ_HZ temperature: 10.0 C heating         ; vorheriger Wert
         2015-02-17_10:13:13 WZ_HZ ccsOverride: no, unused
         2015-02-17_10:13:13 WZ_HZ wakeup: notification
         2015-02-17_10:15:05 WZ_HZ CMD: ZW_APPLICATION_UPDATE
         2015-02-17_10:15:08 WZ_HZ battery: 75 %
         2015-02-17_10:15:08 WZ_HZ temperature: 13.0 C heating         ; neuer Wert
         2015-02-17_10:15:08 WZ_HZ ccsOverride: no, unused
         2015-02-17_10:15:08 WZ_HZ wakeup: notification
     + Der Wert scheint also angekommen.
     + Im fhem.log-File gibt es keinen diesbetreffebndeb Eintrag.
     + Will man mit "set" einen Wert einstellen, so findet man im
       - fhem.log:  2015.02.17 10:23:05 2: ZWave set WZ_HZ setpointHeating   ; 25 Grad wurde gesetzt
       - Gerätelog: 2015-02-17_10:23:05 WZ_HZ setpointHeating 25
         Zum nächsten Wakeup: 2015.02.17 10:26:50 4: Sending stored command: 130205430101011905
                              2015.02.17 10:26:50 4: Sending wakeupNoMoreInformation to node: 02
                              2015-02-17_10:36:35 WZ_HZ battery: 75 %
                              2015-02-17_10:36:35 WZ_HZ temperature: 25.0 C heating   ; neuer Wert angekommen
                              2015-02-17_10:36:35 WZ_HZ ccsOverride: no, unused
                              2015-02-17_10:36:35 WZ_HZ wakeup: notification

Frage: wie kann ich nun komplette "Heizungssequenzen" (CLIMATE_CONTROL_SCHEDULE ) setzen, d.h. je Tag Zeiträume und Temperaturen vorgeben (wie ich es schon in Foren gesehen habe) ?
Vorher muss ich jedoch den Fibaro Motion Sensor FGMS001 zum "Spielen" bringen. Meine Untersuchungen dazu habe ich den Thread Fibaro "Motion Sensor" eingestellt.

Raspi 4B + RaZberry2 (Deb 10), FritzBox 7490;
AEOTec: KeyFobGen5: 1x;
Danfoss: Living Connect 2.51: 3x;
Fibaro: FGK: 10x: 3x; FGBS: 001: 8x, 222: 1x; FGMS001: 2x; FGR: 222: 3x, 223: 2x; FGRGBWM-441: 1x; FGBS: 222: 2x, 223: 2x,224: 1x;
Philio: PAN06-1A: 3x;

rudolfkoenig

ZitatFrage: wie kann ich nun komplette "Heizungssequenzen" (CLIMATE_CONTROL_SCHEDULE ) setzen
Entweder warten, bis das jemand sonst implementiert, oder es selbst in die Hand nehmen (fhem/FHEM/10_ZWave.pm %zwave_class, CLIMATE_CONTROL_SCHEDULE, set Eintrag bauen)