Hallo zusammen,
ich habe folgendes Problem mit meinen HomeMatic-Funkheizkörperthermostaten am Raspberry Pi 3 mit Homematic-Funkmodul:
Die Uhrzeit an den Thermostaten verstellt sich andauernd und läuft ca. 3 Stunden vor. Ich habe die Uhrzeit im RPi3 geprüft, die ist richtig. Die Zeiten in den Logs in FHEM sind auch richtig.
Hat noch jemand eine Idee, was ich noch versuchen könnte?
Vielen Dank vorab!
Fargo
Betrifft das alle Thermostate?
Verwendest Du systime für die Thermostate?
Welchen Typ Thermostate hast Du?
Was heisst verstellt sich genauer (kontinuierlich / auf einmal / über welchen Zeitraum)?
Hi viegener,
nein, systime kenne ich nicht. Es sind die HomeMatic 105155 Funk-Stellantriebe und die Zeit verstellt sich soweit ich bisher bemerkt habe auf einmal um ca. 3 Stunden. Ich habe die Konfiguration jetzt erst ca. 4 Wochen und es ist in der letzten Woche schon zwei Mal passiert.
Grüße
Fargo
1) Also zur Sicherheit:
Du hast nicht irgendwo ein at so in der Form:
define TimeUpdate at *05:05 set BZ.Klima sysTime
m.a.W. gibt es regelmässige Operationen die auf den Thermostaten durch geführt werden?
2) Findet sich im log etwas zu den Thermostaten um die Zeit zu der sich das verstellt?
3) Sind Uhrzeit und Zeitzone (!) auf dem Rechner korrekt?
einmal am tag werden die thermostate automatisch von fhem synchronisiert. wenn die thermostate also eine falsche zeit anzeigen, müsste also dein pi während der synchronisation eine falsche zeit haben.
nach einem reboot hat der pi zb erst eine "falsche" zeit, bis er sich bei einem ntp server synchronisiert. hast du mal im syslog vom pi geschaut?
Hallo zusammen,
ich habe seit vorgestern in die fhem.cfg in Anlehnung an diesen Wiki-Eintrag hier (https://wiki.fhem.de/wiki/FHT:_Datum_und_Zeit_von_fhem_setzen_lassen) eine Ergänzung eingetragen, die aber leider auch nichts gebracht hat:
define fht_dateupdate at *15:00:01 { fhem("set TYPE=FHT date") } }
define fht_timeupdate at *16:00:01 { fhem("set TYPE=FHT time") } }
Da im Wiki leider nicht mal erklärt ist, wo man das eintragen muss, war das einfach nur meine persönliche Anfänger-Vermutung :P
Da steht aber auch nichts mit systime. Ansonsten habe ich auch keine weiteren Eingriffe gemacht.
Die Zeitzone ist richtig, das hatte ich auch alles konfiguriert. Es wird auch immer die richtige Zeit angezeigt, wenn ich sie abfrage.
Ich habe gerade noch mal alles durchgeklickt, mir ist was aufgefallen: bei den Thermostaten steht fast überalle "CMDs_pending", das klingt danach, als wäre irgendwas mit der Verbindung nicht in Ordnung?
Grüße
Fargo
Hast du noch ein Testsystem mit einem anderen IODEV? Ich habe letztes Jahr ein ähnliches Problem gehabt und konnte es mir zunächst nicht sofort erklären. Ich nutze viele IODevs für Homematic (3 HMLAN, 2 HMUSB und einen HMUART). Der HMUART war damals noch Teil eines Testsystems mit einer anderen HMID und die Zeit auf dem entsprechenden Pi war falsch. Das ist mir natürlich als letztes eingefallen, weil ich nie daran gedacht hätte, dass einige der Thermostate sich ausgerechnet von diesem HMUART die Zeit holen. So war es aber offenbar, weil die falsche Zeit identisch mit der im Test-Pi war. Nachdem die Zeit im Testsystem richtig war, hatte ich nie wieder ein Problem. Ich würde auch nicht ganz ausschließen, dass irgendein Test-CUL in einem Testsystem ein Problem machen könnte.
Nein, ich habe keine anderen Systeme... daran kann es eigentlich nicht liegen.
Ich habe die Uhrzeiten manuell wieder richtig gestellt und nun, einige Stunden später, sind sie wieder um gute 3 Stunden verstellt. Es hat auch kein Neustart des RPI oder etwas anderem stattgefunden.
Ich bin echt ratlos...
Also verteilt doch dein FHEM-Server die falsche Uhrzeit.
Es wäre deshalb wichtig herauszufinden, ob es nicht dich irgendwelche unerklärlichen Abweichungen auf dem pi ergibt.
Zeitzone?
Wie synchronisierst due die raspberry uhr
Was sagt er auf shell-Ebene?
Hi Fargo!
Zitat von: Fargo am 17 Dezember 2016, 13:20:32
Hallo zusammen,
ich habe seit vorgestern in die fhem.cfg in Anlehnung an diesen Wiki-Eintrag hier (https://wiki.fhem.de/wiki/FHT:_Datum_und_Zeit_von_fhem_setzen_lassen) eine Ergänzung eingetragen, die aber leider auch nichts gebracht hat:
define fht_dateupdate at *15:00:01 { fhem("set TYPE=FHT date") } }
define fht_timeupdate at *16:00:01 { fhem("set TYPE=FHT time") } }
Die Definition bezieht sich mit
TYPE=FHT doch auf FHT (FS20)-Geräte und ist also bei deiner Konfiguration überflüssig! Du setzt doch HM-Gräte ein.
Um dem jetzt mal auf den Grund zu gehen, kannst Du bitte mal auf dem Pi:
date
eingeben und uns mitteilen (bitte incl. echter Uhrzeit)
Hi zusammen,
tja, blöde nichts erklärende Code-Schnipsel... ich als Anfänger dachte, es würde Funkheizthermostat bedeuten :-/
Dann nehme ich das mal wieder raus.
Die momentane Date-Anzeige sieht so aus:
Mon 19 Dec 22:58:59 CET 2016
Wie kann ich denn die Uhrzeit in FHEM abfragen?
Edit: Habe es selbst herausgefunden. Mit { localtime() } bekomme ich die Uhrzeit in FHEM, die allerdings mit der des Pi übereinstimmt.
Wobei .. nach der Uhrzeit des Beitrages dürfte es stimmen .. und auf CET ist es auch gestellt.
P.S. Du hast doch bestimmt einen ntp-laufen, was sagt denn ein
ntpq -p
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
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.
Ja ok, aber ich denke mal, es war mit meiner Angabe eindeutig, dass es sich in dem Moment um die richtige Zeit handelte...
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
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
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
http://www.meintechblog.de/2015/06/ungenaue-fhem-systemzeit-berichtigen-und-uhrzeit-angelernter-geraete-updaten/
STRG+F "sysTime"
Vielleicht hilft das..
Grüße
Stephan
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
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
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
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.
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
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.
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 ...
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
Hi Fargo,
das mit dem Linux Wissen sehe ich anders ;-) Ich selbst hab schon ein gutes Dutzend Anläufe unternommen, Windows durch Linux zu ersetzen. Und bin nun doch wieder bei Windows, damit bin ich aufgewachsen, damit komm ich einfach klar. :-)
FHEM geht, mal von der Einrichtung abgesehen, aber da gibt es ja wirklich Schritt für Schritt Anleitungen, erstmal OHNE Linux Kenntnisse. Später brauchste dann evtl mal Perl, aber auch das lässt sich mit/durch FHEM lernen.
Ich würde die Flinte nicht ins Korn werfen, schau mal was deine anderen Geräte so machen, den list-Befehl kennst du ja nun, falls die alle ein Problem haben:
protCmdPend 73 CMDs_pending
Dann würde ich hier mal Pause machen und die Suche bemühen (pairing von HM CC RT DN) oder ein neues Thema aufmachen wenn du auch nach der ganzen Leserei nicht weiter kommst um eben zuerst dieses Problem zu beheben.
Grüße
Achim
Hi Achim,
ich schau mal, ob ich während der Feiertage vielleicht mal wieder den Nerv habe und es weiter versuche ;)
Ich habe unter "Everything" nachgeschaut, da stehen 3 von 4 Thermostaten auf CMDs_pending. Müsste die gleiche Angabe sein wie bei list, nehme ich mal an.
Grüße
Fargo
Meine Frage bezüglich "Wissen" war eigentlich anders gedacht: Wenn ich weiß, das jemand "kein Wissen hat", Antworte ich einfach anders ;o)
Das ist gut zu wissen, für mich also bitte super ausführlich, falls du noch Lust hast ;)
Wünsche aber erst mal ein frohes Fest
Fargo
Zitat von: Fargo am 23 Dezember 2016, 20:53:20
Hi Achim,
ich schau mal, ob ich während der Feiertage vielleicht mal wieder den Nerv habe und es weiter versuche ;)
Ich habe unter "Everything" nachgeschaut, da stehen 3 von 4 Thermostaten auf CMDs_pending. Müsste die gleiche Angabe sein wie bei list, nehme ich mal an.
Grüße
Fargo
Dann erst einmal die cmds pending wegbekommen...
...sollte auch durch (ab)warten gehen...
Dann mal die lists der Thermostate posten, dann kann man sehen was los ist, noch fehlt bzw. nicht i.O. ist...
Und dann in Ruhe weiter machen...
Solange das mit der Kommunikation zu den Thermostaten noch nicht flutscht braucht man wg. evtl. falscher Uhrzeit noch nicht schauen (wurde ja bereits ausgeführt)...
Bei den Thermostaten hilft auch ab und an die "Boost-Taste" zu drücken (wie beim Anlernen)...
Aber nix sonst (in fhem) machen, erst mal die anstehenden cmds abarbeiten (lassen)...
Frosch Fescht! Joachim