Kritisch: Umgewolltes Schalten der keyMatic nach Neustart

Begonnen von yawp, 11 Juli 2020, 11:42:45

Vorheriges Thema - Nächstes Thema

yawp

Hallo,

nach dem letzten Update der 10_CUL_HM.pm vom 07.07.2020 werden nach einem Neustart fast alle keyMatic automatisch angesteuert.
Als Folge davon wurde u.a. die Haustür aufgeschlossen und stand über die Nacht offen.

Desweiteren sind von der automatischen Ansteuerung auch einige Lampen betroffen.

Der Fehler ist behoben mit dem Wiedereinpielen der alten Version der 10_CUL_HM.pm vom 06.07.2020.

Daraufhin habe ich das Update der 10_CUL_HM.pm bis auf weiteres ausgeschlossen.

Müssen mit der neusten Version der 10_CUL_HM.pm jetzt irgendwelche Parameter gesetzt werden, damit dieses automatische Ansteuern nach einem Neustart unterbunden wird?

Viele Grüße
Marko
FHEM 5.8 auf Raspberry Pi 2, CUL_HM

amenomade

Zitat von: yawp am 11 Juli 2020, 11:42:45


Müssen mit der neusten Version der 10_CUL_HM.pm jetzt irgendwelche Parameter gesetzt werden, damit dieses automatische Ansteuern nach einem Neustart unterbunden wird?

Zuerst prüfen, dass deine notify/DOIFs/usw, die evtl. die Haustür steuern, im Sinn von triggernden Events selektiv genug sind.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Pfriemler

Aktuell ist V 22377 vom 5.7.20 aktuell. Ggü meiner im Einsatz befindlichen 22237 kann ich nichts relevantes erkennen ...? Oder hat martin eine frischere Version so schnell zurückgezogen?
Tatsächlich ändert sich gerade einiges in der Registerbehandlung und automatischen Checks. Ich bin bzgl. der Fehlersuche da ganz bei meinem Vorredner...
"Ä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 ..."

Pfriemler

#3
So, jetzt ich auch. Scheint eine ähnliche Ursache zu haben. Aktuell V 22393 vom 13.7. 18:04 Uhr.

Hier überwacht ein HM-Messzwischenstecker ein Gerät und schaltet es bei Überstrom ab (internes Peering) und triggert gleichzeitig einen vccu_btn (als weiteren Peer-Partner).
Ein DOIF reagiert auf Triggerung und sendet eine Nachricht ("Gerät wegen Fehler abgeschaltet").

Heute kam die Meldung nach dem Neustart mit dieser Version, ohne dass ein Ereignis sichtbar vorlag. edit: Wir haben ein neues reading cfgState, welches hier u.U. Triggerungen verursacht, wenn die Regex nicht richtig stimmt.

Der State des Buttons steht dabei unverändert auf Oktober letztes Jahr (letzte Auslösung vom Zwischenstecker). Wieso es also ein (fake-)Event gegeben hat, entzieht sich zur Gänze meinem Verständnis.. Bisher hatte ich kein event-on-change-reading auf dem vccu_Btn gesetzt. Ich werde beobachten ob es hilft. Ich vermute, nur die Schärfung des Regex ist hilfreich, weil sich cfgState auch gelegentlich ändern kann. Gut, vielleicht nicht bei einem vccu_btn ...

"Ä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 ..."

amenomade

Zitatedit: Wir haben ein neues reading cfgState, welches hier u.U. Triggerungen verursacht, wenn die Regex nicht richtig stimmt.

Das hab ich vom Anfang an gesagt ;)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Pfriemler

Zitat von: amenomade am 15 Juli 2020, 19:01:19
Das hab ich vom Anfang an gesagt ;)
Aber es hilft ja auch wenn man weiß wonach man suchen muss und was die Ursache ist. Die Neuerung hat sich ziemlich eingeschlichen und sorgt jetzt auch bei früher "ruhigen" Geräten für spürbar mehr Events, mglw. eben auch obwohl sich am eigentlichen Zustand des Gerätes nix ändert. Das ist nämlich wirklich neu und da hilft auch kein event-on-change-reading, sondern nur eine saubere Eventbehandlung.
"Ä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 ..."

amenomade

Ja, sorry, ich war faul. Vielleicht hätte ich das "warum" von meiner Aussage erklären müssen : ich hatte irgendwo gelesen, dass neue Readings mit entspr. Events gekommen sind, aber ich habe mir nicht die Mühe gegeben, es wieder  zu suchen ;)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

martinp876

Es ist natürlich ein Problem  wenn sich etwas ändert.  Das ist bei jeder Änderung so. 
Um sicher aufgestellt zu sein rate ich , readings  bzw. Notifies auszucodieren.  Auch wenn fhem dazu einlädt mit wildcards zu arbeiten ist das immer gefährlich. Das System lebt.  Bestehende readings sollten nicht verändert werden. Das muss schon ein Notfall sein.  Aber erweiterbar muss das System schon sein.
Kritisch wie immer ist das reading "state"welches in Bezug auf notifys schlecht implement ist.
Auch wenn ich mir mit der Aussage keine Freude mache: wenn ihr nach der Einführung der neuen readings Probleme hattet war eure Implementierung zwar funktional aber doch unsauber, nicht Zukunftssicher und stand auf dünnen Füßen.
Fhem bietet durchaus die Möglichkeit es besser zu machen.

Natürlich fühle ich mit euch. Allerdings kann euch so etwas bei wildcards jederzeit wieder ereilen.