Danfoss LC-13 (014G0013)

[Didi65]

Hallo Zusammen!

Ich habe mir 3 wunderhübsche Danfoss LC-13 Thermostate zugelegt. Das includieren ins ZWave-Netzwerk hat einwandfrei funktioniert. Auch das senden des Geheimnisses = "set WakeupIntervals 300 1" war kein Problem. Insgesamt funktioniert alles wunderbar, bis etwa 2-4 Stunden später, plötzlich ist am Display des Thermostates "E5" abzulesen und dann kommt die "wakeup notification" zuverlässig nur noch alle 30 Minuten . Entnimmt man die Batterien und setzt diese nach kurzer Zeit wieder ein, funktioniert es dann wieder um 2-4 Stunden später wieder abzukacken ..... 

In keinem Fhem-Thread konnte ich etwas zu diesem Thermostat lesen, hat trotzdem vielleicht jemand Erfahrungen mit diesem Thermostat gemacht oder weiss mir Rat?

Config:

Code Auswählen Erweitern

define Thermostat_Wohnen_Links ZWave 0184d2eb 5
attr Thermostat_Wohnen_Links IODev ZWDongle_0
attr Thermostat_Wohnen_Links classes BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD
attr Thermostat_Wohnen_Links icon hc_wht_regler
attr Thermostat_Wohnen_Links room Wohnen,ZWave
attr Thermostat_Wohnen_Links verbose 5

Logfile:

Code Auswählen Erweitern

2015-01-12_03:59:21 Thermostat_Wohnen_Rechts battery: 50 %
2015-01-12_03:59:21 Thermostat_Wohnen_Rechts temperature: 23.0 C heating
2015-01-12_03:59:21 Thermostat_Wohnen_Rechts ccsOverride: no, unused
2015-01-12_03:59:21 Thermostat_Wohnen_Rechts wakeup: notification
2015-01-12_04:04:14 Thermostat_Wohnen_Rechts battery: 50 %
2015-01-12_04:04:14 Thermostat_Wohnen_Rechts temperature: 23.0 C heating
2015-01-12_04:04:14 Thermostat_Wohnen_Rechts ccsOverride: no, unused
2015-01-12_04:04:14 Thermostat_Wohnen_Rechts wakeup: notification
2015-01-12_04:09:06 Thermostat_Wohnen_Rechts battery: 50 %
2015-01-12_04:09:06 Thermostat_Wohnen_Rechts temperature: 23.0 C heating
2015-01-12_04:09:06 Thermostat_Wohnen_Rechts ccsOverride: no, unused
2015-01-12_04:09:06 Thermostat_Wohnen_Rechts wakeup: notification
2015-01-12_04:13:58 Thermostat_Wohnen_Rechts battery: 50 %
2015-01-12_04:13:58 Thermostat_Wohnen_Rechts temperature: 23.0 C heating
2015-01-12_04:13:58 Thermostat_Wohnen_Rechts ccsOverride: no, unused
2015-01-12_04:13:58 Thermostat_Wohnen_Rechts wakeup: notification
2015-01-12_04:43:12 Thermostat_Wohnen_Rechts battery: 50 %
2015-01-12_04:43:12 Thermostat_Wohnen_Rechts temperature: 23.0 C heating
2015-01-12_04:43:12 Thermostat_Wohnen_Rechts ccsOverride: no, unused
2015-01-12_04:43:12 Thermostat_Wohnen_Rechts wakeup: notification
2015-01-12_05:12:27 Thermostat_Wohnen_Rechts battery: 50 %
2015-01-12_05:12:27 Thermostat_Wohnen_Rechts temperature: 23.0 C heating
2015-01-12_05:12:27 Thermostat_Wohnen_Rechts ccsOverride: no, unused
2015-01-12_05:12:27 Thermostat_Wohnen_Rechts wakeup: notification

Die anderen Threads zu Danfoss Thermostaten habe ich allesamt durchgelesen.

Für Euere Bemühungen bedanke ich mich schon jetzt recht herzlich!

Gruß
Dietmar

[krikan]

Interessantes Forschungsprojekt
Laut Anleitung E5 = "Der Thermostat erhält nicht die erwarteten Antworten vom Regelsystem." Das 30-Minuten-Wakeup-Intervall wird bei Verlust der Controllerverbindung genutzt.

Mögliche Ursachen könnten bspw. sein:

• Verbindungsprobleme zum Controller (Funktelegrammverluste!) -> Kannst Du das ausschließen? Welcher Controller?
• Technische Anforderungen laut Anleitung an das Zwave-System sind nicht erfüllt -> mehrere Thermostate in einem Raum mit verschiedenem Programm/setpoint, oder...
• Fhem gibt nicht die korrekte Antwort auf Thermostat-Nachrichten -> verbose 5

Als Ansatzpunkt für letzteres: Logge mal mit verbose 5, was bei Verbindungsabbruch passiert. Evtl. kann man erkennen, ob Fhem auf eine Thermostat-Nachricht nicht reagiert oder zu spät reagiert.

edit: verbose 5 musst Du beim Controller setzen!

[Didi65]

Forschungsprojekt ist gut .... da ich Fhem-Anfänger bin, würde ich es eher als Jugend forscht bezeichnen. Aber ich gebe mir Mühe und vielleicht kommt ja auch was anständiges dabei raus, damit das ganze Fhem-Projekt profitiert.

Laut Anleitung E5 = "Der Thermostat erhält nicht die erwarteten Antworten vom Regelsystem." Das 30-Minuten-Wakeup-Intervall wird bei Verlust der Controllerverbindung genutzt.

Ja, das habe ich auch gelesen.

Mögliche Ursachen könnten bspw. sein:

• Verbindungsprobleme zum Controller (Funktelegrammverluste!) -> Kannst Du das ausschließen? Welcher Controller?

Aeotec Z-Stick Series 2
Wie kann ich Funktelegrammverluste ausschließen?

• Technische Anforderungen laut Anleitung an das Zwave-System sind nicht erfüllt -> mehrere Thermostate in einem Raum mit verschiedenem Programm/setpoint, oder...

Generell habe ich derzeit quasi ein Testlabor aufgebaut. Sprich die ganze Mimik befindet sich in einem offenen "Ess-Koch-Wohnzimmer". Module sind:

1 x Notebook mit Ubuntu
1 x Aeotec Z-Stick Series 2
3 x Danfoss LC-13
2 x Aeotec Multisensor
1 x FIBARO Relais 2 Schalter a 1.5kW (FIB_FGS-221)
1 x FIBARO Roller Shutter 2 (FIB_FGRM-222)
1 x Fibaro Rauchsensor / Smokealarm (FIB_FGSS-101)

Derzeit werden die Danfoss weder von Fhem noch von den Sensoren gesteuert und liefern praktisch nur Werte an Fhem. Die Vorgabetemperatur ist bei allen gleich eingestellt. Wobei ich mir nicht vorstellen kann, wie der Thermostat oder der Controller feststellen könnte, dass es im gleichen Raum noch ein weiteres Thermostat gibt oder dies sich evtl. im Nachbarraum befindet.

• Fhem gibt nicht die korrekte Antwort auf Thermostat-Nachrichten -> verbose 5

Als Ansatzpunkt für letzteres: Logge mal mit verbose 5, was bei Verbindungsabbruch passiert. Evtl. kann man erkennen, ob Fhem auf eine Thermostat-Nachricht nicht reagiert oder zu spät reagiert.

Verbose 5 habe ich auf allen Geräten eingestellt.

Letzter gültiger Log Thermostat

Code Auswählen Erweitern

2015-01-15_23:14:49 Thermostat_Wohnen_Rechts battery: 48 %
2015-01-15_23:14:49 Thermostat_Wohnen_Rechts temperature: 23.0 C heating
2015-01-15_23:14:49 Thermostat_Wohnen_Rechts ccsOverride: no, unused
2015-01-15_23:14:49 Thermostat_Wohnen_Rechts wakeup: notification

Letzter gültiger Log Fhem

Code Auswählen Erweitern

2015.01.15 23:14:49.771 5: ZWDongle/RAW: /0109000400060380033044
2015.01.15 23:14:49.771 5: SW: 06
2015.01.15 23:14:49.772 5: ZWDongle_Read ZWDongle_0: 0004000603800330
2015.01.15 23:14:49.772 5: ZWDongle_0 dispatch 0004000603800330
2015.01.15 23:14:49.772 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:03800330
2015.01.15 23:14:49.787 5: ZWDongle/RAW: /010c00040006064303014208fc00
2015.01.15 23:14:49.787 5: SW: 06
2015.01.15 23:14:49.788 5: ZWDongle_Read ZWDongle_0: 00040006064303014208fc
2015.01.15 23:14:49.789 5: ZWDongle_0 dispatch 00040006064303014208fc
2015.01.15 23:14:49.789 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:064303014208fc
2015.01.15 23:14:49.803 5: ZWDongle/RAW: /010a00040006044608007fc2
2015.01.15 23:14:49.803 5: SW: 06
2015.01.15 23:14:49.804 5: ZWDongle_Read ZWDongle_0: 00040006044608007f
2015.01.15 23:14:49.804 5: ZWDongle_0 dispatch 00040006044608007f
2015.01.15 23:14:49.804 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:044608007f
2015.01.15 23:14:49.818 5: ZWDongle/RAW: /01080004000602840774
2015.01.15 23:14:49.818 5: SW: 06
2015.01.15 23:14:49.820 5: ZWDongle_Read ZWDongle_0: 00040006028407
2015.01.15 23:14:49.820 5: ZWDongle_0 dispatch 00040006028407
2015.01.15 23:14:49.820 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:028407

Bis dorthin hat sich der Thermostat zuverlässig alle 4'52'' beim Controller gemeldet > sollte er sich pünktlich um 23:19:41 wieder melden. Nach meinem Verständnis sollte genau dort ein Ereignis sein, welches dort nicht hingehört. Nachfolgend der Log aus genau dieser Zeit.

Code Auswählen Erweitern

2015.01.15 23:18:54.645 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:0a ARG:06310504220000
2015.01.15 23:19:16.318 5: ZWDongle/RAW: /010c00040004063105012200d436
2015.01.15 23:19:16.318 5: SW: 06
2015.01.15 23:19:16.320 5: ZWDongle_Read ZWDongle_0: 00040004063105012200d4
2015.01.15 23:19:16.320 5: ZWDongle_0 dispatch 00040004063105012200d4
2015.01.15 23:19:16.320 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:063105012200d4
2015.01.15 23:19:25.585 5: ZWDongle/RAW: /0109000408080380033240
2015.01.15 23:19:25.585 5: SW: 06
2015.01.15 23:19:25.586 5: ZWDongle_Read ZWDongle_0: 0004080803800332
2015.01.15 23:19:25.587 5: ZWDongle_0 dispatch 0004080803800332
2015.01.15 23:19:25.587 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:03800332
2015.01.15 23:19:25.596 5: ZWDongle/RAW: /0109000400080380033248
2015.01.15 23:19:25.596 5: SW: 06
2015.01.15 23:19:25.598 5: ZWDongle_Read ZWDongle_0: 0004000803800332
2015.01.15 23:19:25.598 5: ZWDongle_0 dispatch 0004000803800332
2015.01.15 23:19:25.598 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:03800332
2015.01.15 23:19:25.649 5: ZWDongle/RAW: /010c00040808063105030a0001cd
2015.01.15 23:19:25.649 5: SW: 06
2015.01.15 23:19:25.650 5: ZWDongle_Read ZWDongle_0: 00040808063105030a0001
2015.01.15 23:19:25.651 5: ZWDongle_0 dispatch 00040808063105030a0001
2015.01.15 23:19:25.651 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:063105030a0001
2015.01.15 23:19:25.657 5: ZWDongle/RAW: /010c00040008063105030a0001c5
2015.01.15 23:19:25.657 5: SW: 06
2015.01.15 23:19:25.658 5: ZWDongle_Read ZWDongle_0: 00040008063105030a0001
2015.01.15 23:19:25.658 5: ZWDongle_0 dispatch 00040008063105030a0001
2015.01.15 23:19:25.658 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:063105030a0001
2015.01.15 23:19:25.737 5: ZWDongle/RAW: /010c0004080806310505011b00da
2015.01.15 23:19:25.737 5: SW: 06
2015.01.15 23:19:25.739 5: ZWDongle_Read ZWDongle_0: 0004080806310505011b00
2015.01.15 23:19:25.739 5: ZWDongle_0 dispatch 0004080806310505011b00
2015.01.15 23:19:25.739 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:06310505011b00
2015.01.15 23:19:25.739 1: PERL WARNING: Argument "27 %" isn't numeric in addition (+) at (eval 5029) line 1.
2015.01.15 23:19:25.739 3: stacktrace:
2015.01.15 23:19:25.740 3:     main::__ANON__                      called by (eval 5029) (1)
2015.01.15 23:19:25.740 3:     (eval)                              called by fhem.pl (3580)
2015.01.15 23:19:25.740 3:     main::readingsEndUpdate             called by ./FHEM/10_ZWave.pm (1074)
2015.01.15 23:19:25.740 3:     main::ZWave_Parse                   called by fhem.pl (3092)
2015.01.15 23:19:25.740 3:     main::Dispatch                      called by ./FHEM/00_ZWDongle.pm (604)
2015.01.15 23:19:25.740 3:     main::ZWDongle_Parse                called by ./FHEM/00_ZWDongle.pm (540)
2015.01.15 23:19:25.740 3:     main::ZWDongle_Read                 called by fhem.pl (2955)
2015.01.15 23:19:25.740 3:     main::CallFn                        called by fhem.pl (608)
2015.01.15 23:19:25.748 5: ZWDongle/RAW: /010c0004000806310505011b00d2
2015.01.15 23:19:25.749 5: SW: 06
2015.01.15 23:19:25.750 5: ZWDongle_Read ZWDongle_0: 0004000806310505011b00
2015.01.15 23:19:25.750 5: ZWDongle_0 dispatch 0004000806310505011b00
2015.01.15 23:19:25.751 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:06310505011b00
2015.01.15 23:19:25.753 1: PERL WARNING: Argument "27 %" isn't numeric in addition (+) at (eval 5033) line 1.
2015.01.15 23:19:25.753 3: stacktrace:
2015.01.15 23:19:25.753 3:     main::__ANON__                      called by (eval 5033) (1)
2015.01.15 23:19:25.753 3:     (eval)                              called by fhem.pl (3580)
2015.01.15 23:19:25.753 3:     main::readingsEndUpdate             called by ./FHEM/10_ZWave.pm (1074)
2015.01.15 23:19:25.753 3:     main::ZWave_Parse                   called by fhem.pl (3092)
2015.01.15 23:19:25.753 3:     main::Dispatch                      called by ./FHEM/00_ZWDongle.pm (604)
2015.01.15 23:19:25.753 3:     main::ZWDongle_Parse                called by ./FHEM/00_ZWDongle.pm (540)
2015.01.15 23:19:25.753 3:     main::ZWDongle_Read                 called by fhem.pl (2955)
2015.01.15 23:19:25.753 3:     main::CallFn                        called by fhem.pl (608)
2015.01.15 23:19:25.829 5: ZWDongle/RAW: /010c00040808063105012200bc5a
2015.01.15 23:19:25.829 5: SW: 06
2015.01.15 23:19:25.830 5: ZWDongle_Read ZWDongle_0: 00040808063105012200bc
2015.01.15 23:19:25.831 5: ZWDongle_0 dispatch 00040808063105012200bc
2015.01.15 23:19:25.831 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:063105012200bc
2015.01.15 23:19:25.839 5: ZWDongle/RAW: /010c00040008063105012200bc52
2015.01.15 23:19:25.839 5: SW: 06
2015.01.15 23:19:25.840 5: ZWDongle_Read ZWDongle_0: 00040008063105012200bc
2015.01.15 23:19:25.841 5: ZWDongle_0 dispatch 00040008063105012200bc
2015.01.15 23:19:25.841 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:063105012200bc
2015.01.15 23:19:25.874 5: ZWDongle/RAW: /0108000400080284077a
2015.01.15 23:19:25.874 5: SW: 06
2015.01.15 23:19:25.875 5: ZWDongle_Read ZWDongle_0: 00040008028407
2015.01.15 23:19:25.876 5: ZWDongle_0 dispatch 00040008028407
2015.01.15 23:19:25.876 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:028407
2015.01.15 23:19:52.643 5: ZWDongle/RAW: /01100004000a0a32022144000000150000ab
2015.01.15 23:19:52.644 5: SW: 06
2015.01.15 23:19:52.645 5: ZWDongle_Read ZWDongle_0: 0004000a0a32022144000000150000
2015.01.15 23:19:52.645 5: ZWDongle_0 dispatch 0004000a0a32022144000000150000
2015.01.15 23:19:52.646 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:0a ARG:0a32022144000000150000
2015.01.15 23:19:54.642 5: ZWDongle/RAW: /010c0004000a06310504220000e9
2015.01.15 23:19:54.643 5: SW: 06
2015.01.15 23:19:54.644 5: ZWDongle_Read ZWDongle_0: 0004000a06310504220000
2015.01.15 23:19:54.644 5: ZWDongle_0 dispatch 0004000a06310504220000
2015.01.15 23:19:54.645 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:0a ARG:06310504220000
2015.01.15 23:20:32.757 5: ZWDongle/RAW: /01080004000302840771


Sollte der Kontakt zum Controller verloren gehen, sollte sich laut Beschreibung von Danfoss das Thermostat bei der nächsten gültigen Notification wieder "beruhigen" und wieder zum eingestellten WakeupIntervall zurückkehren, deshalb noch der Log vom "Wiedereintritt des Thermostats in das Z-Wave Universum".

Code Auswählen Erweitern

2015.01.15 23:44:06.163 5: ZWDongle/RAW: /0109000400060380033044
2015.01.15 23:44:06.163 5: SW: 06
2015.01.15 23:44:06.165 5: ZWDongle_Read ZWDongle_0: 0004000603800330
2015.01.15 23:44:06.165 5: ZWDongle_0 dispatch 0004000603800330
2015.01.15 23:44:06.165 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:03800330
2015.01.15 23:44:06.180 5: ZWDongle/RAW: /010c00040006064303014208fc00
2015.01.15 23:44:06.180 5: SW: 06
2015.01.15 23:44:06.182 5: ZWDongle_Read ZWDongle_0: 00040006064303014208fc
2015.01.15 23:44:06.182 5: ZWDongle_0 dispatch 00040006064303014208fc
2015.01.15 23:44:06.182 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:064303014208fc
2015.01.15 23:44:06.195 5: ZWDongle/RAW: /010a00040006044608007fc2
2015.01.15 23:44:06.195 5: SW: 06
2015.01.15 23:44:06.196 5: ZWDongle_Read ZWDongle_0: 00040006044608007f
2015.01.15 23:44:06.196 5: ZWDongle_0 dispatch 00040006044608007f
2015.01.15 23:44:06.196 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:044608007f
2015.01.15 23:44:06.209 5: ZWDongle/RAW: /01080004000602840774
2015.01.15 23:44:06.210 5: SW: 06
2015.01.15 23:44:06.211 5: ZWDongle_Read ZWDongle_0: 00040006028407
2015.01.15 23:44:06.211 5: ZWDongle_0 dispatch 00040006028407
2015.01.15 23:44:06.211 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:06 ARG:028407

Zur Systematik: Nachdem ich die ganze Prozedur wieder und wieder getestet habe kann ich festhalten:

• Dieses Verhalten haben alle 3 Danfoss Thermostate
• Maximale Überlebensdauer 1,5 Stunden
• Ich konnte keine direkte Verbindung mit der Perl Warnung herleiten

[krikan]

Wie kann ich Funktelegrammverluste ausschließen?

Gute Funkverbindung Aber bei Deinem vermutlich kurzem Abstand sollte es zu keinen Telegrammverlusten kommen. Wenn eine Nachricht vom Controller nicht am Device landet erkennt man das im Log (NACK o.ä.). Umgekehrt sieht man es nicht, kann es nur durch fehlende Events feststellen.

Derzeit werden die Danfoss weder von Fhem noch von den Sensoren gesteuert und liefern praktisch nur Werte an Fhem.

Kann das evtl. schon ein Problem sein? Erwartet der Thermostat evtl. setpoint vom Controller!? Leider gibt die Anleitung nicht viel her; eigentlich ist das eine Ansammlung von wagen Aussagen. Auch das Handbuch auf handbuch.zwave.de liefert leider nicht mehr Infos.

Mein Problem bei Deinen Logs:
Ich kann nicht erkennen, welches Device (Id) das betrachtete Thermostat hat. Interessant wäre der gesamte Verlauf des Logs für dieses Device. Kannst ja mal das gesamte Log anhängen, wenn Du magst. Wenn das Thermostat eine bestimmte Nachricht vermisst, wird man aber vermutlich nichts erkennen. Habe mal bei den Mitbewerber-Softwareprodukten in den Foren gesucht. Dort taucht das E5-Problem auch häufiger auf. Bei einigen Closed-Source-Produkten wurde es gelöst; finde aber keine genaue Angabe woran es lag...

Ob die Perl-Warnings eine Problem sind, kann ich nicht ausschließen, vermute aber eher auch nicht. Das müsste sich ggfs. Rudi mal anschauen:

2015.01.15 23:19:25.753 1: PERL WARNING: Argument "27 %" isn't numeric in addition (+) at (eval 5033) line 1.
2015.01.15 23:19:25.753 3: stacktrace:
2015.01.15 23:19:25.753 3:     main::__ANON__                      called by (eval 5033) (1)
2015.01.15 23:19:25.753 3:     (eval)                              called by fhem.pl (3580)
2015.01.15 23:19:25.753 3:     main::readingsEndUpdate             called by ./FHEM/10_ZWave.pm (1074)
2015.01.15 23:19:25.753 3:     main::ZWave_Parse                   called by fhem.pl (3092)
2015.01.15 23:19:25.753 3:     main::Dispatch                      called by ./FHEM/00_ZWDongle.pm (604)
2015.01.15 23:19:25.753 3:     main::ZWDongle_Parse                called by ./FHEM/00_ZWDongle.pm (540)
2015.01.15 23:19:25.753 3:     main::ZWDongle_Read                 called by fhem.pl (2955)
2015.01.15 23:19:25.753 3:     main::CallFn                        called by fhem.pl (608)

Ach so, Anfänger bin und bleibe ich auch, obwohl ich schon lange dabei bin. Manchmal hat man aber Erfolge...

[rudolfkoenig]

Die Warnung kommt von einem userReading. Ich habe fhem.pl gestern modifiziert, damit es in diesem Fall zusaetzlich das ausgefuehrte Perl-Expression ausgibt.

[Didi65]

Beigefügt der Log vom Device ID 06.

Verbindungsprobleme habe ich in der derzeitigen Konstellation so gut wie nicht. Ich habe die WakeUps der Devices im Charting Frontend dargestellt - für heute fehlen mir bei einem von 8 Devices 3 WakeUps bei einem mittleren WakeUp von 300 s, die anderen WakeUps kommen vollständig.

Ich lese auch immer und immer wieder die anderen Foren und die Danfoss Beschreibungen durch, ich bin da noch über etwas gestolpert in den Danfoss Beschreibungen .....

"Make sure to use Danfoss Living connects only with Z-Wave controllers fully implementing all battery life time extention methods recommended by Danfoss. All controllers based on Z-Wave.Me software (e.g. RaZberry) fully support these methods."

Ich habe schon danach gesucht inwieweit der Aeotec Z-Stick Series 2 mit Z-Wave.Me kompatibel ist - habe aber bisher noch nichts gefunden ...... wobei eigentlich sollten sie ja alle Z-Wave reden, hören und verstehen!

[krikan]

Beigefügt der Log vom Device ID 06.

Sorry, wenn ich mich zu ungenau geäußert habe: Bräuchte das (gesamte) Logfile mit den Raw-Messages des Dongles. Befürchte nur immer mehr, dass das ein Riesen-Forschungsprojekt ist...

"Make sure to use Danfoss Living connects only with Z-Wave controllers fully implementing all battery life time extention methods recommended by Danfoss. All controllers based on Z-Wave.Me software (e.g. RaZberry) fully support these methods."

Das hatte ich auch gelesen, ist aber wieder eine sehr ungenaue Aussage. Mit der Kombatiblität zwischen den Z-Wave-Sticks/Geräten ist das so eine Sache: Es gibt diverse SDKs und Implementierungen. Die neuen sollten immer alte bedienen und erkennen können (mit Ausnahmen); jedoch nicht zwingend umgekehrt. Z-wave.me-Implemtierungen sind (razberry=ZWave Plus) sind sehr aktuell, Z-Stick 2 deutlich älter. Auch das könnte ein Problem sein, glaube ich aber erstmal nicht. Wie Du liest ist das eine Bastelei mit vielen Unbekannten, das Protokoll ist leider nicht öffentlich und Danfoss zeichnet sich nicht gerade durch optimale Zwave-Doku/Implementierung aus. Es scheint auch diverse Firmwares für Dein Thermosthat mit unterschiedlichen Problemen zu geben, wenn ich den anderen Foren glauben darf.

[Didi65]

Das Logfile habe ich beigefügt. Die IDs sind wie folgt vergeben:

1 x ID 01 - Aeotec Z-Stick Series 2
3 x ID 06, 07, 14 - Danfoss LC-13 (durch viel testen hat ID 14 zuvor auch schon andere IDs angenommen z.B. ID 05)
2 x ID 03, 08 - Aeotec Multisensor
1 x ID 12 - FIBARO Relais 2 Schalter a 1.5kW (FIB_FGS-221)
1 x ID 10 - FIBARO Roller Shutter 2 (FIB_FGRM-222)
1 x ID 04 - FIBARO Rauchsensor / Smokealarm (FIB_FGSS-101)

Meine Danfoss haben die Version Lib 6 Prot 3.67 App 1.1

Während das 014G0012 nach Danfoss Angaben nicht wirklich für Z-Wave geeignet sein soll, sagt Danfoss, dass die 014G0013 genau für solch eine Umgebung entwickelt wurden.

Riesen-Forschungsprojekt hin oder her, die Danfoss sind meines Erachtens in der Z-Wave Welt die einzig richtigen Thermostate. Wenn wir diese Thermostate zum fliegen bekommen vermute ich, dass sich mehr User für Fhem entscheiden könnten.
Ich habe mir wirklich viele Systeme (vielleicht auch die meisten) angesehen bevor ich mich für Fhem und Bastelei entschieden habe und kann nur sagen, dass ausser dem Gira Server und Symcon die meisten "Server" nur verbesserte Fernbedienungen sind! Aber - der wesentliche Unterschied, die können Danfoss ....... Also, wenn die das können, dann sollte es doch auch für Fhem möglich sein.

[rudolfkoenig]

Ich habe mal das Log nach ID:06 gefiltert und angeschaut:
sowohl im 5Minuten Intervall, wie auch in der 30Min Version kommen immer 4 Nachrichten:

Code Auswählen Erweitern

03 800330          -> battery 48%
06 4303014208fc    -> temperature -> 23.00 C
04 4608007f        -> ccsOverride:no, unused
02 8407            -> wakeup:notification

Das ist nichts auffaelliges.

Ich vermute, dass das Geraet irgendwelche Nachrichten von FHEM erwartet, die Preisfrage lautet, welche.  Evtl. koennten das die Helfer im zwave.de Forum beantworten. Und es waere gut rauszufinden, was Danfoss mit "all battery life time extention methods recommended by Danfoss" meint. Gibts sowas wie Danfoss Support? Man hat ja schliesslich fuer die Geraete gezahlt.

[Didi65]

Danfoss (Dänemark) habe ich angeschrieben mit der Frage, was das Thermostat vom Server erwartet. Da ich nicht wirklich gut Englisch kann, hoffe ich, dass Sie meine Frage verstehen und ich bald eine Antwort bekomme.

[Didi65]

Auf dem Z-Wave Forum habe ich auch meine Frage hinterlassen.

[Didi65]

Ich habe heute mit Danfoss Deutschland telefoniert. Die LC-13 Thermostate sind OEM Produkte die direkt von Danfoss Dänemark ausgeliefert und mit spezieller FW nach Wünschen der Z-Wave "Organisation" ausgeliefert werden. Der Support wird wie üblich bei OEM Produkten, durch den Verkäufer übernommen. Ich habe meinen Verkäufer kontaktiert, leider war der Z-Wave zuständige Mitarbeiter nicht mehr zu sprechen, aber sein Kollege sagte mir, dass er sich der Sache annimmt.

Zwischenzeitlich habe ich noch etwas mehr recherchiert. Es könnte doch sein, dass es an der Kompatibilität Stick/Controller Thermostat liegt. Der LC-13 spricht und hört bereits Z-Wave+ und vermutlich der Aeotec nicht. Sprich, der Stick als vermeintlicher "Legastheniker" kann nur das notwendigste verstehen und hören - und so kommt die Unterhaltung zunächst ins stottern und dann zum Abbruch.

Apropos sprechen und hören, muss Fhem (open-zwave) auch ZWave+ (ZWave.me) sprechen und hören können, und wenn, versteht das Fhem bereits?

[krikan]

Der LC-13 spricht und hört bereits Z-Wave+

Woher hast Du diese Info; ich konnte keinerlei Zwave+ Zertifizierung für LC13 finden.
Grundfrage: Was ist eigentlich Zwave+?
Frei zugängliche Info: http://www.zwave-review.com/zwave/z-wave-plus.php
Im Buch von Dr. Pätz findet sich auch nicht wirklich softwaretechnisch handfeste Angaben. Bemerkenswert finde ich dort nur, dass die Dokus ausführlicher (Parameters,..) sein müssen; genau das vermisse ich beim LC13.
Fhem und Zwave+ lässt sich erst wirklich beantworten, wenn die Grundfrage geklärt ist. Aber vermutlich: Nein. Problem bleibt, dass es keine frei zugänglichen Infos zum Zwave-Protokoll gibt; nur eben die alte Protokoll-Doku und das was mit Basteln/Recherche durch openzwave oder hier herausgefunden wurde.

Es wäre schon prima, wenn Du weitere Infos zum LC13 bekommen könntest; auch Zwave+ ist sicherlich interessant.

[Didi65]

Ich habe jetzt erstmal abgewartet was von dem allem kommt, was ich angeleiert habe. Bisher war das eher dürftig hier ist die erste Antwort aus dem Z-Wave Forum.

http://www.zwave.de/index.php/kunena/fragen-zu-z-wave-produkten/22-z-wave-heizungs-steuerkopf-fehler-e5

[rudolfkoenig]

Stimmt, da hat wer keine Lust sich damit im Detail auseinanderzusetzen.

Aber es bringt mich auf die Idee "Inspirieren lassen". Ich wuerde erst pruefen, ob Razberry (bzw. was auch immer) mit dem Thermostat funktioniert, das alleine waere eine Hilfestellung. Als zweites die Kommunikation dieser Software mit dem Stick protokollieren (fuer solche Zwecke gibt es diverse Tools), und daraus versuchen zu lernen.

Man koennte die gestern fuer "normale" Geraete aktivierte callbackid auch fuer batterielose einschalten (in ZWave.pm die Zeile mit  "callback=>id" in das vorherige Block fuer WAKE_UP kopieren), allerdings erhoffe ich davon nicht so viel.

[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]

wie 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]

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]

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:

Code Auswählen Erweitern

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

Code Auswählen Erweitern

  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!

Code Auswählen Erweitern

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. 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]

- 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]

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.

[rudolfkoenig]

Frage: 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)

[PNinBB]

@rudolfkoenig:
Danke für den Hinweis; ich werde mich damit beschäftigen, muss aber vorher noch einiges "lernen". Ich werde hier berichten.
Ist die nicht korrekte Erkennung des Thermostaten (Text vor Frage 1) relevant ? Hast du dazu eine Meinung ?
Gruß
Peter

[krikan]

Ist die nicht korrekte Erkennung des Thermostaten (Text vor Frage 1) relevant ? Hast du dazu eine Meinung ?

Auch wenn ich nicht rudolfkoenig bin:
Die XMLs in Fhem kommen von openzwave. Da die sich dort intensiv mit den Besonderheiten der Thermostate beschäftigt habe, sollte man annehmen, dass die Zuordnung korrekt ist. Aber sage niemals nie...
modelIDs werden von Geräten selbst geliefert.

PS: Dein Text ist -vorsichtig formuliert- etwas schwierig zu lesen

[rudolfkoenig]

@krikan: bin ganz deiner Meinung.
@PNinBB: modelConfig zu aendern sollte man nur mit Bedacht, insb. sollte in fhem/FHEM/lib/openzwave_deviceconfig.xml.gz ein passender Eintrag existieren. danfoss/living.xml gibts nicht, danfoss/z.xml schon, allerdings mit von FHEM nicht auswertbaren Eintraegen.

[PNinBB]

@krikan und  @rudolfkoenig
Bezüglich der Bemerkung:

Dein Text ist -vorsichtig formuliert- etwas schwierig zu lesen

Ich danke für die "vorsichtige" Bemerkung und nehme es gern zu Herzen. Es ist wohl meinem jahrelangen Schreiben, Auswerten und Bewerten von Laborberichten geschuldet.
Aber zur Sache:
In der "openzwave_deviceconfig.xml.gz' gibt es beide Einträge:

Code Auswählen Erweitern

<Product sourceFile="danfoss/living.xml">
<CommandClass id="67" base="1" override_precision="2" />
</Product>
<Product sourceFile="danfoss/z.xml">
<CommandClass id="32" action="remove" />
<CommandClass id="67" base="0" override_precision="2" />
</Product>

Ich habe nun die 'openzwave_manufacturer_specific.xml' entsprechend angepasst und in den Readings erscheint der Thermostat nun korrekt. In der Funktionalität ist bisher kein Unterschied zu spüren (ist vielleicht auch nicht zu erwarten, da es nur die CommandClass 67 betrifft), aber ich stehe sicher erst am Anfang.
So wie ich den XML-Text verstehe, wird die CommandClass 32 (Basic) entfernt; was die unterschiedlichen base-Werte bedeuten, ist mir momentan unklar.
Was mein nächstes Projekt betrifft (CLIMATE_CONTROL_SCHEDULE), so werde ich es wohl anders machen: die ganze Funktionalität in PERL und diese dann mit FHEM verbinden.
Gruß
Peter

[krikan]

Hallo Peter,
befürchte Du erwartest etwas zuviel von den XMLs. Deine Änderung kann nicht zu wirklichen funktionalen Änderungen in Fhem führen. Die XMLs dienen in Fhem eigentlich "nur" dazu die Konfigurationsparameter der Zwave-Geräte anzulegen und mit Hilfetexten zu versehen; wesentlich mehr passiert nicht. Ist also quasi ein Komfortfunktion. Bei Deinem Gerät gibt es aber  keine Infos zu den Parametern im XML; der Rest im XML ist für Fhem ohne Relevanz.
Gruß, Christian

[rudolfkoenig]

Ich habe CLOCK (set/get/parse) und CLIMATE_CONTROL_SCHEDULE (set/get/parse) implementiert, allerdings wehrt sich mein Danfoss Living Strangeness (aka DLS) die Daten entgegenzunehmen. Falls jemand mittesten, und was Sinnvolles beitragen kann ("bei mir tut es auch nicht" zaehlt nicht als sinnvoll), dann nur zu.

Das DLS hat beim testen einmal ein komplettes CCS-Report zurueckgeliefert (ich wuesste gerne warum), allerdings mit der Klasse c6 statt 46. Haette jemand dafuer auch eine Erklaerung?

[rudolfkoenig]

Habe die negativen Werte beim CLIMATE_CONTROL_SCHEDULE geaendert (will sagen hoffentlich gefixt).

[PNinBB]

Ich versuche gerade den Danfoss Living Connect (014G0012) in Betrieb zu nehmen (FHEM ist auf neuestem Stand).
Bezüglich CLIMATE_CONTROL_SCHEDULE:
Ich habe in Gerätelistung bei set css als Parameter eingegeben: sun 06:00 10 08:00 -2 13:00 4 17:00 -3 19:00 3 22:00 -12
Im Gerätelog (verbose 5) erscheint:

Code Auswählen Erweitern


2015-03-01_16:04:35 WZ_HZ_TH ccs sun 06:00 10 08:00 -2 13:00 4 17:00 -3 19:00 3 22:00 -12
2015-03-01_16:05:16 WZ_HZ_TH battery: 60 %
2015-03-01_16:05:16 WZ_HZ_TH setpointTemp: 10.0 C heating
2015-03-01_16:05:16 WZ_HZ_TH ccsOverride: no, unused
2015-03-01_16:05:16 WZ_HZ_TH wakeup: notification
2015-03-01_16:10:10 WZ_HZ_TH battery: 60 %
2015-03-01_16:10:10 WZ_HZ_TH setpointTemp: 10.0 C heating
2015-03-01_16:10:10 WZ_HZ_TH ccsOverride: no, unused
2015-03-01_16:10:10 WZ_HZ_TH wakeup: notification
2015-03-01_16:15:03 WZ_HZ_TH battery: 60 %
2015-03-01_16:15:03 WZ_HZ_TH setpointTemp: 10.0 C heating
2015-03-01_16:15:03 WZ_HZ_TH ccsOverride: no, unused
2015-03-01_16:15:03 WZ_HZ_TH wakeup: notification
2015-03-01_16:15:04 WZ_HZ_TH ccs_sun: 06:00 10.0 08:00 -2.0 13:00 4.0 17:00 -3.0 19:00 3.0 22:00 -12.0
2015-03-01_16:15:04 WZ_HZ_TH ccsChanged: 00


Es gibt aber keine Auswirkung auf die später auf der Gerätliste gezeigte Temperatur, d.h. ist wird nichts geändert.

Code Auswählen Erweitern


2015-03-01_17:47:59 WZ_HZ_TH battery: 60 %
2015-03-01_17:48:00 WZ_HZ_TH battery: 60 %
2015-03-01_17:48:02 WZ_HZ_TH battery: 60 %
2015-03-01_17:48:03 WZ_HZ_TH battery: 60 %
2015-03-01_17:48:05 WZ_HZ_TH setpointTemp: 10.0 C heating
2015-03-01_17:48:06 WZ_HZ_TH setpointTemp: 10.0 C heating
2015-03-01_17:48:08 WZ_HZ_TH setpointTemp: 10.0 C heating
2015-03-01_17:48:09 WZ_HZ_TH setpointTemp: 10.0 C heating
2015-03-01_17:48:11 WZ_HZ_TH ccsOverride: no, unused
2015-03-01_17:48:12 WZ_HZ_TH ccsOverride: no, unused
2015-03-01_17:48:14 WZ_HZ_TH ccsOverride: no, unused
2015-03-01_17:48:15 WZ_HZ_TH ccsOverride: no, unused

Unklar sind für mich auch die mehrfachen Einträge.

Versuche ich eine Liste für einen anderen Tag einzugeben, so erscheint die Fehlermeldung: wrong arg, need: <weekday> HH:MM relTemp HH:MM relTemp ...

Frage: Kann man für jeden Tag eine Steuerfolge eintragen ?


Bezüglich CLOCK:
* Wenn ich "Set CLOCK" auswähle, dann gibt es keine "negative" Reaktion.
* Will ich dann die Zeit abfragen, dann gibt es die Information:
   get clock:
   Scheduled for sending after WAKEUP
   Aus Logfile:

Code Auswählen Erweitern


2015-03-01_17:38:12 WZ_HZ_TH battery: 60 %
2015-03-01_17:38:14 WZ_HZ_TH battery: 60 %
2015-03-01_17:38:15 WZ_HZ_TH battery: 60 %
2015-03-01_17:38:17 WZ_HZ_TH battery: 60 %
2015-03-01_17:38:18 WZ_HZ_TH setpointTemp: 10.0 C heating
2015-03-01_17:38:20 WZ_HZ_TH setpointTemp: 10.0 C heating
2015-03-01_17:38:21 WZ_HZ_TH setpointTemp: 10.0 C heating
2015-03-01_17:38:23 WZ_HZ_TH setpointTemp: 10.0 C heating
2015-03-01_17:38:24 WZ_HZ_TH ccsOverride: no, unused
2015-03-01_17:38:26 WZ_HZ_TH ccsOverride: no, unused
2015-03-01_17:38:27 WZ_HZ_TH ccsOverride: no, unused
2015-03-01_17:38:29 WZ_HZ_TH ccsOverride: no, unused

Es wird also keine Zeit zurückgemeldet !?

[rudolfkoenig]

Man kann das Profil definitiv fuer mehrere Tage eingeben, ich habe es sogar geschafft das Profil vom Geraet zurueckzulesen.
Die Fehlermeldung ist noch nicht sehr Benutzerfreundlich, besagt nur, dass das Modul der Ansicht ist, dass die Parameter falsch sind.
Ob ich die Bits richtig setze, oder ob die geaenderten Temperaturen in der Anzeige eine Auswirkung haben sollte, dazu kann ich (noch?) nichts sagen. Ich habe auch schon mal eine Antwort auf "get clock" bekommen. Gefragt habe ich gefuehlt 10-mal

Insg. bin ich vom Geraet enttaeuscht, da
- die gemessene Temperatur nicht zurueckmeldet wird
- die Batterieanzeige innerhalb von einem Tag von 86% zu 40% und dann zu low gewechselt ist. Ich warte jetzt, bis es ausfaellt.
- die gedruckte Installationsanleitung irrefuehrend ist
- am ersten Tag das Ventil zugemacht wird (laut Broschuere ist das Absicht). Im Winter kommt also eine Installation nicht in Frage.
- das Geraet einen schlechten Empfang hat, ich muss ein AN158 als Relay verwenden.
- nach meinem Gefuehl zickig ist, evtl. liegt das aber "nur" am Empfang.

[Didi65]

Also zunächst einmal laufen 2 meiner 3 LC-13 seit der 30 minütigen Batterieabfrage rund. Das eine Thermostat welches nicht rund läuft hat jeden Tag 1 bis 4 Hänger über max. 2,50 Std (Standard 1,00 Std). Diese Hänger kann ich mir derzeit nicht erklären, da das Thermostat ca. 6 m mit freier Sichtverbindung zum Stick entfernt ist.

ALLE neuen get Abfragen haben direkt funktioniert! Per Clock wurde die Uhrzeit auch einwandfrei eingestellt, allerdings läuft das Sch...ding im Thermostat viel zu schnell. Innerhalb 5 Std. ca. 6 min. Das könnte man aber auch automatisieren...

Die set + get ccs funktionieren problemlos. Es wird alles korrekt eingetragen und natürlich auch beim get abgefragt.

Super Arbeit - Vielen Dank!

Für mich bleiben nur noch 3 Fragen. Wie kann ich den Thermostat mit dem Sensor verbinden ... können mir da Variable helfen? Wofür taugt ccsChanged und ccsOverride und wie weiss ich welche get, set und parse parameter ich in die 10_zwave eingeben muss. Die SDS11060-7 Z-Wave Command Class Specification habe ich bereits.

Gruß
Dietmar

Ps.: Die anfänglichen Batterien hielten ca. 4 Monate, nachdem die Thermostate alle 5 min senden und die Batterie alle 30 min. abgefragt werden, halten die Batterien (Akkus) ca. 2 Wochen. Natürlich ist das mit der Konfiguration der Thermostaten zäh ... und am Anfang war ich auch enttäuscht, gerade wenn man sich nicht selbst helfen kann und auf andere angewiesen ist. Aber gerade mit den neuesten Änderungen von Rudolf sehe ich Licht am Ende des Tunnels.

Übrigens kann man in den Beschreibungen von Danfoss nachlesen, dass es den LC-13 nur gibt, weil die früheren Thermostate nicht so toll mit Z-Wave gearbeitet haben - wenn ich jetzt die Posts so nachlese kann ich das nachvollziehen - bei mir (LC-13) werden wirklich ALLE get Abfragen sofort und einwandfrei übertragen.

[rudolfkoenig]

Wie kann ich den Thermostat mit dem Sensor verbinden ...

Verstehe die Frage nicht. Oder "define xx notify sensor:... set lc13 setpointHeating $EVENT1" (oder so).

Wofür taugt ccsChanged und ccsOverride

Steht im PDF. Mein Verstaendnis: ccsChanged verraet, ob man am Geraet direkt rumgefummelt hat, und ccsOverride verbietet das rumfummeln.

wie weiss ich welche get, set und parse parameter ich in die 10_zwave eingeben muss.

Na dafuer ist jetzt zuspaet. Fuer weitere, nicht implementierte Klassen bitte selbst ueberlegen. Wenn man es selbst nicht rauskriegt, dann sollte man es vermutlich anderen ueberlassen.

[Mundus]

Hallo FHEM-Gemeinde,

ich habe auch den Danfoss LC-13 (014G0013), leider funktioniert er noch nicht ganz perfekt... Leider kann ich den Befehl

Code Auswählen Erweitern

set <THERMOSTAT> setpointHeating
nur mit ganzzahligen Werten (4,...,28) absetzen. Sobald ich
20,5 oder 20.5 eingeben will

Code Auswählen Erweitern

set <THERMOSTAT> setpointHeating 20.5 erhalte ich die Fehlermeldung

Error: 20.5 is not a decimal number

Leider weiß ich nicht, wo mein Fehler ist. Am Thermostat kann ich die Werte in 0.5 Steps einstellen.

Viele Grüße

Mundus

[krikan]

Hallo!
Der Befehl setpointHeating akzeptiert laut http://fhem.de/commandref#ZWave nur ganzzahlige Werte. Wenn Du es genauer haben möchtest, solltest Du -falls vorhanden- thermostatSetpointSet nehmen. Mehr zu dem Befehl auch in der commandref.
Gruß, Christian

[jay-jey]

Hallo,

also ich hätte da auch (eine vielleicht doofe) Frage zum Thema CLIMATE_CONTROL_SCHEDULE. Ich habe nun auch versucht einen Plan zu hinterlegen aber anscheinend wird der auch nicht vom Thermostaten übernommen. Also ich kann ihn set einfügen und ich kann ihn auch per get auslesen. Nur die Temperatur ändert sich nicht. Ich habe einfach

Code Auswählen Erweitern

set Schlafz_Heizung ccs thu 06:00 4.0 09:00 0.0 12:00 4.0 23:00 0.0

eingegeben. Muss ich den Plan noch irgendwie aktivieren, konnte dazu nichts finden.

Hier mal ein List vom Gerät

Code Auswählen Erweitern

Internals:
   DEF        c3b60621 7
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     20
   NAME       Schlafz_Heizung
   NR         122
   STATE      wakeupInterval 86400 1
   TYPE       ZWave
   ZWDongle_0_MSGCNT 20
   ZWDongle_0_RAWMSG 00040007028407
   ZWDongle_0_TIME 2016-11-10 16:25:34
   ZWaveSubDevice no
   homeId     c3b60621
   isWakeUp   1
   lastMsgSent 1478791536.11734
   nodeIdHex  07
   Readings:
     2016-11-05 09:26:49   CMD             ZW_APPLICATION_UPDATE
     2016-11-10 16:25:33   battery         95 %
     2016-11-10 13:00:50   ccsChanged      00
     2016-11-10 16:25:34   ccsOverride     no, unused
     2016-11-10 13:00:51   ccs_fri         06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
     2016-11-10 13:00:50   ccs_mon         06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
     2016-11-10 13:00:51   ccs_sat         06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
     2016-11-10 13:00:51   ccs_sun         06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
     2016-11-10 13:00:51   ccs_thu         06:00 4.0 09:00 0.0 12:00 4.0 23:00 0.0
     2016-11-10 13:00:51   ccs_tue         06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
     2016-11-10 13:00:51   ccs_wed         06:00 4.0 09:00 0.0 17:00 4.0 23:00 0.0
     2016-11-10 13:00:50   clock           thu 12:38
     2016-10-31 13:36:09   model           Danfoss Z Thermostat 014G0013
     2016-10-31 13:36:09   modelConfig     danfoss/z.xml
     2016-10-31 13:36:09   modelId         0002-0005-0004
     2016-11-10 16:25:33   setpointTemp    17.00 C heating
     2016-10-31 13:36:07   state           wakeupInterval 86400 1
     2016-11-10 16:25:36   timeToAck       0.027
     2016-11-10 16:25:36   transmit        OK
     2016-11-10 16:25:34   wakeup          notification
Attributes:
   IODev      ZWDongle_0
   classes    BATTERY CLIMATE_CONTROL_SCHEDULE CLOCK MANUFACTURER_SPECIFIC MULTI_CMD PROTECTION THERMOSTAT_SETPOINT VERSION WAKE_UP MARK CLIMATE_CONTROL_SCHEDULE CLOCK MULTI_CMD
   room       ZWave
   vclasses   BATTERY:1 CLIMATE_CONTROL_SCHEDULE:1 CLOCK:1 MANUFACTURER_SPECIFIC:1 MULTI_CMD:1 PROTECTION:2 THERMOSTAT_SETPOINT:2 VERSION:1 WAKE_UP:2
   verbose    5

und ein Auszug aus dem LOG

Code Auswählen Erweitern

2016-11-10_01:48:09 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_01:48:09 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_02:17:22 Schlafz_Heizung battery: 96 %
2016-11-10_02:17:22 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_02:17:22 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_02:17:22 Schlafz_Heizung wakeup: notification
2016-11-10_02:46:37 Schlafz_Heizung battery: 96 %
2016-11-10_02:46:37 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_02:46:37 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_02:46:37 Schlafz_Heizung wakeup: notification
2016-11-10_03:15:52 Schlafz_Heizung battery: 96 %
2016-11-10_03:15:52 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_03:15:52 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_03:15:52 Schlafz_Heizung wakeup: notification
2016-11-10_03:45:06 Schlafz_Heizung battery: 96 %
2016-11-10_03:45:06 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_03:45:06 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_03:45:07 Schlafz_Heizung wakeup: notification
2016-11-10_04:14:21 Schlafz_Heizung battery: 96 %
2016-11-10_04:14:21 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_04:14:21 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_04:14:21 Schlafz_Heizung wakeup: notification
2016-11-10_04:43:36 Schlafz_Heizung battery: 96 %
2016-11-10_04:43:36 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_04:43:36 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_04:43:36 Schlafz_Heizung wakeup: notification
2016-11-10_05:12:51 Schlafz_Heizung battery: 96 %
2016-11-10_05:12:51 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_05:12:51 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_05:12:51 Schlafz_Heizung wakeup: notification
2016-11-10_05:42:09 Schlafz_Heizung battery: 96 %
2016-11-10_05:42:09 Schlafz_Heizung battery: 96 %
2016-11-10_05:42:09 Schlafz_Heizung battery: 96 %
2016-11-10_05:42:09 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_05:42:09 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_06:11:21 Schlafz_Heizung battery: 96 %
2016-11-10_06:11:21 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_06:11:21 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_06:11:21 Schlafz_Heizung wakeup: notification
2016-11-10_06:40:36 Schlafz_Heizung battery: 96 %
2016-11-10_06:40:36 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_06:40:36 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_06:40:36 Schlafz_Heizung wakeup: notification
2016-11-10_07:09:51 Schlafz_Heizung battery: 96 %
2016-11-10_07:09:51 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_07:09:51 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_07:09:51 Schlafz_Heizung wakeup: notification
2016-11-10_07:39:06 Schlafz_Heizung battery: 96 %
2016-11-10_07:39:07 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_07:39:07 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_07:39:07 Schlafz_Heizung wakeup: notification
2016-11-10_08:08:22 Schlafz_Heizung battery: 96 %
2016-11-10_08:08:22 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_08:08:22 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_08:08:22 Schlafz_Heizung wakeup: notification
2016-11-10_08:37:36 Schlafz_Heizung battery: 96 %
2016-11-10_08:37:37 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_08:37:37 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_08:37:37 Schlafz_Heizung wakeup: notification
2016-11-10_09:06:54 Schlafz_Heizung battery: 96 %
2016-11-10_09:06:54 Schlafz_Heizung battery: 96 %
2016-11-10_09:06:54 Schlafz_Heizung battery: 96 %
2016-11-10_09:06:54 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_09:06:54 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_09:36:08 Schlafz_Heizung battery: 96 %
2016-11-10_09:36:08 Schlafz_Heizung battery: 96 %
2016-11-10_09:36:08 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_09:36:08 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_10:05:21 Schlafz_Heizung battery: 96 %
2016-11-10_10:05:21 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_10:05:21 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_10:05:21 Schlafz_Heizung wakeup: notification
2016-11-10_10:34:36 Schlafz_Heizung battery: 96 %
2016-11-10_10:34:36 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_10:34:36 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_10:34:36 Schlafz_Heizung wakeup: notification
2016-11-10_10:34:36 Schlafz_Heizung ccs_mon: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_10:34:36 Schlafz_Heizung ccs_tue: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_10:34:36 Schlafz_Heizung ccs_wed: 06:00 4.0 09:00 0.0 17:00 4.0 23:00 0.0
2016-11-10_10:34:36 Schlafz_Heizung ccs_thu: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_10:34:37 Schlafz_Heizung ccs_fri: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_10:34:37 Schlafz_Heizung ccs_sat: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_10:34:37 Schlafz_Heizung ccs_sun: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_11:03:51 Schlafz_Heizung battery: 96 %
2016-11-10_11:03:51 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_11:03:51 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_11:03:51 Schlafz_Heizung wakeup: notification
2016-11-10_11:33:06 Schlafz_Heizung battery: 96 %
2016-11-10_11:33:06 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_11:33:06 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_11:33:06 Schlafz_Heizung wakeup: notification
2016-11-10_11:33:06 Schlafz_Heizung ccs_mon: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_11:33:06 Schlafz_Heizung ccs_tue: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_11:33:06 Schlafz_Heizung ccs_wed: 06:00 4.0 09:00 0.0 17:00 4.0 23:00 0.0
2016-11-10_11:33:06 Schlafz_Heizung ccs_thu: 06:00 4.0 09:00 0.0 12:00 4.0 23:00 0.0
2016-11-10_11:33:06 Schlafz_Heizung ccs_fri: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_11:33:06 Schlafz_Heizung ccs_sat: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_11:33:06 Schlafz_Heizung ccs_sun: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_12:02:21 Schlafz_Heizung battery: 96 %
2016-11-10_12:02:21 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_12:02:21 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_12:02:21 Schlafz_Heizung wakeup: notification
2016-11-10_12:02:21 Schlafz_Heizung clock: thu 11:34
2016-11-10_12:02:21 Schlafz_Heizung clock: thu 11:38
2016-11-10_12:31:39 Schlafz_Heizung battery: 96 %
2016-11-10_12:31:39 Schlafz_Heizung battery: 96 %
2016-11-10_12:31:39 Schlafz_Heizung battery: 96 %
2016-11-10_12:31:39 Schlafz_Heizung battery: 96 %
2016-11-10_12:31:39 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_12:31:39 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_13:00:50 Schlafz_Heizung battery: 95 %
2016-11-10_13:00:50 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_13:00:50 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_13:00:50 Schlafz_Heizung wakeup: notification
2016-11-10_13:00:50 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_13:00:50 Schlafz_Heizung ccsChanged: 00
2016-11-10_13:00:50 Schlafz_Heizung clock: thu 12:38
2016-11-10_13:00:50 Schlafz_Heizung ccs_mon: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_13:00:51 Schlafz_Heizung ccs_tue: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_13:00:51 Schlafz_Heizung ccs_wed: 06:00 4.0 09:00 0.0 17:00 4.0 23:00 0.0
2016-11-10_13:00:51 Schlafz_Heizung ccs_thu: 06:00 4.0 09:00 0.0 12:00 4.0 23:00 0.0
2016-11-10_13:00:51 Schlafz_Heizung ccs_fri: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_13:00:51 Schlafz_Heizung ccs_sat: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_13:00:51 Schlafz_Heizung ccs_sun: 06:00 4.0 09:00 0.0 16:00 4.0 23:00 0.0
2016-11-10_13:30:05 Schlafz_Heizung battery: 95 %
2016-11-10_13:30:05 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_13:30:05 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_13:30:05 Schlafz_Heizung wakeup: notification
2016-11-10_13:59:19 Schlafz_Heizung battery: 95 %
2016-11-10_13:59:19 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_13:59:19 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_13:59:19 Schlafz_Heizung wakeup: notification
2016-11-10_14:28:34 Schlafz_Heizung battery: 95 %
2016-11-10_14:28:34 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_14:28:34 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_14:28:34 Schlafz_Heizung wakeup: notification
2016-11-10_14:57:49 Schlafz_Heizung battery: 95 %
2016-11-10_14:57:49 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_14:57:49 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_14:57:49 Schlafz_Heizung wakeup: notification
2016-11-10_15:27:04 Schlafz_Heizung battery: 95 %
2016-11-10_15:27:04 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_15:27:04 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_15:27:04 Schlafz_Heizung wakeup: notification
2016-11-10_15:56:19 Schlafz_Heizung battery: 95 %
2016-11-10_15:56:19 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_15:56:19 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_15:56:19 Schlafz_Heizung wakeup: notification
2016-11-10_16:25:33 Schlafz_Heizung battery: 95 %
2016-11-10_16:25:33 Schlafz_Heizung setpointTemp: 17.00 C heating
2016-11-10_16:25:34 Schlafz_Heizung ccsOverride: no, unused
2016-11-10_16:25:34 Schlafz_Heizung wakeup: notification

[A.Harrenberg]

Hi,

ich kann es gerade nicht definitiv bestätigen, bin aber der Meinung das man da einen "permaneten Override" aktivieren muss. Wie das geht kann ich gerade nicht sagen...

Gruß,
Andreas.

[jay-jey]

Hi,

kann leider nichts zu einem Befehl permanent Override finden. Hat vielleicht noch jemand ne Idee? Hat jemand das ganze vielleicht auch anders gelöst?

[A.Harrenberg]

Hi JJ,

habe gerade mal im Code nachgeschaut, die Klasse ist leider (noch) nicht vollständig implementiert, die Befehle die ich da mit "Override" im Kopf hatte fehlen da. Allerdings habe ich auch mal kurz in die Beschreibung dieser Funktionen geschaut und die dienen nur dazu die eingestellt Schedule zu überschreiben. Also sollte es eigentlich mit Deiner eingestellten Schedule funktionieren.

Woran machst Du denn fest das die Temperatur sich nicht ändert? Display?

Gruß,
Andreas.

[buspirat]

Kurzer Nachtrag zum "E5-Fehler", der vor allem viele Nutzer im Frühjahr 2015 geplagt hatte:
Ein baugleiches Deveolo Thermostat von April 2016 ("Danfoss devolo Thermostat MT2650") läuft seit über zehn Tagen ohne zusätzliche Batterie-Abfrage per at-Befehl. Das Thermostat wacht von selbst alle 30 Minuten auf.

Die Status-Rückmeldung verschluckt/verdoppelt manchmal Werte:

Code Auswählen Erweitern


2016-11-13_17:03:15 Heizung_Bad battery: 84 %
2016-11-13_17:32:47 Heizung_Bad battery: 84 %
2016-11-13_17:32:47 Heizung_Bad setpointTemp: 16.00 C heating
2016-11-13_17:32:47 Heizung_Bad setpointTemp: 16.00 C heating
2016-11-13_17:32:48 Heizung_Bad setpointTemp: 16.00 C heating
2016-11-13_18:02:19 Heizung_Bad battery: 84 %
2016-11-13_18:02:20 Heizung_Bad battery: 84 %
2016-11-13_18:31:52 Heizung_Bad battery: 84 %
2016-11-13_19:01:25 Heizung_Bad battery: 84 %
2016-11-13_19:01:25 Heizung_Bad battery: 84 %
2016-11-13_19:30:57 Heizung_Bad battery: 84 %
2016-11-13_19:30:58 Heizung_Bad battery: 84 %
2016-11-13_20:00:30 Heizung_Bad battery: 84 %
2016-11-13_20:00:30 Heizung_Bad battery: 84 %
2016-11-13_20:00:30 Heizung_Bad setpointTemp: 16.00 C heating
2016-11-13_20:00:31 Heizung_Bad setpointTemp: 16.00 C heating
2016-11-13_20:30:03 Heizung_Bad battery: 84 %
2016-11-13_20:30:03 Heizung_Bad setpointTemp: 16.00 C heating
2016-11-13_20:30:03 Heizung_Bad setpointTemp: 16.00 C heating
2016-11-13_20:59:36 Heizung_Bad battery: 84 %
2016-11-13_20:59:36 Heizung_Bad battery: 84 %
2016-11-13_20:59:36 Heizung_Bad battery: 84 %
2016-11-13_21:29:09 Heizung_Bad battery: 84 %
2016-11-13_21:58:42 Heizung_Bad battery: 84 %
2016-11-13_21:58:42 Heizung_Bad setpointTemp: 16.00 C heating
2016-11-13_21:58:42 Heizung_Bad ccsOverride: no, unused
2016-11-13_21:58:43 Heizung_Bad temperature: 18.76 C
2016-11-13_21:58:43 Heizung_Bad temperature: 18.76 C


-> normalerweise wird die Temperatur mitgeschickt, ebenso die "wakeUp Notification".

[Damu]

Hallo

Habe auch 2 Danfoss LC-13 (014G0013).
Bei einem habe ich seit ca 4 Tagen das

Atdanfoss_Thermostat_.....

auf Inaktiv gesetzt.
Hatte bis jetzt noch keinen Ausfall.
Braucht es das Batterie_Abfrage-At Befehl wirklich oder etwa nur bis das Danfoss sich richtig eingestellt hat?
Habe auch ein baugleiches Devolo das läuft auch gut.
Natürlich ohne Abfrage_Befehl.
Sind meine ersten Zwave Geräte.

Bei mir passen leider nur die Danfoss Thermostate in die UP Kästen für die Fusbodenheizung.

Ist aber irgendwie blöd das mann bei einem E5 Fehler die Batterie entfernen muss.
Das heist bei mir ganze Abdeckung entfernen............

[Adnohmi]

Hallo kann mir einer helfen ich habe meine Danfoss LC-13 über das Tahoma Modul eingebunden, sie funktionieren auch so weit nur da ich noch Neuling bin was FHEM betrifft weiss ich leider nicht wie das HomebridgeMapping und das userReadings dazu aussehen muß damit ich es über das HomeKit am Iphone steuern kann.