Langzeitstabilität HM Konfiguration?

Begonnen von reibuehl, 13 Februar 2022, 11:44:17

Vorheriges Thema - Nächstes Thema

reibuehl

Hallo,

ich habe vor etwa 6-8 Monaten alle "Beanstandungen" des hminfo ConfigChecks behoben. Seither habe ich außer den notwendigen Batteriewechseln keine Veränderungen an der Konfiguration meiner HomeMatic Komponenten vorgenommen. Trotzdem zeigt mir der Config Check inzwischen wieder >15 Beanstandungen an. Von missing register list über peer not verified bis trigger sent to unpeered device ist alles dabei. Es sind auch nicht nur einzelne Device Typen betroffen. UP-Schalter, Wandthermostat, Fenstersensor, mit AC Anschluss, mit Batterie, alles bunt gemischt.

Ist das normal?

Gruß,
Reiner
Reiner.

Gernott

Solange alles funktioniert, würde ich mir deswegen keine grauen Haare wachsen lassen. Die meisten Probleme kommen bei mir daher, daß FHEM die Information z.B. über Register verloren hat. Deswegen funktioniert aber alles weiter.

Pfriemler

Die (ärgerliche) Frage ist ja immer, warum FHEM Daten verloren hat.
Langzeitstabil ist die Funktionalität schon.
Wartungsfrei ist sie leider seit langem nicht.
Der perfekte GAU tritt ein, wenn ein Amok laufendes Modul etwa bei einem Update einen Neustart nahelegt und das fhem.save dabei komplett zerstört wird (weil es zuvor nicht vollständig geladen worden war). Damit sind auch alle gespeicherten states und Registerlisten erst einmal hinüber. Wenn man einmal einen halbwegs brauchbaren Registerstand erreicht hat, sollte man ihn dringend in einer Datei ablegen und diese sichern.
Darüberhinaus habe ich die Beobachtung gemacht, dass CUL_HM sehr allergisch auf nicht vorhandene Geräte reagiert und diese mit einer geradezu unverfrorenen Penetranz anzufunken versucht, solange man autoReadReg nicht bändigt - was ja normalerweise bei erreichbaren und antwortenden Geräten eher sinnvoll ist, weil die Register so aktuell gehalten werden, nicht aber bei Geräten, die weder wakeup noch lazyConfig unterstützen. Hier wird der ahnungslose Benutzer ebenfalls völlig im Regen stehen gelassen...

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Otto123

Ich meine die CUL_HM Versionen von vorigem Jahr Mai oder so, haben genau diese Symptome verursacht. Beim Start von FHEM wurden liebevoll alle Register in die Tonne gekloppt, die Batteriegeräte hatten das Nachsehen. Ich habe damals ständig restore machen müssen, weil ich keine Lust hatte immer die Tasten zu drücken.

Also unbedingt jetzt aktualisieren!
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

#4
jedes getconfig löscht zunächst die registerlisten.
ist es anschliessend nicht erfolgreich oder wird mit clear msgEvents abgebrochen, meckert configCheck.

edit:
HMinfoTools.js installieren und "attr sumERROR" wie beschrieben ergänzen.
dann sieht man rechtzeitig probleme.
"attr autoReadReg 5_missing" repariert vieles automatisch.
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