Nach FW Update, Systemvariable hat ungültigen Wert nach Reboot

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Nach FW Update, Systemvariable hat ungültigen Wert nach Reboot

Beitrag von jp112sdl » 11.04.2021, 12:33

Alles zum SDV gibt es hier: viewtopic.php?f=31&t=47049
Irgendwo findest du dort auch angehängte Downloaddateien.
Zur Freischaltung musst du dann nur 1x niederknien und Herrn Black per Privatnachricht um eine Lizenz bitten.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Benutzeravatar
Black
Beiträge: 5463
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 418 Mal
Danksagung erhalten: 1069 Mal
Kontaktdaten:

Re: Nach FW Update, Systemvariable hat ungültigen Wert nach Reboot

Beitrag von Black » 11.04.2021, 12:40

fast richtig.... per PN anschreiben reicht allerdings...
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg

Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann

Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W

technical contribution against annoying advertising

coffeejunk
Beiträge: 27
Registriert: 04.06.2020, 13:32
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 3 Mal
Danksagung erhalten: 1 Mal

Re: Nach FW Update, Systemvariable hat ungültigen Wert nach Reboot

Beitrag von coffeejunk » 11.04.2021, 13:54

Xel66 hat geschrieben:
09.04.2021, 15:32
Ach ja, es wird bestimmt gleich jemand um die Ecke kommen und behaupten, dass alle Programme beim Reboot laufen und dass das unerwünscht ist und man dagegen einen Workaround in alle Programme (basiert auf der originalen Anwesenheisvariable) einfügen muss. Sorry, das ist und bleibt Bullsh*t. Mit einer geeigneten Bedingungsetzung kann man die meisten Probleme umschiffen (indem man z.B. Trigger nicht auf Default-Werte z.B. 0°C setzt). Und Programme, die durch Tastenbetätigung, Zeitmodule oder andere bewusste Trigger gesetzt werden, braucht man auch nicht auf diese Weise "sichern".
Dass alle Programme beim Neustart an getriggert werden, da sind wir einer Meinung.

Allerdings, die Ausführung so mancher Ansteuerung zu verhindern direkt nach Start der Zentrale, finde ich äußerst sinnvoll. Die aktuellen Zustände vieler Sensoren werden zwar auf den letzten Stand gesetzt, ob die jetzt aber direkt nach dem Start den tatsächlich aktuellen Zuständen entsprechen, darauf kann man sich jetzt wirklich nicht verlassen. Auch Systemvariable sind zu diesem Zeitpunkt noch nicht "sicher" gesetzt.

Mal angenommen, du hast Fensterkontake und eine Innen-Jalousie, alle Fenster sind zu, die Jalousie ist oben, es scheint gerade keine Sonne.

Du fährst die Zentrale runter, zwischenzeitlich scheint die Sonne und Mammi öffnet 2 Fenster.

Du startest die Zentrale neu, deine Programme fangen an zu werkeln , wie würdest du dann deine Bedingungen setzen, damit die Jalousie nicht runter gefahren wird? Merke: Die Fenstersensoren waren geschlossen und habe diesen Zustand, ca 1 Stunde lang, sofern sich nichts ändert. Alle Bedingungen sind zu diesem Zeitpunkt Fragwürdig, da nicht sicher ist, ob sie den aktuellen Zustand in der Zentrale haben...... als die Fenster geöffnet wurden, war die Zentrale "Offline"

Auf welche Zustände, Systemvariable etc. kannst du dich zu diesem Zeitpunkt verlassen?? Keine!
Gruß
Jürgen

MichaelN
Beiträge: 9562
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 696 Mal
Danksagung erhalten: 1608 Mal

Re: Nach FW Update, Systemvariable hat ungültigen Wert nach Reboot

Beitrag von MichaelN » 11.04.2021, 14:00

Ich löse das so, indem ich diesen Sensoren beim Reboot einen fail-safe Status "Unterschiebe". Meinem SRH also "offen". Das bleibt dann solange bis der Sensor seinen Status aktualisiert oder ich den Türgriff betätige. Aber ich blockiere nicht einfach alle Programme bei Systemstart wahllos. Ganz im Gegenteil ist mir dann wichtig, das schnellstmöglich Stati wie "Tag", "Sonne", etc. wieder aktualisiert werden.

Aber ich glaube nicht, das diese Diskussion dem TO hilft, da ich noch nie gehört habe, das eine Werteliste nach dem Boot einen ungültigen Wert annimmt.
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

Benutzeravatar
Black
Beiträge: 5463
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 418 Mal
Danksagung erhalten: 1069 Mal
Kontaktdaten:

Re: Nach FW Update, Systemvariable hat ungültigen Wert nach Reboot

Beitrag von Black » 11.04.2021, 14:06

es gibt dabei kein schwarz oder weiss.fakt ist,bei CCU start werden alle Programme gemäß der Reihenfolges ihres Vorkommens in ID_PROGRAMS angestossen.
Es gibt durchaus Fälle, wo man dieses auch sinnig zur Aktualisierung nutzen kann. Beispielsweise CCU ging OFF bei zeitsteuerungTag,nun wieder ON bei Zeitsteuerung Nacht. Hier braucht es das programm zur aktualisierung des Zustandes.

Ebenso kann man den Geräten (in der regaHSS) bei Start CCU zustände aufzwingen. Ich nutze dies z.b.für die fenster und Türsensoriken.
UseCase: tur ist auf, hinten im garten mit dem Nachbarn am quatschen... stromausfall, netzwiederkehr - sensoren werden als tür zu erkannt, es kommt die nacht erkennung und du pennst die nacht auf der terasse, weil die türrollos zugefahren sind.

umgekehrt, wenn ein unklarer zustand gefährliche Bewegungen hervorrufen kann (Zerstörung einer Jalosie bei offener Tur, so muss der Zustand nach Neustart als unklar gespeichert werden, und bei unklar finden keine automatischen bewegungen statt.
Das ist aber Sache des Anwenders dies zu definieren und auch zu programmieren.

Black
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg

Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann

Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W

technical contribution against annoying advertising

Hütte
Beiträge: 746
Registriert: 08.02.2017, 11:08
Hat sich bedankt: 32 Mal
Danksagung erhalten: 75 Mal

Re: Nach FW Update, Systemvariable hat ungültigen Wert nach Reboot

Beitrag von Hütte » 11.04.2021, 17:01

coffeejunk hat geschrieben:
11.04.2021, 12:22
Hütte hat geschrieben:
10.04.2021, 19:40
Vor einiger Zeit gab es aber durch eine Änderung in der FW für das Haupt-Funkmodul, die dazu führte, dass die Frequenz leicht verschoben war und dadurch zu vermehrten Kommunikationsstörungen führte. Dies wurde mit der letzen Ändereung an der FW für das Funkmodul (hat nichts mit dem Rest zu tun) wieder korrigiert. Und diese FW für das Funkmodul ist "closed Source", die nur durch eQ-3 geändert werden kann. Da kommt auch Jens nicht dran, um da was anzupassen.
Heisst dass, dass die Änderungen in der aktuellen RM jetzt noch mit drin sind, oder sind sie dort schon wieder draussen?
Wie ich schrieb, wurde es wieder korrigiert. D.h., die Frequenzverschiebung ist wieder draussen.

Bis jetzt ist aber immer noch nicht klar, was du mit LAN-GW meinst. Meinst du ein HM-LAN-GW? Oder einen HmIP-HAP, der als LAN-Gateway für HmIP-Geräte funktioniert?

Welches Thermostat setzt du ein? Denn wenn Konfigurationsdaten zur Übertragung anstehen, dann muss am Thermostat eine Taste gedrückt werden. Bei HmIP-Geräten ist es meist die Systemtaste auf der Vorderseite. Bei klassischen HM-Geräten muss man meist eine kleine Taste im Inneren des Gerätes kurz drücken. Genaueres findest du in der Bedienungsanleitung des Gerätes. Falls du die nicht mehr haben solltest, dann findest du sie auch zumindest auf der Webseite von ELV bei dem jeweiligen Gerät.

Wenn der DC der Zentrale hochgeht, dann läuft der Funkverkehr auch über das Funkmodul der Zentrale. Wenn der Funkverkehr über ein LAN-GW läuft, dann hat das keinen Einfluss auf den DC der Zentrale, sondern nur auf den DC des entsprechenden LAN-GW.

Aber eventuell hast du irgenwo einen Babbling-Idiot, also ein Gerät, dessen Batterie kurz vor dem Verrecken ist und dadurch im Dauerfeuer funkt. Als Ergebnis treibt dies den DC der Zentrale nach oben.

coffeejunk
Beiträge: 27
Registriert: 04.06.2020, 13:32
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 3 Mal
Danksagung erhalten: 1 Mal

Re: Nach FW Update, Systemvariable hat ungültigen Wert nach Reboot

Beitrag von coffeejunk » 11.04.2021, 19:05

Hütte hat geschrieben:
11.04.2021, 17:01

Wie ich schrieb, wurde es wieder korrigiert. D.h., die Frequenzverschiebung ist wieder draussen.

Bis jetzt ist aber immer noch nicht klar, was du mit LAN-GW meinst. Meinst du ein HM-LAN-GW? Oder einen HmIP-HAP, der als LAN-Gateway für HmIP-Geräte funktioniert?
Ich meinte ein HM-LAN-GW, dieses habe ich jetzt mal deaktiviert, da ich dieses irgendwie im "verdacht" habe.
Hütte hat geschrieben:
11.04.2021, 17:01
Welches Thermostat setzt du ein?
Die betroffenen Thermostate waren vom Typ HM-TC-IT-WM-W-EU
Hütte hat geschrieben:
11.04.2021, 17:01
Wenn der DC der Zentrale hochgeht, dann läuft der Funkverkehr auch über das Funkmodul der Zentrale. Wenn der Funkverkehr über ein LAN-GW läuft, dann hat das keinen Einfluss auf den DC der Zentrale, sondern nur auf den DC des entsprechenden LAN-GW.

Aber eventuell hast du irgenwo einen Babbling-Idiot, also ein Gerät, dessen Batterie kurz vor dem Verrecken ist und dadurch im Dauerfeuer funkt. Als Ergebnis treibt dies den DC der Zentrale nach oben.
Seltsam war halt nur, als ich die Wandthermostate (einzeln) neu angelernt hatte, der DC sprunghaft von 15% auf 99% angestiegen ist, was mich irgendwie vermuten lässt, dass das Gateway da die Finger im Spiel hatte.

Ich denke, dass ich den Grossteil der Probleme nun im Griff habe (außer die Initialisierung der Systemvariable. Die Wandthermostate, die nach dem Update der Raspberrymatic das fehlverhalten gezeigt haben (F10 usw.) habe ich festgestellt, dass in der RM defekte Verknüpfungen vorhanden waren. Wie auch immer das passiert ist, ich musste die Heizgruppen auflösen, danach manuell die defekten Verknüpfungen entfernen, danach konnte ich die Geräte jeweils in die entsprechenden Heizgruppen schieben.

Auch schien die Konfiguration der LAN Gateways, als wo man festlegen kann, welches Gerät sendet an welches Gateway , nicht dem tatsächlichem Verkehr entsprochen zu haben, soll heißen, es sah so aus, als ob die Geräte die Meldungen nicht an die festgelegten Gatewasy/RM gesendet haben, das könnte den hohen DC erklären.....

Das war das erste Update, das so richtig in die Hose gegangen ist. Da ich das Gateway abgeschaltet habe, kommt es jetzt vermutlich vermehrt zu Störungen, muss ich mal abwarten. Ich danke euch auf jedenfall für die Hilfe!

Mein IObroker wollte gestern auf einmal auch keine aktuellen Zustände bei ca. 20 Geräten mehr übernehmen, in der RM war UNREACH false in IObroker war UNREACH bei den Geräten true. Auch ein Neustart hat da nichts gebracht. Erst nachdem ich auf der RM alle Probleme gelöst hatte, waren die Zustände der RM nach einem RESTORE von IObroker, wieder synchron.... Weiss der Geier.....

Ich habe noch ein zweites Gateway im Dach, das ist eine umfunktionierte CCU2, die war davon komplett unbeeindruckt, Probleme gabs nur mit den Geräten an dem original Gateway von ELV.

Das Problem mit der Systemvariable werde ich auf einem getrennten System mal genauer analysieren. Durch die ständigen Reboot's, habe ich mich dieses Wochenende etwas unbeliebt gemacht :?

Jürgen
Gruß
Jürgen

Xel66
Beiträge: 14086
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 581 Mal
Danksagung erhalten: 1492 Mal

Re: Nach FW Update, Systemvariable hat ungültigen Wert nach Reboot

Beitrag von Xel66 » 11.04.2021, 20:52

coffeejunk hat geschrieben:
11.04.2021, 13:54
Dass alle Programme beim Neustart an getriggert werden, da sind wir einer Meinung.
In dem Satz fehlt ein NICHT. Ansonsten sind wir diesbezüglich auch nicht einer Meinung. Ich dachte eigentlich, dass ich unmissverständlich klar gemacht habe, dass diese Behauptung auch durch häufige Wiederholung nicht an Wahrheitsgehalt gewinnt.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

Hütte
Beiträge: 746
Registriert: 08.02.2017, 11:08
Hat sich bedankt: 32 Mal
Danksagung erhalten: 75 Mal

Re: Nach FW Update, Systemvariable hat ungültigen Wert nach Reboot

Beitrag von Hütte » 11.04.2021, 20:53

Bezüglich der Zuweisung von klassischen HM-Geräten zu einem HM-LAN-GW benutze ich schon eine ganze Weile den "Homematic Manager" von @hobbyquaker. Damit kann auf dem Reiter "Funk" auf ganz einfache Weise festlegen, ob das jeweilige HM-Gerät über ein bestimmtes HM-LAN-GW kommunizieren soll oder direkt mit der Zentrale. Und das Ganze dann nach ein paar Tagen noch einmal prüfen, gegebenenfalls mal umschalten und erneut testen.

Denn bei den Einstellungen über die WebUI erschliesst sich für mich nicht, was die Auswirkungen sind, wenn bei "Feste Zuordnung aufheben" ein Haken gesetzt wurde und z.B. ein HM-LAN-GW augewählt wurde. Denn auch die aktuellste Version des WebUI-Handbuches schweigt sich dazu komplett aus und liefert keinerlei Information.

Wenn ich über die WebUI diesen Haken setze und im Homematic Manager die Anzeige aktualisiere, dann sehe ich dort, dass ein Flag bei "Roaming" gesetzt ist. Dies könnte eventuell nun dazu führen, dass die Zentrale zuerst versucht, das Gerät direkt zu erreichen. Erst wenn mehrere Versuche erfolglos waren, dann wird es über das erste HM-LAN-GW versucht. Wenn es dann auch noch mehrere HM-LAN-GW's gibt, kann es also unter Umständen passieren, dass erst das letzte HM-LAN-GW erfolgreich ist. In der Zwischenzeit treiben aber all diese Fehlversuche den DC der jeweils anderen Funkmodule nach oben. Irgendwie auch nicht im Sinne der Erfinder. Dies könnte also eventuell erklären, warum dein DC so sprunghaft angestiegen ist. Aber auch dann sollte man etwas Ruhe bewahren und das System erst einmal wenigstens eine Stunde laufen lassen und schauen, ob der DC sich wieder normalisiert.

Wenn du dann auch noch mehrere Geräte neu anlernst, dann erzeugt das ebenfalls Traffic im Funkmodul. Das darf aber halt pro Stunde nur 36 Sekunden senden. Und wenn zusätzlich auch noch das Gerät schlecht erreichbar ist, dann ergibt das also weiteren Traffic, der deinen DC nach oben treibt.

Man könnte eigentlich fast sagen: "Homematic ist wie Tier in freier Wildbahn". Hektische Aktionen sind auf jeden Fall zu vermeiden. Ruhe bewahren, damit sich das Tier sich an die neue Situation gewöhnen kann. Danach kann man den nächsten Schritt unternehmen. :wink:

Da nutze ich lieber den Homematic Manager und kann die Einstellungen und das Ergebnis ziemlich gut kontrollieren und beinflussen.

Und die angezeigten RSI-Werte sollte man auf keinen Fall als "der Weisheit letzten Schluss" auffassen. Eher als ersten Hinweis. Aber auch der kann täuschen. Daher lieber etwas testen und schauen, welche Einstellung besser funktioniert.

Viele Grüße,
Hütte

Benutzeravatar
Black
Beiträge: 5463
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 418 Mal
Danksagung erhalten: 1069 Mal
Kontaktdaten:

Re: Nach FW Update, Systemvariable hat ungültigen Wert nach Reboot

Beitrag von Black » 11.04.2021, 21:30

Xel66 hat geschrieben:
11.04.2021, 20:52
In dem Satz fehlt ein NICHT. Ansonsten sind wir diesbezüglich auch nicht einer Meinung. Ich dachte eigentlich, dass ich unmissverständlich klar gemacht habe, dass diese Behauptung auch durch häufige Wiederholung nicht an Wahrheitsgehalt gewinnt.
Gruß Xel66
ALso ich sehe das nicht so und das entspricht nicht meinen empirisch gemachten Erfahrungen

mein Spielesystem schaut immo so aus:

PRG.JPG

in jedes programm habe ich ein kleines Loggerscript in jeden Wenn, Sonstwenn und Sonst zweig hineingesetzt.

Die Bedingunen sind wild gemischt, mal Zeitprogramm, mal tastendruck eines HMIP gerätes, Mal ystemvariablen.

Dann das System neugestartet.

Im Log sieht man Wunderbar die Reihenfolge der Programme, wie diese gestartet wurden... es sind alle (aktivierten), und die reihenfolge entspricht der Reihenfolge in ID_PROGRAMS (Die beiden Systeminternen habe ich nicht manipuliert, könnte ich in einem zweiten Lauf aber auch noch)

PRG2.JPG

Natürlich wird hierbei NICHT, wie bei ProgramExecute, Blind in die erste Destiation gesprungen, sondern es findet eine Saubere Bedingungsprüfung statt. Wäre noch eine $scr$ Ausgabe dabei programmiert, so verweist diese auf ein NULL object bzw ins Nirvana, auch logisch, es fand ja kein Trigegr durch einen Datenpunkt, zeitmodul o.ä. statt.


Das Systemlog ergibt dann

Code: Alles auswählen

Apr 11 21:12:15 SpieleSystem user.debug Test2: [Wenn]
Apr 11 21:12:15 SpieleSystem user.debug Test1: [Wenn]
Apr 11 21:12:15 SpieleSystem user.debug Test: [Sonst]
Apr 11 21:12:15 SpieleSystem user.debug StartScript: [Sonst]
Apr 11 21:12:15 SpieleSystem user.debug StartProgII: [Sonsr]
Apr 11 21:12:15 SpieleSystem user.debug Keypressed: [Sonst]
Apr 11 21:12:15 SpieleSystem user.debug FSMKopierQuelle: [Sonsr]
Apr 11 21:12:15 SpieleSystem user.debug EinTest: [Wenn]
Apr 11 21:12:15 SpieleSystem user.debug DebugVars: [Sonst]
Apr 11 21:12:09 SpieleSystem user.info monit[937]: 'SpieleSystem' Monit 5.27.2 started

Achtung, SDV Logger, dabei ist das oberste Element das letzte Element.

So das ist mein Aufbau und meine Argumentationsführung, nun deine.

Black
Zuletzt geändert von Black am 11.04.2021, 21:35, insgesamt 1-mal geändert.
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg

Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann

Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W

technical contribution against annoying advertising

Antworten

Zurück zu „RaspberryMatic“