Bei Reboot/Neustart der CCU verändert ein ETRV-2 die SOLL Temperatur und lößt einen Boost aus

[baueric]

Hallo Zusammen...

es ist jetzt schon zum zweiten Mal passiert, dass in meinem Arbeitszimmer nach einem Reboot/Neustart der CCU3 das ETRV-2 Thermostat in einen Boost gegangen ist und die Heizgruppe seine SOLL-Temperatur verändert hat. Die übrigen Gruppen/Thermostate waren nicht betroffen. Das erste Mal lief die CCU mit der original FW 3.65.11, dieses Mail mit RaspberryMatic 3.65.11.20221005. Die Firmware aller ETRV-2s ist aktuell (2.2.. Insgesamt neun Thermostate, 11 Fensterkontakte und acht WTH-2s in 8 Heizgruppen zusammengefasst. Es gibt keine Hinweise im Systemprotokoll und auch kein Programm, das für das Arbeitszimmer die SOLL-Temperatur steuert. Ferner habe ich Anwesenheit Variable in die Funktion BootFlag umfunktioniert und in meine Programme integriert. Es gibt auch kein Node-RED Flow. Der iOBroker liest nur die die Daten für Grafana...

Hat jemand eine Idee wie ich dem Problem auf die Spur kommen kann?

[jmaus]

Alle Programme deaktivieren und nochmal reboot machen. Wenn es dann nicht passiert liegt es an einem Programm das du dann falsch ausgelegt hast bzw nicht beachtet hast das bei einem CCU Neustart ja immer alle Programme 1x zum Initialisieren ausgeführt werden.

[Gluehwurm]

Button Einstellungen -> Gerät -> eTRVxx -> Button Programme

Gruß
Bruno

[baueric]

Button Einstellungen -> Gerät -> eTRVxx -> Button Programme

Diese Ansicht ist leer.

Grüße Eric

[jmaus]

Diese Ansicht reicht mitunter nichz. Es kann auch sein das ein programm ein anderes gerät triggert welches selbst eine DV mit dem TRV hat. Insofern wie gesagt alle WebUI Programme einfach mal ausschalten!

[Xel66]

...das bei einem CCU Neustart ja immer alle Programme 1x zum Initialisieren ausgeführt werden.

Sorry, dass ich widerspreche (und es ist definitiv nicht meine Absicht, Dir ans Bein zu pissen), aber gerade Du solltest es ja wissen, dass das so nicht korrekt bzw. äußerst missverständlich formuliert ist. Aber ich habe es aufgegeben, hier stets den Don Quijote zu machen. Diese Behauptung wird nicht wahrer, wenn man sie noch so oft wiederholt. Würden die Programme "ausgeführt", dann würde auch eine Aktion durchgeführt. In den Logs ist nachvollziehbar, dass lediglich eine Prüfung der Bedingungen durchgeführt wird.

Das wurde vom Hersteller so angelegt, vermutlich um das System in einen konsistenten Zustand entsprechend der aktuellen Status (die aber auch manchmal falsch sein können, weil frisch mit Default initialisiert) gestellt wird. Ergibt keine Bedingung eines Programms ein WAHR, wird die Prüfung ohne Aktion abgebrochen (auch im Log ersichtlich).

Solche unpräzisen Behauptungen treiben nur noch mehr unbedarfte Nutzer in die Fänge der "Hamelner-Jungs" (einer läuft eine falsche Melodie flötend vorneweg und alle rennen blind hinterher) und sie bauen sinnfreierweise den Workaround in alle ihre Programme ein, weil sie vermeiden wollen, dass "unerwünschte Aktionen" ausgeführt werden. Der Workaround ist in Einzelfällen sinnvoll, aber der universelle Einsatz ist einfach nur Bull und kann eben wunderbar einen single point of failure darstellen, der das komplette System auf den Bauch legt. Ist dann quasi ein Masterswitch jeglicher Automation. Wer's braucht...!?!

Gruß Xel66

[baueric]

Das wurde vom Hersteller so angelegt, vermutlich um das System in einen konsistenten Zustand entsprechend der aktuellen Status...

Wenn ich Holger richtig in seinen Seminaren verstanden habe, wir u.U. der "Sonst" Zweig ausgeführt. Ich habe ein paar "Sonst wenn" Zweige, da bei einem Start idR. aber meist min. eine Bedingung nicht greift, laufen die Progs IMHO nicht. Nur ggf. das Backup Programm und das OpenWeather Script (Scheduler). In der Statusliste wird auch nur ein Teil der Programme mit einem Datum der letzten Ausführung bei einem Neustart gekennzeichnet.

Nun zu meinen Tests. Ich habe heute Neustarts sowohl mit aktivierten als auch ohne aktivierte Programme durchgeführt und konnte das Verhalten nicht reproduzieren. Der Fehler ist nun zweimal innerhalb von 47 Tagen aufgetreten. Einzige Besonderheit gestern war eine Alarmmeldung in der CCU: Ein WatchDog hatte chronyd neu gestartet. Heute waren keine Meldungen die Neustarts betreffend.

Grüße Eric

[Xel66]

Wenn ich Holger richtig in seinen Seminaren verstanden habe, wir u.U. der "Sonst" Zweig ausgeführt.

Korrekt, denn dieser Aktionsweg kommt ja zur Ausführung, wenn die vorher geprüfte(n) Bedingung(en) kein WAHR ergeben. Darum bietet die Verwendung von SONT auch viel Konfliktpotenzial, besonders in Programmen, in denen der Workaround verwendet wird, denn dort ergibt die Prüfung potenziell immer ein FALSCH. Und genau das kann auch zu unerwünschten Ergebnissen führen. Darum meine gebetsmühlenartige Hinweise, diesen Workaround nur ganz bewusst an Stellen, an denen er notwendig oder zielführend ist, einzusetzen - und keineswegs global und ohne nachvollziehen zu können (Stichwort: Einsteigerskills) was er in dem jeweiligen Programm bewirkt.

Gruß Xel66