HM-CC-RT-DN mit LaCrosse virtuelle Temperatur Sensoren hat Aussetzer

Begonnen von Merlin, 15 Dezember 2015, 19:10:39

Vorheriges Thema - Nächstes Thema

Merlin

Zitat von: martinp876 am 10 Januar 2016, 09:28:34
Ich habe einmal einen virtuellen Sensor aufgesetzt. Hat geklappt, habe keine Aussetzer bemerkt.

Ich fürchte unter Laborbedingungen mit nur einem VT/RT wird das schwer nachzustellen. Das macht ja vermutlich auch die Analyse so schwert.
Meine Erkenntnis ist je mehr Last, Funkverkehr usw anstehen umso öfter tritt der Fehler auf.

martinp876


thaliondrambor

Ich beobachte das Problem auch schon seit längerer Zeit. Da ich nach einer Lösung bereits im letzten Jahr gesucht hatte, wo es diesen Post noch nicht gab, habe ich gestern Abend einen neuen aufgemacht. Dieser ist hier zu finden: http://forum.fhem.de/index.php?topic=47379.msg391051

Ich habe heute Nacht mal Apptime laufen gelassen:



                                name             function    max  count    total  average maxDly
                       SqueezeServer       SB_SERVER_Read   1151   1347     9712     7.21      0 HASH(SqueezeServer)
                         tmr-at_Exec      HASH(0x5696060)   1091      1     1091  1091.00      4 HASH(AquariumHeizungEin)
                     SK_Temp_Verlauf            dummy_Set   1089      1     1089  1089.00      0 HASH(SK_Temp_Verlauf); SK_Temp_Verlauf; on
                         SK_Schalten          notify_Exec   1081      1     1081  1081.00      0 HASH(SK_Schalten); HASH(SK_Temp_Verlauf)
             tmr-CUL_HM_updateConfig         updateConfig   1051      1     1051  1051.00      0 updateConfig
                       myJeeLink_866       JeeLink_Define   1027      1     1027  1027.00      0 HASH(myJeeLink_866); myJeeLink_866 JeeLink /dev/ttyUSB0@57600
                 tmr-Calendar_Wakeup      HASH(0x5111a58)    413     15     5008   333.87      2 HASH(Abfall)
                          PushBullet    Pushbullet_Define    408      1      408   408.00      0 HASH(PushBullet); PushBullet Pushbullet lPwQydXJnTsmYvQFgKe9wOAjSQZi200h
                       myJeeLink_866         JeeLink_Read    337      7      814   116.29      0 HASH(myJeeLink_866)
                       SK_AQ2_Heizen        THRESHOLD_Set    279      1      279   279.00      0 HASH(SK_AQ2_Heizen); SK_AQ2_Heizen; desired; 22.1
                       SK_AQ1_Heizen        THRESHOLD_Set    278      6      278    46.33      0 HASH(SK_AQ1_Heizen); SK_AQ1_Heizen; desired; 22.1
                              HMLAN1           HMLAN_Read    271   7678    61631     8.03      0 HASH(HMLAN1)
                       SK_AQ1_Heizen     THRESHOLD_Notify    268  30129      777     0.03      0 HASH(SK_AQ1_Heizen); HASH(SK_AQ1_TemperaturSensor)
                       SK_AQ2_Heizen     THRESHOLD_Notify    264  30129      678     0.02      0 HASH(SK_AQ2_Heizen); HASH(SK_AQ2_TemperaturSensor)
                         tmr-at_Exec      HASH(0x4d061a0)    258    860    91914   106.88      5 HASH(VirtuelleTemperatur)
                      SK_AQ1_Heizung               IT_Set    257      3      767   255.67      0 HASH(SK_AQ1_Heizung); SK_AQ1_Heizung; off
                             CUL_433              CUL_Get    256      8     2029   253.62      0 HASH(CUL_433);  ; raw; is0FFFF00FFFF0
                        SK_AQ1_Licht               IT_Set    254      1      254   254.00      0 HASH(SK_AQ1_Licht); SK_AQ1_Licht; on
                        SK_AQ2_Licht               IT_Set    254      1      254   254.00      0 HASH(SK_AQ2_Licht); SK_AQ2_Licht; on
                      SK_AQ2_Heizung               IT_Set    253      3      759   253.00      0 HASH(SK_AQ2_Heizung); SK_AQ2_Heizung; off
                         tmr-at_Exec      HASH(0x53391c8)    201      1      201   201.00      1 HASH(SK_Temp_berechnen)


Ich habe übrigens Thermostate mit 1.3 und 1.4 und der Fehler tritt bei allen auf.

Ich hänge mal noch meinen Log dran, wo alle Abweichungen zwischen Thermostat und Sensor größer als 0.5K erfasst werden.

Gibt es etwas was ich zur Unterstützung der Fehlersuche beitragen kann? Infos, Versuche?

frank

                       SK_AQ1_Heizen     THRESHOLD_Notify    268  30129      777     0.03      0 HASH(SK_AQ1_Heizen); HASH(SK_AQ1_TemperaturSensor)
                       SK_AQ2_Heizen     THRESHOLD_Notify    264  30129      678     0.02      0 HASH(SK_AQ2_Heizen); HASH(SK_AQ2_TemperaturSensor)

in einer nacht jeweils über 30000 aufrufe ist sicherlich zuviel und unnötig.  :)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Merlin

Hallo,

ich habe bei der "erweiterten Fehlersuche" etwas entdeckt:
der NTP daemon beeinflusst das Timigverhalten extrem negativ! Da hier ja das Timing sehr eng ist und sehr exakt sein muss, sind permanante Aktualiesierungen der Systemzeit wohl sehr kontraproduktiv!

Hab das durch Zufall entdeckt. Auf einem Testsystem mit Minimalkonfiguration hab ich inzwischen mit der Timig Firmware Erweiterung vom CUL eine recht stabile Konfiguration. Dann ist mir aufgefallen das die Uhrzeiten im Log nicht 100% passen und ich den ntp vergessen hatte zu installieren. Hab den nachinstalliert und das System ist wieder komplett ausgeflippt! Wieder deinstalliert und alles ist wieder gut.

Kann das jemand nachstellen/bestätigen?


Hollo

Zitat von: Merlin am 14 Januar 2016, 13:59:13
...der NTP daemon beeinflusst das Timigverhalten extrem negativ! ...
Kann das jemand nachstellen/bestätigen?
Dann war ich hier http://forum.fhem.de/index.php/topic,45735.msg386221.html#msg386221 (vorletzter Absatz) ja schon auf der richtigen Spur.
Mein BananaPro wird übrigens auch per ntp-Daemon von meinem Server "syncronisiert".
Werde den Dienst mal stoppen und beobachten.

Parallel ist mir aufgefallen, dass die zyklische Aktualisierung des MPD (anderer Rechner) ganz schön bremst.
Da gab es auch schon mal Meldungen, dass fhem quasi einfriert, wenn ein MPD-Server nicht mehr erreichbar ist...  ???
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

thaliondrambor

#96
Zitat von: frank am 14 Januar 2016, 13:44:49
                       SK_AQ1_Heizen     THRESHOLD_Notify    268  30129      777     0.03      0 HASH(SK_AQ1_Heizen); HASH(SK_AQ1_TemperaturSensor)
                       SK_AQ2_Heizen     THRESHOLD_Notify    264  30129      678     0.02      0 HASH(SK_AQ2_Heizen); HASH(SK_AQ2_TemperaturSensor)

in einer nacht jeweils über 30000 aufrufe ist sicherlich zuviel und unnötig.  :)

Ich sehe ein, dass es etwas viel ist, aber ich weiß gerade nicht, wie ich daran was ändern soll. Eine Ausgabe von Apptime sortiert nach der Häufigkeit der Counts ergibt, dass alle Dinge die auf Ereignisse warten, so oft ausgeführt werden (notifys, thresholds, logs).

                                name             function    max  count    total  average maxDly
                       AlleHeizungen     structure_Notify     14   1427       85     0.06      0 HASH(AlleHeizungen); HASH(ZE.Batterie)
               FileLog_bz_Temperatur          FileLog_Log     14   1427      180     0.13      0 HASH(FileLog_bz_Temperatur); HASH(wc_Temperatur)
               FileLog_ez_Temperatur          FileLog_Log     12   1427       87     0.06      0 HASH(FileLog_ez_Temperatur); HASH(ku_Temperatur)
               FileLog_ke_Temperatur          FileLog_Log      6   1427      107     0.07      0 HASH(FileLog_ke_Temperatur); HASH(SchildkroetenWarnung_2)
               FileLog_ku_Temperatur          FileLog_Log     18   1427      129     0.09      0 HASH(FileLog_ku_Temperatur); HASH(ZE.Batterie)
               FileLog_os_Temperatur          FileLog_Log     13   1427      127     0.09      0 HASH(FileLog_os_Temperatur); HASH(bz_v_Temperatur)
               FileLog_sz_Temperatur          FileLog_Log     10   1427       95     0.07      0 HASH(FileLog_sz_Temperatur); HASH(sz_v_Temperatur)
               FileLog_wc_Temperatur          FileLog_Log     22   1427      125     0.09      0 HASH(FileLog_wc_Temperatur); HASH(ZE.Batterie)
                              HMLAN1         HMLAN_Notify      5   1427        7     0.00      0 HASH(HMLAN1); HASH(ZE.Batterie)
                             Logfile          FileLog_Log     24   1427      156     0.11      0 HASH(Logfile); HASH(SensorFehler)
                           SB_Kindle     SB_PLAYER_Notify     35   1427      942     0.66      0 HASH(SB_Kindle); HASH(ZE.Batterie)
                        SB_S5_Norman     SB_PLAYER_Notify     29   1427      987     0.69      0 HASH(SB_S5_Norman); HASH(ZE.Batterie)
                       SK_AQ1_Heizen     THRESHOLD_Notify      6   1427       25     0.02      0 HASH(SK_AQ1_Heizen); HASH(ZE.Batterie)
                       SK_AQ2_Heizen     THRESHOLD_Notify      5   1427       15     0.01      0 HASH(SK_AQ2_Heizen); HASH(sz_v_temp)
              SchildkroetenWarnung_0     THRESHOLD_Notify     33   1427      259     0.18      0 HASH(SchildkroetenWarnung_0); HASH(ke_TemperaturSensor)
              SchildkroetenWarnung_1     THRESHOLD_Notify     28   1427      245     0.17      0 HASH(SchildkroetenWarnung_1); HASH(ke_TemperaturSensor)
              SchildkroetenWarnung_2     THRESHOLD_Notify     29   1427      236     0.17      0 HASH(SchildkroetenWarnung_2); HASH(ke_TemperaturSensor)
               SchildkroetenZuKalt_0     THRESHOLD_Notify    559   1427      777     0.54      0 HASH(SchildkroetenZuKalt_0); HASH(ke_TemperaturSensor)
               SchildkroetenZuKalt_1     THRESHOLD_Notify    566   1427      846     0.59      0 HASH(SchildkroetenZuKalt_1); HASH(ke_TemperaturSensor)
               SchildkroetenZuKalt_2     THRESHOLD_Notify     59   1427      239     0.17      0 HASH(SchildkroetenZuKalt_2); HASH(ke_TemperaturSensor)
                       SqueezeServer     SB_SERVER_Notify      8   1427       32     0.02      0 HASH(SqueezeServer); HASH(kz_TemperaturSensor)
                 WA_Handy_Norman_Log          FileLog_Log     31   1427     2378     1.67      0 HASH(WA_Handy_Norman_Log); HASH(ZE.Batterie)
                                 WEB            FW_Notify      2   1427        7     0.00      0 HASH(WEB); HASH(ku_v_Temperatur)
            WEB_192.168.100.37_54565            FW_Notify      8   1427       19     0.01      0 HASH(WEB_192.168.100.37_54565); HASH(kz_v_temp)
            WEB_192.168.100.37_54566            FW_Notify     13   1427       19     0.01      0 HASH(WEB_192.168.100.37_54566); HASH(ZE.Batterie)
            WEB_192.168.100.37_54567            FW_Notify      5   1427        9     0.01      0 HASH(WEB_192.168.100.37_54567); HASH(os_TemperaturSensor)
            WEB_192.168.100.37_54568            FW_Notify     14   1427       26     0.02      0 HASH(WEB_192.168.100.37_54568); HASH(ZE.Batterie)
                            WEBphone            FW_Notify      3   1427        7     0.00      0 HASH(WEBphone); HASH(wz_TemperaturSensor)
                           WEBtablet            FW_Notify      2   1427        4     0.00      0 HASH(WEBtablet); HASH(SensorFehler)
                         ZE.Activity readingsGroup_Notify     46   1427     5390     3.78      0 HASH(ZE.Activity); HASH(ez_Thermostat)
                         ZE.Batterie readingsGroup_Notify    122   1427    19677    13.79      0 HASH(ZE.Batterie); HASH(ez_TemperaturSensor)
                       ZE.Empfaenger readingsGroup_Notify     32   1427       80     0.06      0 HASH(ZE.Empfaenger); HASH(global)
                       ZE.MotorError readingsGroup_Notify     84   1427     5810     4.07      0 HASH(ZE.MotorError); HASH(ku_Thermostat)
                     ZE.WatchCUL_433      watchdog_Notify     10   1427      116     0.08      0 HASH(ZE.WatchCUL_433); HASH(ez_TemperaturSensor)
                ZE.WatchCUL_433_long      watchdog_Notify     14   1427       52     0.04      0 HASH(ZE.WatchCUL_433_long); HASH(os_TemperaturSensor)
                      ZE.WatchHMLAN1      watchdog_Notify     11   1427      100     0.07      0 HASH(ZE.WatchHMLAN1); HASH(wc_TemperaturSensor)
                 ZE.WatchHMLAN1_long      watchdog_Notify     11   1427       51     0.04      0 HASH(ZE.WatchHMLAN1_long); HASH(wc_Thermostat_Weather)
               ZE.WatchmyJeeLink_866      watchdog_Notify     11   1427       73     0.05      0 HASH(ZE.WatchmyJeeLink_866); HASH(bz_v_Temperatur)
          ZE.WatchmyJeeLink_866_long      watchdog_Notify     14   1427       63     0.04      0 HASH(ZE.WatchmyJeeLink_866_long); HASH(Verbrauch)
                          eventTypes    eventTypes_Notify     23   1427      117     0.08      0 HASH(eventTypes); HASH(bz_Thermostat)
                   n_FTUI_Thermostat          notify_Exec     28   1427     1877     1.32      0 HASH(n_FTUI_Thermostat); HASH(ZE.Batterie)
                        n_weatherNow          notify_Exec     28   1427     1706     1.20      0 HASH(n_weatherNow); HASH(kz_Thermostat)
                            wc_n_PIR          notify_Exec     22   1427      261     0.18      0 HASH(wc_n_PIR); HASH(ez_TemperaturSensor)


Das ist in geschätzen 15 Minuten nach Start von Apptime zusammen gekommen.

Edit: Ich habe apptime gerade mal gestartet und nach wenigen Sekunden das Ergebnis angesehen. ALLE notifys und logs haben nach wenigen Sekunden bereits vier Aufrufe. Die meisten davon haben zusammen 0ms Dauer. Ich mache mir über die 30000 erstmal keine Gedanken.

                                name             function    max  count    total  average maxDly
                       myJeeLink_866         JeeLink_Read     17     10       57     5.70      0 HASH(myJeeLink_866)
                       AlleHeizungen     structure_Notify      0      4        0     0.00      0
               FileLog_bz_Temperatur          FileLog_Log      0      4        0     0.00      0
               FileLog_ez_Temperatur          FileLog_Log      0      4        0     0.00      0
               FileLog_ke_Temperatur          FileLog_Log      0      4        0     0.00      0
               FileLog_ku_Temperatur          FileLog_Log      0      4        0     0.00      0
               FileLog_os_Temperatur          FileLog_Log      0      4        0     0.00      0
               FileLog_sz_Temperatur          FileLog_Log      1      4        1     0.25      0 HASH(FileLog_sz_Temperatur); HASH(ku_TemperaturSensor)
               FileLog_wc_Temperatur          FileLog_Log      0      4        0     0.00      0
                              HMLAN1         HMLAN_Notify      0      4        0     0.00      0
                             Logfile          FileLog_Log      0      4        0     0.00      0
                           SB_Kindle     SB_PLAYER_Notify      0      4        0     0.00      0
                        SB_S5_Norman     SB_PLAYER_Notify      0      4        0     0.00      0
                       SK_AQ1_Heizen     THRESHOLD_Notify      0      4        0     0.00      0
                       SK_AQ2_Heizen     THRESHOLD_Notify      0      4        0     0.00      0
              SchildkroetenWarnung_0     THRESHOLD_Notify      0      4        0     0.00      0
              SchildkroetenWarnung_1     THRESHOLD_Notify      0      4        0     0.00      0
              SchildkroetenWarnung_2     THRESHOLD_Notify      0      4        0     0.00      0
               SchildkroetenZuKalt_0     THRESHOLD_Notify      0      4        0     0.00      0
               SchildkroetenZuKalt_1     THRESHOLD_Notify      0      4        0     0.00      0
               SchildkroetenZuKalt_2     THRESHOLD_Notify      1      4        1     0.25      0 HASH(SchildkroetenZuKalt_2); HASH(ke_TemperaturSensor)
                       SqueezeServer     SB_SERVER_Notify      0      4        0     0.00      0
                 WA_Handy_Norman_Log          FileLog_Log      3      4        3     0.75      0 HASH(WA_Handy_Norman_Log); HASH(wz_TemperaturSensor)
                                 WEB            FW_Notify      0      4        0     0.00      0
            WEB_192.168.100.21_51796            FW_Notify      1      4        1     0.25      0 HASH(WEB_192.168.100.21_51796); HASH(wz_TemperaturSensor)
            WEB_192.168.100.21_51859            FW_Notify      0      4        0     0.00      0
            WEB_192.168.100.37_55726            FW_Notify      0      4        0     0.00      0
            WEB_192.168.100.37_55727            FW_Notify      1      4        1     0.25      0 HASH(WEB_192.168.100.37_55727); HASH(ke_TemperaturSensor)
            WEB_192.168.100.37_55728            FW_Notify      0      4        0     0.00      0
            WEB_192.168.100.37_55729            FW_Notify      0      4        0     0.00      0
                            WEBphone            FW_Notify      0      4        0     0.00      0
                           WEBtablet            FW_Notify      0      4        0     0.00      0
                         ZE.Activity readingsGroup_Notify      0      4        0     0.00      0
                         ZE.Batterie readingsGroup_Notify      0      4        0     0.00      0
                       ZE.Empfaenger readingsGroup_Notify      0      4        0     0.00      0
                       ZE.MotorError readingsGroup_Notify      0      4        0     0.00      0
                     ZE.WatchCUL_433      watchdog_Notify      0      4        0     0.00      0
                ZE.WatchCUL_433_long      watchdog_Notify      0      4        0     0.00      0
                      ZE.WatchHMLAN1      watchdog_Notify      0      4        0     0.00      0
                 ZE.WatchHMLAN1_long      watchdog_Notify      1      4        1     0.25      0 HASH(ZE.WatchHMLAN1_long); HASH(ku_TemperaturSensor)
               ZE.WatchmyJeeLink_866      watchdog_Notify      0      4        0     0.00      0
          ZE.WatchmyJeeLink_866_long      watchdog_Notify      0      4        0     0.00      0
                          eventTypes    eventTypes_Notify      1      4        1     0.25      0 HASH(eventTypes); HASH(ke_TemperaturSensor)
                   n_FTUI_Thermostat          notify_Exec      1      4        1     0.25      0 HASH(n_FTUI_Thermostat); HASH(ke_TemperaturSensor)
                        n_weatherNow          notify_Exec      0      4        0     0.00      0
                            wc_n_PIR          notify_Exec      1      4        1     0.25      0 HASH(wc_n_PIR); HASH(sz_TemperaturSensor)



Ich habe mal von meinen 7 Thermostaten von 6 Stück das Peering rückgängig gemacht und schaue, ob das Einfluss auf den Fehler hat.

thaliondrambor

#97
[Update]: Fehler ist nach circa 18 Stunden wieder aufgetaucht.

Gleich zum Anfang die gute Nachricht: Die virtuellen Devices arbeiten bereits die ganze Nacht (9 Stunden) fehlerfrei mit den Thermostaten zusammen.

Das Unpeering der 6 Thermostate hat leider nichts gebracht. Dafür habe ich aber durch diesen Versuch trotzdem das ganze zum Laufen gebracht, ich bin mir ziemlich sicher, dass ich das Problem identifiziert habe.

Aber erstmal beim Anfang beginnen.

Ich habe bis auf das Wohnzimmerthermostat alle Thermostate von den virtuellen Devices getrennt (set virtuelles_Device_Channel peerChan 0 thermostat_Weather single unset). Leider hat das nicht zum Erfolg geführt. Das Wohnzimmerthermostat hat für eine Stunde nahezu durchgängig nicht die richtige Temperatur gehabt.
Ich habe weiter nach einer Lösung gesucht und unter anderem das Attribut "hmLanQlen" vom HMLAN von "low" (0) auf "normal" (3) gesetzt. Ich glaube, dass dies nicht die Lösung war, denn das Wohnzimmerthermostat hat weiterhin Fehler produziert. Ich kann es aber auch nicht zu 100% ausschließen, dass dies nicht geholfen hat.
Außerdem habe ich FHEM neugestartet. Dies hatte zur Folge das der Channel vom virtuellen Device seine Eigenschaft als "virtTemp" verloren hat. ("set XXX virtTemp XX führt zu einer Fehlermeldung).

Da dies alles nicht geholfen hat, habe ich die Channel wieder miteinander gepeert (set virtuelles_Device_Channel peerChan 0 thermostat_Weather single). Und siehe da, die 6 zuvor getrennten Thermostate haben einwandfrei die Temperatur aus dem virtuellen Device übernommen. Nur das Wohnzimmerthermostat war weiterhin fehlerhaft.
Also habe ich nach einer Beobachtungszeit das gleiche für das Wohnzimmer gemacht. Peering aufheben, FHEM neustarten (kein virtTemp mehr), wieder gepeer und schon lief auch das Wohnzimmerthermostat einwandfrei. Und sie tun es auch weiterhin.

Meine Schlussfolgerungen:

Ich habe also über die Ursache nachgedacht. Der Zeitraum zur Kommunikation wird ja vom Modul berechnet, aber irgendwoher muss das Modul ja wissen, was es berechnen muss. Dies muss ihm irgendwie einmalig mitgeteilt werden. Ich gehe davon aus, dass das beim "ersten Kontakt" also beim Peering stattfindet.
Nun läuft nach einer gewissen Zeit, aber die Uhrzeit zwischen FHEM und Thermostat auseinander, da Uhren nie hundertprozentig synchron laufen. Deswegen laufen die Thermostate eine Weile gut, aber irgendwann treten diese Fehler auf.

Wie kann dem Abhilfe geschaffen werden? Eine regelmäßige Synchronisation der Uhrzeit sollte helfen. Diese hatte ich eh schon vor ein paar Wochen eingerichtet, da das Thermostat im Badezimmer morgens auch immer als Uhr genutzt wird. Da ich dort ein paar Minuten Abweichung hatte, lasse ich mittels at um Mitternacht die Uhrzeit der Thermostate auf die Uhrzeit von FHEM setzen (set thermostat_Clima sysTime).

Wie macht dies denn eigentlich Homematic selbst? Es ist eher unwahrscheinlich, dass die Uhrzeit von automatisierten Geräten von Hand gesetzt werden müssen. Also kurz gegoogelt und auch die CCUs von Homematic synchronisieren die Uhrzeit um Mitternacht.

Also nochmal zusammen gefasst.
Problem beheben durch Aufheben des Peerings. Mittels HMINfO überprüfen (configCheck), ob das Peering auch wirklich in beiden Channels gelöscht wurde. Zwischendrin Neustart (eventuell nicht nötig). Peering der Channels wiederherstellen.

Damit das Problem nicht erneut auftritt, die Uhrzeit regelmäßig synchronisieren. (Um den Fehler beim Uhrzeit setzen nicht selber zu erzeugen, sollte die Uhrzeit beim Peering schon synchron sein.)

Langfristig wäre es sinnvoll, wenn das CUL_HM-Modul das synchroniseren der Uhrzeit übernimmt, damit es die selbe Funktionalität wie die CCU hat.
Es wäre sogar zu überlegen, ob nicht FHEM selber alle Devices (nicht nur HM), die die Möglichkeit haben die Uhr zu stellen, diese regelmäßig synchronisieren sollten.


Es wäre schön, wenn andere dies auch mal probieren und bestätigen könnten. Wenn nicht, habe ich all das umsonst geschrieben^^

frank

ZitatLangfristig wäre es sinnvoll, wenn das CUL_HM-Modul das synchroniseren der Uhrzeit übernimmt, damit es die selbe Funktionalität wie die CCU hat.
das geschieht doch schon jeden tag.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

thaliondrambor

Zitat von: frank am 15 Januar 2016, 11:30:02
das geschieht doch schon jeden tag.

Okay. Ich kann nur sagen, das mein Thermostat nach einiger Zeit eine Abweichung von zwei Minuten hatte. Im Moment läuft immer noch alles fehlerfrei. Ich werde es weiter beobachten. Es war nur eine Vermutung, dass es an der Zeit liegt.

frank

ZitatIch kann nur sagen, das mein Thermostat nach einiger Zeit eine Abweichung von zwei Minuten hatte.
du hast hmlan?
vergleiche seine zeit mit fhemzeit.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

thaliondrambor

Der Fehler ist wieder aufgetaucht. :-(
Erst hat das Wohnzimmerthermostat gegen 16 Uhr wieder angefangen und etwas später auch andere. Mittlerweile kommen die Abweichungen wieder "öfter".

Wie kann ich die aktuelle Zeit vom HMLAN auslesen? In HMLAN1_TIME springt die Zeit immer (ca. alle 20-30 Sekunden. keepAlive?). Diese stimmt zwar ungefähr überein, aber ein überprüfen ist so recht schwierig.

frank

ZitatMittlerweile kommen die Abweichungen wieder "öfter".
wenn du jetzt ein set sysTime machst, wird es dann wieder besser? eventuell braucht es etwas zeit dafür.

ZitatWie kann ich die aktuelle Zeit vom HMLAN auslesen?
am einfachsten eventuell, indem du die keepalive logst "attr hmlan logIDs sys". kann man wohl mittlerweile auch im eventmonitor sehen. wenn dann ein keepalive kommt, schaust du in den internals des hmlan nach. dann solltest du die differenz vom timestamp des logs und hmlan_time bekommen können.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Merlin


JoeALLb

ok,  mir wurde zu kalt...  hab jetzt auf einen hm- thermostat gewechselt,  und gut ist....

Viel Glück euch....
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270