[gelöst] Statefile - FHEM startet öfter ohne den letzten Stand

[Master_Nick]

Einen schönen Sonntag in die Runde

Ich habe festgestellt, dass trotz save mein FHEM immer mal wieder gern mit einem falschen Stand dann aus einem Reboot aufwartet.

Aus folgendem Beitrag: https://forum.fhem.de/index.php?topic=28132.0

Habe ich unter anderem: {WriteStatefile()}  als Befehl in der menuEntries meiner Web Instanz.
Mittels cmd={WriteStatefile()}

Abhilfe bringt mir das leider dennoch nicht.


Irgendwie ist das schon unschön, wenn man sein FHEM neu startet und dann gehen Geräte an oder oder :-D
Hat jemand eine Idee?

LG!

[MadMax-FHEM]

Nur den Befehl im Menü zu haben bringt auch nix...

Was tust du denn, wenn/dass das Problem auftritt?

Bei einem Reboot bzw. geplantem fhem Neustart sollte das Statefile durch fhem geschrieben werden (unabhängig von dem Menüeintrag).

Steht etwas im Log?
Auszug eines solchen Vorfalls wäre hilfreich...

Wenn fhem "abstürzt" oder der ganze Rechner/PI "hart ausgeht", dann wird logischerweise das Statefile nicht geschrieben und dann startet fhem u.U. mit alten Werten...

Manch einer hat dazu ein zyklisches at welches dann eben das Statefile schreibt...

Gruß, Joachim

[Otto123]

Hat jemand eine Idee?

Aber die Lösung zu Deiner Fehlermeldung (die jetzt weg ist ? ) steht doch im letzten Beitrag in deinem Link?

Dein Problem zum Schluss liegt doch eventuell daran, dass Du in FHEM irgendwelche Abläufe programmiert hast, die beim Start von FHEM falsche Ausgangswerte haben, was nichts mit dem statefile zu tun haben muss.

[Master_Nick]

Hey Mad Max und Otto123,

Natürlich nutze ich den Befehl dann auch und starte dann erst neu, dennoch kam es weiterhin öfter dazu, dass eben die States wild waren und Lampen dann aktiv an gingen nach FHEM Neustart.

Leider neben dem klassischen:

Code Auswählen Erweitern

2024.03.24 12:52:09 0: Server started with 219 defined entities (fhem.pl:28666/2024-03-16 perl:5.032001 os:linux user:fhem pid:3003418)
nach einem normalem Neustart mittels Menüeintrag "cmd=shutdown+restart" ist im Log nix abnormales.
Ich sammmle aber auch gern nochmal eines von einem Vorfall, wo ich das drumherum mit aufzeigen kann, hatte wegen einer anderen Thematik einen Device auf Verbose 5 :-D Das macht da in dem Log dann keinen Spaß.

Das die normalen Vorgänge bei Powerloss oder Absturz nicht greifen -> selbsterklärend jau.

Das Zyklische wäre, so finde ich eher eine Notlösung.

@Otto123 -> Die Meldung hatte ich selber verzapft weil ich einmal den Befehl kopiert hatte mit dem "F" statt "f" und hatte ihn dann für eine Reaktion auf meinen Menüeintrag (der mit kleinem f ist) gehalten. Daher Fehler gesehen und Log Eintrag raus genommen, da er nichts damit zu tun hat.

Ich starte gleich nochmal neu und schaue, was sich tut.

**EDIT: Ich hatte auch noch eine Vermutung einer Fremdübersteuerung durch MQTT Wirrwarr..... noch hat sich da nix bestätigt.
Und natürlich - nun gemacht.... und alles tut wie es soll...

Code Auswählen Erweitern

2024.03.24 13:57:13 1: Server shutdown delayed due to Echo for max 10 sec
2024.03.24 13:57:16 0: Server shutdown
2024.03.24 13:57:25 0: Featurelevel: 6.3
2024.03.24 13:57:25 0: Server started with 219 defined entities (fhem.pl:28666/2024-03-16 perl:5.032001 os:linux user:fhem pid:3067674)
2024.03.24 13:57:30 1: fhempy_peer_192_168_0_8: Can't connect to ws:192.168.0.8:15733: Operation now in progress
2024.03.24 13:57:30 1: fhempy_peer_192_168_0_8: Can't connect to ws:192.168.0.8:15733: 192.168.0.8: Connection refused (111)
2024.03.24 13:57:30 1: BindingsIo (fhempy_peer_192_168_0_8): ERROR during connection setup: 192.168.0.8: Connection refused (111)
2024.03.24 13:57:30 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/10_BindingsIo.pm line 558.

[betateilchen]

und starte dann erst neu, dennoch kam es weiterhin öfter dazu, dass eben die States wild waren und Lampen dann aktiv an gingen nach FHEM Neustart.

Das hat aber nichts mit dem statefile zu tun.
Durch die Abarbeitung des statefile werden keine set Befehle ausgeführt und auch keine Trigger ausgelöst, die Lampen schalten könnten.

[Master_Nick]

Moin moin!

@Betateilchen!

Danke das war der Hinweis.
Dann hatte es echt mit Unstimmigkeit der Payloads im Mosquitto zu tun.
Es kam bisher auch nicht erneut vor.

Vielen lieben Dank für eure Mitteilungen.