Seit einigen Tagen zeigen meine HM-TC-IT-WM-W-EU eine völlig falsche Uhrzeit an. Mit set sysTime aus FHEM heraus konnte ich dies korrigieren- allerdings haben die Teile nach kurzer Zeit wieder eine falsche Zeit.
Irgendeine Idee wo man da ansetzen könnte - das lief über Monate problemlos!
IOdev ist eine VCCU mit einem HM-LAN-CFG und einen LAN-Gateway
Hi,
da gab es schon mal eine ausgiebige Diskussion, hast Du die gefunden?
https://forum.fhem.de/index.php/topic,28088.msg213462.html#msg213462
Ansonsten habe ich leider keine Idee für Dich.
Gruß Otto
Den HMLAN hab ich mal rosetten - keine Änderung. Nach einiger Zeit gehen alle Thermostate falsch ... statt 21:42 jetzt 02:16, also auch kein Zeitzonenproblem
Den in deinem Thread verlinkten time-request konnte ich aber in keinem Log finden.
Hallo zusammen,
der letzte Eintrag in diesem Thread ist zwar schon etwas her. Aber trotzdem die Frage gibt es hierzu eine Lösung?
Seit der letzten Zeitumstellung haben ich nämlich genau das gleich Problem wie roedert. Jetzt durchfortse ich schon seit
mehr als einer Woche das Forum, quäle Google und haben mein FHEM komplett auf den Kopf gestellt - leider ohne Erfolg.
Mein Setup:
Wohnzimmer: 1 x Wandthermostat (HM-TC-IT-WM-W-EU), 3 x Heizkörperthermostat (HM-CC-RT-DN) und 2 x Fenstersensor (HM-Sec-SCo)
Büro: 1 x Wandthermostat (HM-TC-IT-WM-W-EU), 2 x Heizkörperthermostat (HM-CC-RT-DN) und 2 x Fenstersensor (HM-Sec-SCo)
Studio: 1 x Wandthermostat (HM-TC-IT-WM-W-EU), 2 x Heizkörperthermostat (HM-CC-RT-DN) und 2 x Fenstersensor (HM-Sec-SCo)
Heizkörperthermostate (HT) und Fenstersensoren (FS) sind jeweils direkt mit den Wandthermostaten (WT) gepeert.
Die Temperaturregelung erfolgt jeweils lokal durch den WT auf welchem ein eigenes Wochenprofil läuft.
Über FHEM aktiviere/deaktiviere ich den Auto Mode oder setze nach bestimmten Bedingungen manuell eine feste Temperatur auf dem WT, der diese dann an die gepeerten HT durchreicht.
Wie bei roedert hatte das auch über Jahre perfekt funktioniert - bis zur letzten Zeitumstellung (kurz davor habe ich allerdings auch seit längerem FHEM mal wieder upgedatet).
Was habe ich bereits versucht/geprüft:
- Die Firmware auf den Ventilen und den Thermostaten ist auf dem neuesten Stand
- Raspberry Pi und FHEM sind auf dem neuesten Stand und die Systemzeit ist korrekt
- Alle HMLAN und HMUSB wurden bereits stromlos gemacht, neu gestartet und zeigen die korrekte Zeit an
- Alle Devices erhalten regelässig um 4:00 Uhr via "sysTime" die aktuelle Zeit "gepushed". Wie bei roedert hilft aber nur temporär - nach kurzer Zeit haben wieder alle Geräte die gleiche willkürliche Zeit. Ein entsprechendes "time-request" kann auch ich im Logfile nicht finden.
- Das Attribut "daylightSaveTime" steht bei allen Geräten auf OFF
- Aufgrund der Größe der Zeitabweichungen schließe ich ein Zeitzonenproblem aus
Da alle HM-Geräte synchron die falsche Zeit haben und die Hardware (Raspi, HMLAN usw.) die korrekte Zeit anzeigen gehe ich davon aus, dass das Problem irgendwie von FHEM verursacht wird. nur wo und wann?
Hat wirklich keiner eine Idee wo die wirre Zeit herkommt? Mein WAF-Bonus ist zwischenzeitlich verbraucht und frierende Frauen will wirklich keiner ertragen ;-)
Ich hoffe auf Eure Unterstützung....
zeig mal ein list vom hmlan.
Moin frank,
danke für deine schnelle Reaktion !!!
Habe hier schlechten Empfang aufgrund vieler RF-Quellen in der Nachbarschaft und daher mehrere eigene Gateways im Haus verteilt:
HMLAN 1.OG
Internals:
DEF 192.168.178.45:1000
DeviceName 192.168.178.45:1000
FD 5
HMLAN1_MSGCNT 13878
HMLAN1_TIME 2018-11-10 09:21:30
IFmodel LAN
NAME HMLAN1
NR 42
NTFY_ORDER 50-HMLAN1
PARTIAL
RAWMSG EF12341,0000,05259087,FF,FFBA,79A001F123413E9F63010E
RSSI -70
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 40
msgKeepAlive dlyMax:1.283 bufferMin:3
msgLoadCurrent 0
msgLoadHistoryAbs 5min steps: 0/0/0/0/0/0/0/0/0/0/0/0
msgParseDly min:-19 max:2106 last:9 cnt:13626
owner F12341
owner_CCU vccu
uptime 000 23:59:07.911
READINGS:
2018-11-09 09:04:27 D-HMIdAssigned F12341
2018-11-09 09:04:27 D-HMIdOriginal 23A79E
2018-11-09 09:04:27 D-firmware 0.961
2018-11-09 09:04:27 D-serialNr KEQ0852796
2018-11-09 09:23:19 Xmit-Events ok:2 disconnected:6 init:2
2018-11-09 09:23:19 cond ok
2018-11-10 09:21:14 loadLvl low
2017-10-22 16:34:11 prot_Warning-HighLoad last
2018-11-09 09:23:19 prot_disconnected last
2018-11-09 09:23:19 prot_init last
2018-11-09 09:23:19 prot_keepAlive last
2018-11-09 09:23:19 prot_ok last
2017-04-05 04:19:39 prot_timeout last
2018-11-09 09:23:19 state opened
helper:
assIdCnt 40
assIdRep 40
info 03C1,KEQ0852796,23A79E,F12341
setTime 47053
cnd:
0 2
253 6
255 2
dly:
cnt 13626
lst 9
max 2106
min -19
ids:
1AF1CB:
cfg +1AF1CB,00,00,00
name rollo_DACH
1AF2A9:
cfg +1AF2A9,00,00,00
chn 02
flg 0
msg
name rollo_TERRASSE
to 1541829602.03081
20599E:
cfg +20599E,00,00,00
name rollo_TERRASSE_BUTTON
205C6F:
cfg +205C6F,00,00,00
name rollo_DACH_BUTTON
206D08:
cfg +206D08,00,00,00
flg 0
msg
name OLIVE
to 1541751169.17142
20DB43:
cfg +20DB43,00,00,00
chn 01
flg 0
msg
name GARTEN
to 1541750844.80352
20E4B5:
cfg +20E4B5,00,00,00
chn 01
flg 0
msg
name BAMBUS
to 1541750889.93723
20E4BF:
cfg +20E4BF,00,00,00
flg 0
msg
name PALME
to 1541751315.74349
22A1E2:
cfg +22A1E2,00,00,00
chn 02
flg 0
msg
name eg_HEIZUNG_ez
to 1541818858.73856
22AB96:
cfg +22AB96,00,00,00
chn 02
flg 0
msg
name eg_HEIZUNG_ku
to 1541818825.30874
22DCC0:
cfg +22DCC0,00,00,00
chn 02
flg 0
msg
name eg_HEIZUNG_wz
to 1541818856.04787
262328:
cfg +262328,00,00,00
chn 02
flg 0
msg
name eg_HEIZUNG_thermostat
to 1541818802.53949
27BAB3:
cfg +27BAB3,00,00,00
chn 01
flg 0
msg
name OLEANDER
to 1541786567.3594
299E28:
cfg +299E28,00,00,00
name rauchmelder_TREPPENHAUS_DG
299E91:
cfg +299E91,00,00,00
name rauchmelder_KELLER
299F75:
cfg +299F75,00,00,00
name rauchmelder_TREPPENHAUS_OG
2ED0C9:
cfg +2ED0C9,00,00,00
chn 01
flg 0
msg
name eg_FENSTER_wz
to 1541787303.87093
30A681:
cfg +30A681,00,00,00
chn 01
flg 0
msg
name eg_FENSTER_ku
to 1541756775.35649
30C721:
cfg +30C721,00,00,00
name rauchmelder_BUERO
3BB13E:
cfg +3BB13E,00,00,00
chn 01
flg 0
msg
name garten_SWA
to 1541750674.47093
3E6C88:
cfg +3E6C88,00,00,00
chn 04
flg 0
msg
name garten_SWB
to 1541750678.74152
43C4FE:
cfg +43C4FE,00,00,00
chn 01
flg 0
msg
name garten_MOTIONTRACKER
to 1541834351.85888
44ED2A:
cfg +44ED2A,00,00,00
name rauchmelder_SCHLAFZIMMER
4517FB:
cfg +4517FB,00,00,00
name rauchmelder_STUDIO
451F19:
cfg +451F19,00,00,00
name rauchmelder_WOHNZIMMER
4B7C0D:
cfg +4B7C0D,00,00,00
chn 02
flg 0
msg
name garten_SWC
to 1541832812.09572
4FE382:
cfg +4FE382,00,00,00
chn 01
flg 0
msg
name HM_4FE382
to 1541831382.4263
508618:
cfg +508618,00,00,00
chn 02
flg 0
msg
name garten_SWD
to 1541831376.06754
50C69D:
cfg +50C69D,00,00,00
chn 02
flg 0
msg
name dg_HEIZUNG_nord
to 1541818804.09454
50C6D3:
cfg +50C6D3,00,00,00
chn 02
flg 0
msg
name dg_HEIZUNG_sued
to 1541818804.87535
50C709:
cfg +50C709,00,00,00
chn 02
flg 0
msg
name buero_HEIZUNG_rechts
to 1541818818.93129
50C774:
cfg +50C774,00,00,00
chn 02
flg 0
msg
name buero_HEIZUNG_links
to 1541818895.59828
52D547:
cfg +52D547,00,00,00
chn 02
flg 0
msg
name dg_HEIZUNG_wt
to 1541818805.65739
52D57E:
cfg +52D57E,00,00,00
chn 02
flg 0
msg
name buero_HEIZUNG_wt
to 1541818803.31994
52DB94:
cfg +52DB94,00,00,00
name rauchmelder_TREPPENHAUS_EG
5637F6:
cfg +5637F6,00,00,00
name buero_FENSTER_rechts
56381D:
cfg +56381D,00,00,00
chn 01
flg 0
msg
name dg_FENSTER_sued
to 1541833343.79887
56396A:
cfg +56396A,00,00,00
chn 01
flg 0
msg
name buero_FENSTER_links
to 1541755528.34706
563B58:
cfg +563B58,00,00,00
chn 01
flg 0
msg
name dg_FENSTER_nord
to 1541754845.18655
59E794:
cfg +59E794,00,00,00
chn 02
flg 0
msg
name HM_59E794
to 1541829183.27509
k:
BufMin 3
DlyMax 1.283
Next 1541838099.71446
Start 1541838074.71446
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0x1455f40)
q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 0
loadNo 4
scnt 2
ald:
0
0
0
0
0
0
0
0
0
0
0
0
apIDs:
ref:
drft -0.000159980802303724
hmtL 86332435
kTs 0
offL 1541751742283
sysL 1541838074718
Attributes:
group Gateways
hmId F12341
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room SYSTEM
HMLAN EG:
Internals:
DEF 192.168.178.42:1000
DeviceName 192.168.178.42:1000
FD 27
HMLAN2_MSGCNT 13746
HMLAN2_TIME 2018-11-10 09:22:43
IFmodel LAN
NAME HMLAN2
NR 425
NTFY_ORDER 50-HMLAN2
PARTIAL
RAWMSG E52D57E,0000,050FF5F4,FF,FFB7,2F847052D57E00000000D533
RSSI -73
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 0
msgKeepAlive dlyMax:0.204 bufferMin:4
msgLoadCurrent 0
msgLoadHistoryAbs 5min steps: 0/0/0/0/0/0/0/0/0/0/0/0
msgParseDly min:-3233 max:2025 last:46 cnt:13522
owner F12341
owner_CCU vccu
uptime 000 23:35:32.084
READINGS:
2018-11-09 09:04:25 D-HMIdAssigned F12341
2018-11-09 09:04:25 D-HMIdOriginal 322623
2018-11-09 09:04:25 D-firmware 0.964
2018-11-09 09:04:25 D-serialNr LEQ0985710
2018-11-09 09:48:22 Xmit-Events ok:3 disconnected:5 init:3
2018-11-09 09:48:22 cond ok
2018-11-10 09:22:42 loadLvl low
2018-11-09 09:47:18 prot_disconnected last
2018-11-09 09:48:21 prot_init last
2017-10-10 14:58:20 prot_keepAlive last
2018-11-09 09:48:22 prot_ok last
2018-11-09 09:48:21 state opened
helper:
assIdCnt 0
assIdRep 0
info 03C4,LEQ0985710,322623,F12341
setTime 47053
cnd:
0 3
253 5
255 3
dly:
cnt 13522
lst 46
max 2025
min -3233
ids:
27BAB3:
flg 0
k:
BufMin 4
DlyMax 0.204
Next 1541838187.27663
Start 1541838162.27663
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0x13c52e8)
q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 0
loadNo 4
scnt 3
ald:
0
0
0
0
0
0
0
0
0
0
0
0
apIDs:
ref:
drft -0.000280011200448018
hmtL 84931210
kTs 0
offL 1541753231070
sysL 1541838162280
Attributes:
group Gateways
hmId F12341
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room SYSTEM
HMUSB für Funkausleuchtung im Keller:
Internals:
DEF 127.0.0.1:1234
DeviceName 127.0.0.1:1234
FD 21
HMUSB_MSGCNT 13623
HMUSB_TIME 2018-11-10 09:23:21
IFmodel USB
NAME HMUSB
NR 358
NTFY_ORDER 50-HMUSB
PARTIAL
RAWMSG E4D1464,0000,050ECE1E,FF,FFB8,CF865E4D1464000000025A158F9CD8
RSSI -72
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 1
msgKeepAlive dlyMax:0.882 bufferMin:4
msgLoadCurrent 2
msgLoadHistoryAbs 5min steps: 2/2/2/2/2/2/2/2/2/2/2/2
msgParseDly min:-6 max:2101 last:25 cnt:12400
owner F12341
owner_CCU vccu
uptime 000 23:34:25.474
READINGS:
2018-11-09 09:04:25 D-HMIdAssigned F12341
2018-11-09 09:04:25 D-HMIdOriginal 2CC652
2018-11-09 09:04:25 D-firmware 0.967
2018-11-09 09:04:25 D-serialNr LEQ0659299
2018-11-09 09:49:05 Xmit-Events ok:3 disconnected:34 init:32
2018-11-09 09:49:05 cond ok
2018-11-10 09:23:30 loadLvl low
2018-11-09 09:49:04 prot_disconnected last
2018-11-09 09:49:04 prot_init last
2018-09-18 13:08:23 prot_keepAlive last
2018-11-09 09:49:05 prot_ok last
2018-11-09 09:49:04 state opened
helper:
assIdCnt 1
assIdRep 1
info 03C7,LEQ0659299,2CC652,F12341
setTime 47053
cnd:
0 3
253 34
255 32
dly:
cnt 12400
lst 25
max 2101
min -6
ids:
27BAB3:
flg 0
3E9F63:
cfg +3E9F63,00,00,00
chn 01
flg 0
msg
name HM_3E9F63
to 1541838106.57747
k:
BufMin 4
DlyMax 0.882
Next 1541838235.68725
Start 1541838210.68725
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0x13c5000)
q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 2
loadNo 4
scnt 8
ald:
2
2
2
2
2
2
2
2
2
2
2
2
apIDs:
ref:
drft 1.33319112627986e-05
hmtL 84865474
kTs 0
offL 1541753345225
sysL 1541838185697
Attributes:
group Gateways
hmId F12341
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room SYSTEM
Hast Du eine VCCU konfiguriert? Wenn ja bitte ein list.
CoolTux war schneller ;-)
... dachte gerade noch dass es Sinn macht auch das vccu list zu posten ;-)
Nicht wundern den HMUART haben ich gerade deaktiviert da er auf einen anderen Raspi umzieht.
Internals:
DEF F12341
HMLAN1_MSGCNT 1969
HMLAN1_RAWMSG E1EC556,0000,053581F3,FF,FF9C,9FA6101EC5561E9FEE0601B500
HMLAN1_RSSI -100
HMLAN1_TIME 2018-11-10 09:38:54
HMLAN2_MSGCNT 2274
HMLAN2_RAWMSG EF12341,0000,051E272B,FF,FFBF,208002F123413BB13E00
HMLAN2_RSSI -65
HMLAN2_TIME 2018-11-10 09:38:13
HMUSB_MSGCNT 1804
HMUSB_RAWMSG EF12341,0000,051C68AF,FF,FFB4,208002F123413BB13E00
HMUSB_RSSI -76
HMUSB_TIME 2018-11-10 09:38:13
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 6047
NAME vccu
NOTIFYDEV global
NR 45
NTFY_ORDER 50-vccu
STATE HMLAN1:ok,HMLAN2:ok,HMUSB:ok,HMUART:disconnected,
TYPE CUL_HM
assignedIOs HMLAN1,HMLAN2,HMUART,HMUSB
channel_01 vccu_Btn1
lastMsg No:20 - t:02 s:F12341 d:3BB13E 00
protLastRcv 2018-11-10 09:38:13
protRcv 912 last_at:2018-11-10 09:38:13
protRcvB 28 last_at:2018-11-10 05:19:42
rssi_at_HMLAN1 cnt:590 min:-76 max:-52 avg:-72.15 lst:-70
rssi_at_HMLAN2 cnt:1475 min:-94 max:-55 avg:-67.26 lst:-65
rssi_at_HMUSB cnt:885 min:-79 max:-71 avg:-75.82 lst:-76
READINGS:
2018-11-10 09:38:13 CommandAccepted yes
2018-11-10 09:04:20 state HMLAN1:ok,HMLAN2:ok,HMUSB:ok,HMUART:disconnected,
2018-11-08 22:52:27 unknown_123456 received
2018-11-10 09:35:31 unknown_1E9FEE received
2018-11-10 09:38:54 unknown_1EC556 received
2018-11-10 07:23:39 unknown_23AAF0 received
2018-11-10 07:53:38 unknown_23ADF6 received
2018-11-09 18:01:54 unknown_27F148 received
2018-11-10 09:10:40 unknown_2D6B2B received
2018-11-09 14:42:36 unknown_331D22 received
2018-11-09 23:18:45 unknown_3655A7 received
2018-11-10 09:37:48 unknown_4D1464 received
2018-11-09 08:29:58 unknown_52D013 received
2018-11-10 09:37:18 unknown_5D4A3F received
2018-11-09 19:03:11 unknown_C06595 received
helper:
HM_CMDNR 32
PONtest 1
mId FFF0
regLst ,0
rxType 1
supp_Pair_Rep 0
ack:
expert:
def 1
det 0
raw 0
tpl 0
io:
nextSend 1541839093.19462
prefIO
vccu vccu
ioList:
HMLAN1
HMLAN2
HMUSB
HMUART
mRssi:
mNo 20
io:
HMLAN1:
HMLAN2:
-65
-65
HMUSB:
-76
-76
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_HMLAN1:
avg -72.1576271186441
cnt 590
lst -70
max -52
min -76
at_HMLAN2:
avg -67.2684745762711
cnt 1475
lst -65
max -55
min -94
at_HMUSB:
avg -75.8203389830509
cnt 885
lst -76
max -71
min -79
shadowReg:
Attributes:
IODev HMLAN1
IOList HMLAN1,HMLAN2,HMUSB,HMUART
IOgrp vccu
group Gateways
model CCU-FHEM
room SYSTEM
subType virtual
webCmd virtual:update
die hmlans brauchen schon mal die aktuelle fw 0.965.
hast du vor knapp 24 stunden alle 3 io rebootet?
wie lange hast du die hmlans vom strom getrennt?
poste noch die ausgabe von "get hminfo msgStat"
wenn regelmässig um 4 uhr die zeiten richtig von fhem gesetzt werden, macht es ja keinen sinn, dass kurze zeit später fhem ein weitere zeit "würfelt" und überträgt.
@frank
Zitathast du vor knapp 24 stunden alle 3 io rebootet?
Ja
Zitathast du vor knapp 24 stunden alle 3 io rebootet?
wie lange hast du die hmlans vom strom getrennt?
etwa 1 Minute?
Zitatdie hmlans brauchen schon mal die aktuelle fw 0.965.
Ja - ich weiss :-X
Da ich beim Firmwareupdate schon mal zwei von drei gebricked habe, hatte ich bisher von weiteren FW-Updates Abstand genommen.
Aber vielleicht wird es Zeit das Risiko nochmal einzugehen 8)
Zitatwenn regelmässig um 4 uhr die zeiten richtig von fhem gesetzt werden, macht es ja keinen sinn, dass kurze zeit später fhem ein weitere zeit "würfelt" und überträgt.
Das sehe ich ja genau so!
Das automatische sysTime habe ich ja nur eingebaut weil die HM-Devices sich nicht selbst die richtige Zeit geholt haben und ich auch keinen Log bzgl. "time-request" finden konnte.
Geholfen hat es leider nix. In unregelmäßigen Abständen aber spätenstens nach einigen Studen wird das erzwungene "sysTime" wieder mit einer Fantasie-Zeit überschrieben.
Hier auch die HMinfo msgStat
msg statistics
|---------------------------------------->*
receive | 00| 01| 02| 03| 04| 05| 06| 07| 08| 09| 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23
HMLAN2 :|516|503|509|506|562|520|523|542|531|551|236|593|514|496|490|494|508|571|564|649|535|548|507|511
HMLAN1 :|545|534|553|548|566|556|544|568|568|594|262|577|538|530|513|523|525|565|558|628|550|564|543|543
HMUSB :|499|492|506|499|543|505|504|533|513|535|225|645|508|498|485|488|516|551|536|619|510|529|496|502
send
HMLAN2 :| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0
HMLAN1 :| 6| 6| 6| 6| 28| 7| 13| 27| 10| 11| 3| 27| 13| 6| 7| 8| 13| 33| 28| 42| 9| 18| 6| 9
HMUSB :| 8| 8| 8| 8| 8| 8| 8| 8| 8| 8| 4| 8| 8| 8| 8| 8| 8| 8| 8| 8| 8| 8| 8| 8
receive burst
HMLAN2 :| 0| 0| 0| 0| 5| 1| 0| 0| 2| 3| 2| 8| 0| 0| 0| 0| 0| 4| 2| 5| 0| 2| 0| 1
HMLAN1 :| 0| 0| 0| 0| 0| 1| 0| 0| 2| 3| 2| 6| 0| 0| 0| 0| 0| 1| 2| 4| 0| 2| 0| 1
HMUSB :| 0| 0| 0| 0| 5| 1| 0| 0| 2| 3| 2| 8| 0| 0| 0| 0| 0| 4| 2| 5| 0| 2| 0| 1
send burst
HMLAN2 :| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0
HMLAN1 :| 0| 0| 0| 0| 5| 0| 0| 0| 0| 0| 0| 1| 0| 0| 0| 0| 0| 3| 0| 0| 0| 0| 0| 0
HMUSB :| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0| 0
| 00| 01| 02| 03| 04| 05| 06| 07| 08| 09| 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23
|---------------------------------------->*
receive | Mon| Tue| Wed| Thu| Fri| Sat| Sun|# 24h
HMLAN2 :| 0| 0| 0| 0|8843| 0| 0|#12479
HMLAN1 :| 0| 0| 0| 0|8703| 0| 0|#12995
HMUSB :| 0| 0| 0| 0|8838| 0| 0|#12237
send
HMLAN2 :| 0| 0| 0| 0| 0| 0| 0|# 0
HMLAN1 :| 0| 0| 0| 0| 670| 0| 0|# 342
HMUSB :| 0| 0| 0| 0| 120| 0| 0|# 188
receive burst
HMLAN2 :| 0| 0| 0| 0| 49| 0| 0|# 35
HMLAN1 :| 0| 0| 0| 0| 23| 0| 0|# 24
HMUSB :| 0| 0| 0| 0| 52| 0| 0|# 35
send burst
HMLAN2 :| 0| 0| 0| 0| 0| 0| 0|# 0
HMLAN1 :| 0| 0| 0| 0| 13| 0| 0|# 9
HMUSB :| 0| 0| 0| 0| 0| 0| 0|# 0
| Mon| Tue| Wed| Thu| Fri| Sat| Sun|# 24h
... so jetzt sind auch die HMLAN´s auf dem aktuellen Firmwarestand 0.965
hmlan1 im og hat fast alle devices übernommen, assignedIDsCnt=40. hmlan2=0, hmusb=1.
ist das so gewollt, oder kam das dadurch, dass du alle io rebootet hast und hmlan1 der erste dieser aktion war?
ich verteile stationäre devices mit attr IOgrp über prefered io einigermassen gleichmässig, sofern die rssi dies zulassen.
eventuell mal fhem durchstarten, um wieder "richtig" zu verteilen.
dadurch ist natürlich die wahrscheinlichkeit hoch, dass dieser die zeiten umstellen könnte. er hat auch die älteste fw, die zudem keine infos über die aktuelle load liefern kann.
von gebrickten hmlans habe ich noch nicht wirklich gehört. eventuell meldet er sich nach gescheitertem update mit fw 0.952, angeblich der bootloader. damit funktioniert er dann natürlich nicht mehr, bis nach weiteren versuchen endlich eine funktionierende fw geladen wurde.
edit: dann warten wir mal, was die neue fw bringt.
Zitatdann warten wir mal, was die neue fw bringt.
Leider nichts! Habe direkt nach dem FW-Update ein sysTime an alle Devices geschickt und haben jetzt schon wieder 22:23 als Uhrzeit :-|
Zitatist das so gewollt, oder kam das dadurch, dass du alle io rebootet hast und hmlan1 der erste dieser aktion war?
Das liegt wohl daran dass HMLAN wegen umbauten im EG für einige Tage ausgeschaltet war
Das tritt auch mit Thermostaten auf, die direkt an die CCU angebunden sind. Keine Ahnung, ob das erst seit der Zeitumstellung so ist. An FHEM liegt es jedenfalls nicht, sonst würde es nicht auch bei der CCU auftreten.
@zap
und gibt es in der CCU-Welt einen Weg den Sch... abzustellen?
Bin kurz davor den ganzen HM-Krempel rauszuschmeissen... >:(
@zap
Ganz unschuldig kann FHEM aber auch nicht sein - dann macht FHEM nur das selbe Ding wie die CCU.
Denn von irgendwoher muss die Fantasiezeit ja kommen. 10 Devices überlegen ja nicht spontan sich
auf irgendeine wirre Zeit upzudaten, oder?
Ihr habt mich so verunsichert das ich selber mal eben bei meinen 5 Heizungs und einen Wandthermostat geschaut habe. Alles okay. Zeit stimmt auf die Minute genau bei mir.
Vielleicht ist es ja auch interessant wann Du das letzte mal ein Update gemacht hast.
@CoolTux
Was für ein Update?
- FHEM & Raspi vorgestern das letzte von vielen Malen in den letzten 10 Tagen ;-)
- HMLAN auf anraten von frank vorhin (leider auch ohne Effekt)
- sysTime aktuell mehrmals täglich
Was mich wundert ist dass die HM-Devices laut martinp876 einmal täglich ein "time-request" machen sollten.
Ich sehe aber weder davon was im Log noch von der Geisterzeit
Zitat von: fast-eddy am 10 November 2018, 13:16:09
@CoolTux
Was für ein Update?
- FHEM & Raspi vorgestern das letzte von vielen Malen in den letzten 10 Tagen ;-)
- HMLAN auf anraten von frank vorhin (leider auch ohne Effekt)
- sysTime aktuell mehrmals täglich
Was mich wundert ist dass die HM-Devices laut martinp876 einmal täglich ein "time-request" machen sollten.
Ich sehe aber weder davon was im Log noch von der Geisterzeit
Ja sorry, doof ausgedrückt, hast Recht. Ich meinte das FHEM Update. Aber das passt ja soweit, ist ja sehr frisch.
homematic io's kommunizieren auch selbstständig mit den devices. das kannst durch sniffen der messages sehen:
attr global verbose 1
attr global mseclog 1
attr <hmio> logIDs <name_thermostat>
also bei allen 3 io setzen (nur die io, die nicht senden, zeigen den empfang der selbstständigen msgs an), anschliessend ein "set sysTime" und warten bis die zeit verstellt wird. dann die msgs aus dem log posten.
seltsam finde ich allerdings, dass du scheinbar der einzige im moment bist.
ist dein hmland aktuell?
auf welcher hardware läuft der denn?
allerdings senden bei mir hmlan und hmuart immer nur an die assignten devices diese selbstständigen msgs.
@frank
attr <hmio> logIDs <name_thermostat>
Nur damit ich es richtig verstehe:
Den Eintrag setze ich für jedes IODevice - klar!
Aber welchen WT trage ich ein? Theoretisch kann jedes IO ja mit jedem WT sprechen. Kann ich all WT kommasepariert eintragen?
@frank
Zitatauf welcher hardware läuft der denn?
Der läuft auf dem Pi3 auf dem auch FHEM installiert ist
Zitatist dein hmland aktuell?
...ääähhhm?!
Keine Ahhnung - bin bis eben davon ausgegangen, dass der zusammen mit FHEM sein Update bekommt?
ZitatAber welchen WT trage ich ein? Theoretisch kann jedes IO ja mit jedem WT sprechen. Kann ich all WT kommasepariert eintragen?
ich würde mich erst einmal auf einen konzentrieren, damit das log übersichtlich bleibt.
um hmland musst du dich selber kümmern.
ein WT sollte reichen. Aber ich denke es wird nichts bringen. RTs fragen jeden Nacht nach der Uhrzeit. Bei WT habe ich es jetzt nicht gesehen.
Du kannst die FHEM Zeit mit set ... sysTime manuell übertragen.
das Register DaylightSaveTime im WT beachten!
Zitat von: fast-eddy am 10 November 2018, 12:18:18
@zap
und gibt es in der CCU-Welt einen Weg den Sch... abzustellen?
Bin kurz davor den ganzen HM-Krempel rauszuschmeissen... >:(
Bei mir gingen alle 5 Wandthermostate 3-4 Minuten nach. Das über 2 Tage, seit gestern sind sie wieder in sync. Ich habe nichts gemacht, weder die CCU neu gestartet noch Batterien raus bei den Thermostaten. Spontane Selbstheilung.
@martinp876,
danke für die Hinweise aber wie bereits eingangs beschrieben...
ZitatDu kannst die FHEM Zeit mit set ... sysTime manuell übertragen.
die setze ich die ja schon aus der Not heraus jede Nacht um 4.00 Uhr für alle WT´s.
Hilft nur nichts - nach wenigen Stunden schickt Alice wieder eine Zeit aus dem Wunderland ::)
Zitatdas Register DaylightSaveTime im WT beachten!
die habe ich alle auf Off gesetzt, um das als Fehlerquelle auzuschließen - und eigentlich sollte das ja auch von FHEM kommen wenn ein denn mal ein time-request abgesetzt wird ;)
@zap,
die Hoffnung stirbt zuletzt ;)
Nur ob meine Frau das aussitzen will bezweifle ich 8)
Aber noch hoffe und warte ich...
nun brauche ich das Logfile der messages (sniffen). Du solltet dann einmal ein sync absetzen und mitloggen.
Kurze Beschreibung des Ablaufs was ich nicht sehen kann: wie steht die Uhrzeit, welche Wirkung sysTime hat,... . Wir werden dann seen, wer deinem WT etwas einflüstert
Hallo zusammen
... also hier mal ein kurzer Zwischenstand:
- Seit gestern 13:26 Uhr ist die Zeit stabil und aktuell
- Auch bei den HM-Devices sowohl WT als auch HT tauchen in den Readings plötzlich "time-request" auf. ???
- Im Logfile sehe ich den time-request aber noch immer nicht ?!
Ich freue mich zwar - ärgere mich aber auch darüber dass ich nich sagen kann welche Massnahme jetzt zum Erfolg geführt hat ?!
Es war wohl die von zap angekündigte "Spontanheilung" nur hat es bei mir 10 Tage gedauert und die Abweichungen waren um die 10 Stunden und nicht nur wenige Minuten.
Also was habe ich neben den eingangs erwähnten Maßnahmen (die nichts gebracht haben) getan:
- auf anraten von frank habe ich den HMLANs eine neuere Firmware verpasst (wenn es das war was geholfen hat dann eher der komplette Reboot als die aktuelle FW selbst - den funktioniert hatte es ja vorher schon)
- Einmal die Batterien aus allen HM-Geräten entfernt um ein time-request zu erzwingen
- Das zuvor eingerichtete "at" mit dem ich immer um 4:00 Uhr ein sysTime geschickt hatte wurde wieder deaktiviert
- dann habe ich das Logging der HM Messages zu einem der WT aktiviert
attr global verbose 1
attr global mseclog 1
attr <hmio> logIDs <name_thermostat>
@martinp876
Das Logging der HM-IOs zum WT läuft jetzt seit mehr als einem Tag.
Der Fehler ist zwar nicht mehr aufgetreten aber willst Du das Log trotzdem sehen?
Ich möchte mich lieber noch nicht zu früh freuen und warte noch einige Tage ab bevor ich das Thema abhake.
Aber trotzdem schon mal allen, die mitgedacht und unterstützt haben VIELEN DANK!!!