Uhrzeit bei Thermostaten verstellt sich immer wieder

Begonnen von Fargo, 16 Dezember 2016, 19:30:32

Vorheriges Thema - Nächstes Thema

Fargo

#15
Zitat von: Benni
bitte incl. echter Uhrzeit

Was genau soll das bitte bedeuten??


Ein ntpq -p ergibt Folgendes:


     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp.uni-oldenbu 192.53.103.108   2 u  794 1024  377   49.979    3.063  12.735
+aperture.darksk 194.35.252.7     2 u 137m 1024  200   72.675   -7.405   4.127
2.202.196.104.b 128.138.141.172  2 u   5d 1024    0  136.580   -1.357   0.000
+host-86.3.217.2 130.207.244.240  2 u  589 1024  377  297.200   -2.370  16.100
-fritz.box       195.154.189.15   3 u  938 1024  377   53.289  -13.371  63.251

Benni

Zitat von: Fargo am 20 Dezember 2016, 20:28:58
Was genau soll das bitte bedeuten??

Es ging darum die Systemzeit des Pi mit der echten, realen Uhrzeit "außerhalb des Pi" (bspw. vom Handy, Funkwecker oder der Funkwanduhr o.ä.) zu vergleichen.

FHEM kann natürlich auch keine andere Uhrzeit anzeigen, als die Systemzeit des Pi, deshalb zeigt localtime() immer dasselbe an wie date auf der shell.

Fargo

Ja ok, aber ich denke mal, es war mit meiner Angabe eindeutig, dass es sich in dem Moment um die richtige Zeit handelte...

h-man-kl

Hallo,
ich kann sehr gut verstehen, dass dich das mit der Uhrzeit stört. Leider habe ich keine Lösung für dich, aber da ich das selbe Problem mit meinen FS20 FHTs habe bin ich gespannt ob  hier eine Lösung bei rauskommt, die auch für mich anwendbar ist.
(seit meiner Umstellung von homeputer auf FHEM verstellen sich meine FHTs immer wieder :-( )

Gruß
H-Man
RasPi 3 mit MaxCube für FS20 , HM-Urart, HM-LAN, MiLight, HUE, Lightify, SONOS, Harmony, Unifi, FritzBox 7490... :-)
Ganz nach dem Motto: Normal? Normal is langweilig....

Morgennebel

Hi Fargo,


hast Du evtl. Homematic-Wandthermostate mit Firmware 1.3.2 oder hast Du diese gerade geupgradet?

Ich hatte ähnliche Probleme nach meinen Updates von Firmware 1.1 auf 1.3.2. Die Wandthermostaten waren bei fhem angemeldet, liessen sich steuern, reagierten auf Kommandos, hatten aber eine komplett falsche Uhrzeit.

Das lies sich nur mit systime beheben, ein Gerät nach dem anderen. Mein Ansatz mittels eines DOIFs und FILTER= funktionierte nicht, bzw. führte zu wartenden Kommandos.

Mach doch mal folgendes (und poste die Resultate in CODE-Tags hier):


  • list auf einen fehlerhaften Wandthermostaten
  • systime auf einen fehlerhaften Wandthermostaten, schauen, daß alle Kommandos abgearbeitet sind
  • Erneuter list auf einen fehlerhaften Wandthermostaten
  • date auf dem fhem-Server
  • ls -la /etc/localtime
  • ps auxwww | grep ntp

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Fargo

Hi Morgennebel,

nein, ich habe kein Upgrade an den Thermostaten gemacht. Kann ich irgendwo auslesen, welche Version die haben?

Zu den Auswertungen kann ich nur folgendes vorweisen fürs Erste:

List:

Internals:
   DEF        46EB2C
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     1501
   NAME       az_fht
   NOTIFYDEV  global
   NR         21
   NTFY_ORDER 50-az_fht
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 az_fht_Weather
   channel_02 az_fht_Climate
   channel_03 az_fht_WindowRec
   channel_04 az_fht_Clima
   channel_05 az_fht_ClimaTeam
   channel_06 az_fht_remote
   lastMsg    No:97 - t:10 s:46EB2C d:000000 0AC0FF103A00
   myHmUART_MSGCNT 1501
   myHmUART_RAWMSG 0500001D97861046EB2C0000000AC0FF103A00
   myHmUART_RSSI -29
   myHmUART_TIME 2016-11-29 19:49:10
   protCmdPend 73 CMDs_pending
   protLastRcv 2016-11-29 19:49:10
   protResnd  1 last_at:2016-11-27 16:48:55
   protSnd    258 last_at:2016-11-29 17:32:21
   protState  CMDs_pending
   rssi_at_myHmUART max:-25 cnt:1501 lst:-29 avg:-27.2 min:-35
   Readings:
     2016-11-29 20:01:19   Activity        dead
     2016-11-27 17:26:32   CommandAccepted yes
     2016-11-24 19:30:58   D-firmware      1.4
     2016-11-24 19:30:58   D-serialNr      NEQ0169357
     2016-11-27 16:48:50   PairedTo        0xACDC11
     2016-11-24 19:31:00   R-backOnTime    10 s
     2016-11-24 19:31:00   R-burstRx       on
     2016-11-24 19:31:00   R-cyclicInfoMsg on
     2016-11-24 19:31:00   R-cyclicInfoMsgDis 0
     2016-11-24 19:31:00   R-pairCentral   0xACDC11
     2016-11-27 16:48:50   RegL_00.          01:01 02:01 09:01 0A:AC 0B:DC 0C:11 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2016-11-29 17:32:21   RegL_07.        CA:10 CB:1F CC:20
     2016-11-29 19:49:10   actuator        58
     2016-11-29 19:49:10   battery         ok
     2016-11-29 19:49:10   batteryLevel    3.1
     2016-11-29 19:49:10   desired-temp    24.0
     2016-11-29 19:49:10   measured-temp   25.5
     2016-11-29 19:49:10   motorErr        ok
     2016-12-19 23:10:16   state           CMDs_pending
     2016-11-29 13:18:12   time-request    -
   cmdStack:
     ++A001ACDC1146EB2C00050000000007
     ++A001ACDC1146EB2C0008185932594A5964597E599859B259
     ++A001ACDC1146EB2C0006
     ++A001ACDC1146EB2C00050000000007
     ++A001ACDC1146EB2C0008185932594A5964597E599859B259
     ++A001ACDC1146EB2C0006
     ++A001ACDC1146EB2C00050000000007
     ++A001ACDC1146EB2C00080000145818592E5832594A596459
     ++A001ACDC1146EB2C00087E599859B259
     ++A001ACDC1146EB2C0006
     ++A011ACDC1146EB2C86042C
     ++A011ACDC1146EB2C86042C
     ++A001ACDC1146EB2C00050000000007
     ++A001ACDC1146EB2C00080000145818592E5832594A596459
     ++A001ACDC1146EB2C00087E599859B259
     ++A001ACDC1146EB2C0006
     ++A001ACDC1146EB2C00040000000000
     ++A001ACDC1146EB2C0103
     ++A001ACDC1146EB2C01040000000001
     ++A001ACDC1146EB2C0203
     ++A001ACDC1146EB2C02040000000001
     ++A001ACDC1146EB2C0303
     ++A001ACDC1146EB2C03040000000001
     ++A001ACDC1146EB2C0403
     ++A001ACDC1146EB2C04040000000001
     ++A001ACDC1146EB2C00040000000007
     ++A001ACDC1146EB2C0503
     ++A001ACDC1146EB2C05040000000001
     ++A001ACDC1146EB2C0603
     ++A001ACDC1146EB2C06040000000001
     ++A001ACDC1146EB2C00040000000000
     ++A001ACDC1146EB2C0103
     ++A001ACDC1146EB2C01040000000001
     ++A001ACDC1146EB2C0203
     ++A001ACDC1146EB2C02040000000001
     ++A001ACDC1146EB2C0303
     ++A001ACDC1146EB2C03040000000001
     ++A001ACDC1146EB2C0403
     ++A001ACDC1146EB2C04040000000001
     ++A001ACDC1146EB2C00040000000007
     ++A001ACDC1146EB2C0503
     ++A001ACDC1146EB2C05040000000001
     ++A001ACDC1146EB2C0603
     ++A001ACDC1146EB2C06040000000001
     ++A001ACDC1146EB2C00040000000000
     ++A001ACDC1146EB2C0103
     ++A001ACDC1146EB2C01040000000001
     ++A001ACDC1146EB2C0203
     ++A001ACDC1146EB2C02040000000001
     ++A001ACDC1146EB2C0303
     ++A001ACDC1146EB2C03040000000001
     ++A001ACDC1146EB2C0403
     ++A001ACDC1146EB2C04040000000001
     ++A001ACDC1146EB2C00040000000007
     ++A001ACDC1146EB2C0503
     ++A001ACDC1146EB2C05040000000001
     ++A001ACDC1146EB2C0603
     ++A001ACDC1146EB2C06040000000001
     ++A001ACDC1146EB2C00040000000000
     ++A001ACDC1146EB2C0103
     ++A001ACDC1146EB2C01040000000001
     ++A001ACDC1146EB2C0203
     ++A001ACDC1146EB2C02040000000001
     ++A001ACDC1146EB2C0303
     ++A001ACDC1146EB2C03040000000001
     ++A001ACDC1146EB2C0403
     ++A001ACDC1146EB2C04040000000001
     ++A001ACDC1146EB2C00040000000007
     ++A001ACDC1146EB2C0503
     ++A001ACDC1146EB2C05040000000001
     ++A001ACDC1146EB2C0603
     ++A001ACDC1146EB2C06040000000001
     ++803FACDC1146EB2C02041FEB0938
   Helper:
     HM_CMDNR   151
     PONtest    1
     cSnd       01ACDC1146EB2C04040000000001,01ACDC1146EB2C00040000000007
     mId        0095
     rxType     140
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +46EB2C,02,00,00
       nextSend   1480445350.5359
       prefIO
       rxt        2
       vccu
       p:
         46EB2C
         00
         00
         00
     Mrssi:
       mNo        97
       Io:
         myHmUART   -27
     Prt:
       bErr       0
       sProc      2
       sleeping   1
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       prs        1
     Rssi:
       At_myhmuart:
         avg        -27.2078614257162
         cnt        1501
         lst        -29
         max        -25
         min        -35
     Shregw:
       07         04
     Shadowreg:
       RegL_07.
     Tmpl:
Attributes:
   IODev      myHmUART
   actCycle   000:10
   actStatus  dead
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.4
   model      HM-CC-RT-DN
   room       Arbeitszimmer
   serialNr   NEQ0169357
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit


Ich bekomme den systime-Befehl nicht richtig hin, entweder es fehlen Parameter oder er meckert, systime bräuchte keine Parameter?!

Grüße
Fargo

abc2006

FHEM nightly auf Intel Atom (lubuntu) mit VDSL 50000 ;-)
Nutze zur Zeit OneWire und KNX

Otto123

ZitatmyHmUART_TIME 2016-11-29 19:49:10
   protCmdPend 73 CMDs_pending
   protLastRcv 2016-11-29 19:49:10
   protResnd  1 last_at:2016-11-27 16:48:55
   protSnd    258 last_at:2016-11-29 17:32:21
   protState  CMDs_pending

Wann hast Du das list gemacht? Das sieht nicht so toll aus.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Morgennebel

Um das mal auszuführen:


  • Es ist knapp 3 Wochen her, daß der Thermostat mit fhem geredet hat
  • Es sind 73 Befehle in der Queue, die der Thermostat nicht bearbeitet hat

Entweder ist der Thermostat defekt, Dein CUL oder Dein fhem hat ein massives Problem...

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Otto123

Hi
Naja wobei ich das dann nicht glauben kann :   protResnd  1 last_at:2016-11-27 16:48:55
Ich habe keine Ahnung wann ein Resend angeschoben wird.
Ich dachte eher, entweder ist das List uralt oder das System lebt ein paar Wochen in der Vergangenheit.

Egal: Die Uhrzeit kann so eigentlich am Thermostaten nicht stimmen  :o

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

ZitatEs ist knapp 3 Wochen her, daß der Thermostat mit fhem geredet hat
eigentlich mit niemandem, obwohl er alle 3 min funken sollte. 

zumindestens scheint das display ja noch zu funktionieren, sonst könnte man die falsche zeit ja nicht erkennen. ich würde den burschen mal resetten.
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

Fargo

#26
Hmm, das klingt alles nicht gut... das list ist ganz aktuell gewesen. Vor ca. 3 Wochen habe ich FHEM auf dem Raspi installiert und die Geräte eingebunden. Anschließend alles einmal programmiert und danach sollte es eigentlich einfach nur laufen.

Ist es nicht aber unlogisch, dass sich die Uhrzeit immer verstellt, wenn die Thermostate überhaupt nicht mit dem Raspi kommunizieren würden? Dann müsste die Zeit doch einfach stur (richtig) weiterlaufen, oder nicht?

Was kann ich denn da jetzt machen? Ich habe wie im verlinkten Tutorial jetzt ein

define TimeUpdate at *23:20 set az_fht sysTime eingebaut (oder lautet der Gerätename hier anders?), mal schauen ob das etwas bewirkt.

Ein date bringt übrigens die richtige Uhrzeit
Thu 22 Dec 23:23:10 CET 2016

Ein ls -la /etc/localtime hingegen
-rw-r--r-- 1 root root 2309 Nov 15 23:35 /etc/localtime

Das ps auxwww | grep ntp wirft folgendes aus:
pi         433  0.0  0.1   4276  1844 pts/0    S+   23:26   0:00 grep --color=auto ntp
ntp        719  0.0  0.4   5776  3808 ?        Ss   Nov27   2:29 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 106:111


Was genau bedeutet das alles?

Kann ich evtl. durch einen Neustart bzw. Reset oder irgendwelche Updates etwas erreichen?


Grüße
Ein verzweifelter Fargo

viegener

Ich denke wenn es um FHEM geht, solltest Du das Thema Zeitverstellung erstmal ignorieren.

Ein systime bringt überhaupt nichts, wenn FHEM nicht mit dem Thermostat redet.

Dein list zu dem Device zeigt, dass seit 3 Wochen FHEM wohl gar nicht mit dem Thermostat kommuniziert hat und eigentlich vieles mit ihm zu bereden hätte. Ist das bei anderen Thermostatet auch so?

Ich würde erstmal die grundsätzlichen Probleme lösen bevor Du weiter an irgendwelchen Symptomem herumkuriierst.

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Wernieman

Und noch ein paar Hinweise:

a)
ls -la /etc/localtime
Du fragst hier nach, wann diese Datei erstellt wurde, das hat nichts mit der Systemzeit zu tuhen. Das in dieser Datei die Aktuelle Zeitzohne stehen soll, ist ein anderes Thema. Besser währe also eher, Dir den DateiINHALT anzuzeigen:
cat /etc/localtime

b)
ps aux | grep ntp
Du fragst hier nur, ob ein Prozess ntp existiert. Aber wichtig währe auch, was denn dieser Prozess, der Deine Systemzeit mit Zeitservern abgleicht, denn selber sagt:
ntpq -p
Dort siehst Du, mit welchen Servern Dein Server "redet" und welchen er (aktuell) vertraut

Siehe Dein Beitrag vom 20 Dezember 2016, 20:28:58
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp.uni-oldenbu 192.53.103.108   2 u  794 1024  377   49.979    3.063  12.735
+aperture.darksk 194.35.252.7     2 u 137m 1024  200   72.675   -7.405   4.127
2.202.196.104.b 128.138.141.172  2 u   5d 1024    0  136.580   -1.357   0.000
+host-86.3.217.2 130.207.244.240  2 u  589 1024  377  297.200   -2.370  16.100
-fritz.box       195.154.189.15   3 u  938 1024  377   53.289  -13.371  63.251


Dein Server nimmt aktuell die Zeit von der uni-oldenburg (*), würde aber auch "aperture.darksk" oder "host-86.3.217.2" nehmen (+). Deine Fritz.Box dagegen ist ihm zu ungenau (-), da sie selber zu weit von einem "echten" Zeitserver weg ist (st 3). Mehr Infos bitte im Netz suchen ... gibt sehr viele Informationen dazu!

BTW:
Verstehe mich jetzt bitte nicht falsch, aber wie viel Erfahrung im System (Linux) Umfeld hast Du?

Ansonsten kann ich mich meinem Vorredner nur anschließen, prüfe bitte die Kommunikation zwischen Deinem System und den Devices. Wenn die nicht miteinander "Kommunizieren" kann vieles Passieren ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Fargo

Hi,

danke mal wieder für die Erklärungen. Man tritt mir definitiv nicht zu nahe, wenn man annimmt, dass ich keine Linux-Erfahrung habe. Ich habe mich vorher noch nie damit beschäftigt, darum frage ich auch so blöd.

Ich merke mittlerweile, dass FHEM leider nur was für Linux-Freaks ist, da scheinbar jedes Tutorial die (nicht) selbstverständlichen Linux-Hintergrundinfos weglässt. So macht das alles leider auch keinen Spaß, sich überhaupt reinzuarbeiten, da man nie weiß, ob man nach generellen Linux-Infos oder nach FHEM-Befehlen suchen muss. Ich habe nämlich immer noch keinen blassen Schimmer, wo ich denn nun ansetzen soll...

Zum Glück habe ich bisher ja nur die Thermostate im Haus, die man auch so (umständlich) programmieren kann.

Grüße
Fargo