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

[coffeejunk]

Hallo zusammen,

ich habe gestern mein System auf (RPI4) auf den Firmwarestand 3.57.4.20210320 gebracht.

Nun habe ich das Problem, dass nach einem, Reboot immer eine Systemvariable (und nur die eine...) auf einen ungültigen Wert gesetzt wird. Vor dem Update hatte ich damit keine Probleme.

SysVar.PNG (4.43 KiB) 834 mal betrachtet

Diese Variable hat 4 mögliche Zustände (Index 0-3), nach einem Reboot hat sie allerdings immer den Index 4 als aktuellen Zustand, der jedoch nicht gültig ist und deshalb die Ausführung der zuständigen Programme verhindert. Hat jemand von euch ein ähnliches Problem, seit dem Update?

Faszinierend ist, dass es nur diese eine Variable betrifft. Listet man nach einem Reboot alle Systemvariable und deren Werte auf, ist dies die einzige, die in der WebUI keinen Wert besitzt. Liest man dann den aktuellen Index der Variable aus, ist dieser immer 4.

Setze ich nun die Variable "händisch" auf Standby, also Index 0, hat sie nach dem Reboot wieder den Index 4------

Irgendwelche Ideen?? Wurde da etwas in der FW bezüglich der Systemvariable geändert?

[Xel66]

Da wird wohl ein Programm bei Systemstart laufen, welches mangels besseren Wissens die Systemvariable auf diesen Wert setzt. Von allein ändern sich die Variablen mit einer einzigen Ausnahme (originale Anwesenheitsvariable) nicht. Dieses Programm musst Du identifizieren und die Trigger bzw. zusätzlichen Bedingungen entsprechend setzen. Ein Grundproblem ist eben, dass bestimmte Sensoren bei Systemstart einen Default-Wert bis zur ersten Statusübermittlung bekommen. Bei Temperatursensoren ist das 0°C und bei Türkontakten z.B. "geschlossen". Auch werden netzversorgte (klassische) Aktoren abgefragt und deren Statusmeldung kann auch eine Bedingungsprüfung anstoßen. Solche Sachen sind zu berücksichtigen.

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

Gruß Xel66

[coffeejunk]

Seltsam nur, dass es vor dem Update kein Problem gab, erst danach.

Nun ja, morgen werde ich mal das weiter analysieren und meine Mitbewohner mit unzähligen Reboots nerven...

Dazu werde ich meinen IO-Broker schlafen legen und alle Programme, die auf die Systemvariable zugreifen, mal abschalten......

Und vorher alle Standby Steckdosen entfernen, nicht dass wieder einer mitten im Game stromlos wird.....

Aber ich meine, irgendwo genau über so ein Problem, mit der Initialisierung auf schnellen Raspis, irgendwas gelesen zu haben, leider weiß ich nicht mehr wo und habe auch schon auf Github gesucht......

Vielleicht krätscht auch von der IO-Broker Seite was dazwischen.... da habe ich auch einige Adapter aktualisiert.... mal sehen....ich berichte.....

[coffeejunk]

Also irgendwie spinnt gerade immer mehr hier! Nun haben nach jedem Reboot irgendwelche Geräte Kommunikationsstörung, Wandthermostate bleiben mit F10 stehen usw. immer wieder nach einem Reboot anders.... bis gestern hatte ich ein stabiles System

Gerade nochmal einen Reboot gemacht zum testen, seltsamerweise bekomme ich für die Systemvariable verschiedene Werte angezeigt.

Bei Status-> Systemvariable hat sie den falschen Wert
Bei Systemvariable, wenn ich sie in Bearbeitung nehme, wird der Wert für Standby (also Index 0) angezeigt....

Ich glaube das Update hat mir nachhaltig irgendetwas zerschossen! Werde jetzt mal das System neu aufsetzen und das Backup vor dem Update einspielen... jetzt mal die Zentrale runter gefahren und einen Kaltstart gemacht, mal sehen....

Heute habe ich das erste mal das Update direkt von GitHub gemacht und scho wars nix..... vielleicht war auch das das Problem.

[MichaelN]

Kauf dir mal ne neue SD Karte

[coffeejunk]

Hallo,

Stand der Dinge:

[*]Neue SD-Karte
[*]RaspberryMatic 3.55.5.20201226 neu installiert
[*]Backup (Stand vor dem Update) eingespielt

So wie ich es jetzt sehe, habe ich 2 unterschiedliche Probleme:

Systemvariable:
Das Problem mit der falsch gesetzten Systemvariable, besteht nach wie vor. Alle Programme, die auf die Variable zugreifen, habe ich kontrolliert. Über die WebUI ist es eh nicht möglich, die Variable auf einen "ungültigen" Wert zu setzen. Keine Ahnung warum die Variable auf den Index 4 gesetzt wird. Vermute mal, dass dieses Problem bei einem anderen Update auftrat. Gibt es eine Möglichkeit, die Programme so anzuzeigen, wie sie intern im System gespeichert sind?

DytyCycle in V 3.57.4.20210320
Im Normalbetrieb (alte Firmware 3.55.5.20201226) hatte ich seither einen DC von 4-10% in der CCU, mit der neuen Firmware (V 3.57.4.20210320)habe ich im Normalbetrieb meist über 25%, das ist seltsam.
Auch die Kommunikationsstörungen, wo sich dann einige Geräte "weg hängen" und nie wieder mit der Zentrale sprechen möchten, sind komisch. Anscheinend wurde Funktechnisch etwas geändert, was zu einem erhöhten DC führt.

Geräte, die vor dem Downgrade bereits auf "Kommunikation gestört" waren, sind auch mit der alten Firmware nach einspielen eines Backups nicht mehr erreichbar gewesen. Erst nach Entnahme der Batterien und Neustart, haben sich die Geräte wieder gemeldet .

Sehr seltsam das ganze. Ich bleibe jetzt erstmal auf der alten Version.....

Möglich, dass es Konflikte gibt, da an der CCU auch noch zwei LAN-Gateways dran hängen. Ist das Update, welches das Funkmodul in der CCU bedient auch auf den Gateways präsent oder führen unterschiedliche Übertragungs-Methoden zu genau diesem Problem.....

[MichaelN]

Keine Ahnung warum die Variable auf den Index 4 gesetzt wird. Vermute mal, dass dieses Problem bei einem anderen Update auftrat. Gibt es eine Möglichkeit, die Programme so anzuzeigen, wie sie intern im System gespeichert sind?

Blacks SDV sollte bei solchen Analysen helfen

[Hütte]

Als du die aktuelle Version installiert hattest, was wurde dir da auf der Startseite neben dem DC-Balken im neuen Balken "CS" (Carrier Sense) angezeigt? Denn der gibt Aufschluß darüber, wie stark das Frequenzband von 868 MHz durch Fremdsignale oder dergleichen belegt ist. Denn bei HmIP Geräten prüft das Funkmodul vor dem Senden der Befehle, ob der Level nicht zu hoch ist. Ist er zu zu hoch wird nicht gesendet und es wird eine Kommunikationsstörung gemeldet. Da reicht es manchmal schon aus, das Funkmodul oder den Raspi (bei aufgestecktem Funkmodul) etwas zu verschieben. Oder andere Störquellen wie WLAN-Router/-Repeater an einer anderen Position zu bringen.

Dass du von Battereie betriebenen nach einem Neustart nicht sofort den aktuellen Status hast, ist vollkommen normal. Die melden sich nur zyklisch bei der Zentrale oder aber wenn bei denen ein Ereignis eintritt, z.B. Fenster öffnen oder schließen. Wenn du die Batterien rausnimmst und wieder einlegst, dann melden sie sich natürlich sofort bei der Zentrale. Da würde es bei einem Fensterkontakt sogar ausreichen, einfach nur den Deckel abzunehmen. Denn dann wird sofort eine Sabotagemeldung an die Zentrale gesendet.

Falls du von einem HM-LAN-Gateway sprechen solltest, da hat sich bezüglich FW für die Funktion des Funkmoduls schon seit Ewigkeiten seitens eQ-3, und somit auch in Raspberrymatic, nichts mehr getan und da wird sich wohl auch michts mehr tun, da es nur für die klassischen HM-Geräte geeignet ist.

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.

[coffeejunk]

Als du die aktuelle Version installiert hattest, was wurde dir da auf der Startseite neben dem DC-Balken im neuen Balken "CS" (Carrier Sense) angezeigt?

Ja, der Wert lag so zwischen 1-3%, Danke für den Hinweis, habe mich schon gefragt, was dieser Wert bedeuten soll.

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?

Irgendwie habe ich gerade den Verdacht, dass etwas schief geht im Zusammenhang mit den LAN-Gateways. Zwischenzeitlich bin ich wieder auf der aktuellen RM und immer wieder Kommunikationsstörungen, hier als Beispiel eine Heizgruppe mit 1 Wandthermostat und zwei Heizkörperregler.

Alle drei angemeldet über ein LAN GW. Heute morgen Störung Regler->Verbundpartner, das heisst Verbindung zur Zentrale i.O.

Die Heizgruppe habe ich "testweise" Aufgelöst, Ergebnis = Für den Wandthermostat stehen Konfigurationsdaten an, die aber nie übertragen werden. Wandthermostat neu gestartet = Von der Zentrale aus erreichbar, Konfig wird aber nicht übertragen.

Wandthermostat reset und neu angelernt direkt an der Zentrale = DC nun von 15% auf 98% hoch.....

Nun habe ich mal alle Geräte vom LAN GW runter direkt auf die Zentrale zum testen..... irgendwie habe ich das Gefühl, dass die Kommunikation gerade doppelt und dreifach über mehrere Wege geht, was den DC erklären könnte.....mal sehen.....

[coffeejunk]

Blacks SDV sollte bei solchen Analysen helfen

Wo bekommt man das? Habe gestern auf Github geschaut, konnte das Projekt zwar finden, aber keine Pakete im REP ???