[Gelöst] Nach Neustart / Stromausfall / .. falsche Readings in Devices

[Gear]

Hallo zusammen,

mein FHEM merkt sich die letzten Readings nicht.
Im Bild ein Beispiel.

- Blau ist das Setzen auf 0 um 0 Uhr. > Ist gewollt.
- Gelb war der Neustart des Servers nach Update.
- Grün war der Neustart von FHEM nach Update.

Es betrifft alle Devices und wenn man die Readings anschaut, dann sind diese Timestamps der Readings von einem alten Datum.

Das Problem hatte ich damals mit FHEM direkt auf dem RPi 4 und jetzt mit FHEM in Docker auf einem ODroid H3.
An Docker liegt es nicht, FHEM wird beim Stop von Docker ordnungsgemäß heruntergefahren, laut Konsole.

Was braucht Ihr für Informationen?

Vielen Dank
Grüße
Gear

[RalfRog]

Die Readings werden nach einem Neustart ja aus "log/fhem.save" wieder hergestellt.
Schau doch mal im Zeitstempel ob die Datei korrekt geschrieben wenn FHEM gestoppt wird.
Manuell kann man das Schreiben auch auslösen {WriteStatefile()}

[Gear]

Ok, nun scheint FHEM bei einem "Shutdown/Restart" die Readings zu speichern und auch korrekt zu laden.

Bei einem Neustart des Containers passiert dies aber nicht.
Hier sehe ich in der Konsole des Containers die Ausführung des "Shutdown".

Wann werden denn die Readings in die File geschrieben?
Sobald diese gesetzt werden oder nur bei einem "Shutdown/Restart"?

[betateilchen]

Das statefile wird nur automatisch geschrieben, wenn der Befehl "shutdown" ausgeführt wird. Egal, ob mit oder ohne restart.

[Gear]

Gibt es eine Möglichkeit, das zu umgehen?
Ein "at" alle x Zeit?

Oder eine ganz andere Möglichkeit?

Danke!

[Damian]

Ich speichere meine save-Datei im Stundentakt, um einem Datenverlust vorzubeugen.

Code Auswählen Erweitern

defmod di_save DOIF {[:00];;fhem"save"}

[betateilchen]

Gibt es eine Möglichkeit, das zu umgehen?
Ein "at" alle x Zeit?

Es gibt sogar eine Suchfunktion hier im Forum, mit der man verschiedene Lösungsansätze finden könnte, wenn man sie benutzt.

Code Auswählen Erweitern

define at_statefile at +*01:00:00 {WriteStatefile}

[Gear]

Vielen Dank für die Hilfe!

[Otto123]

Bei einem Neustart des Containers passiert dies aber nicht.

Wie ist Dein Container gebaut?
Normalerweise wird beim shutdown des Containers erst ein shutdown an FHEM gesendet, ein Wartemechanismus gebaut der überprüft ob FHEM herunter gefahren ist, erst dann wird der Container beendet.
Offenbar funktioniert oder existiert dieser Mechanismus bei Dir nicht.

[Gear]

Hey Otto,

also wenn ich in der Konsole des FHEM Containers in Portainer bin, dann sehe ich den "Shutdown", dennoch schreibt es nichts in die Datei.
Habe nun das "at" und seit dem speichert es das ab.

Meine Docker Compose für FHEM:

Code Auswählen Erweitern

version: '3'
services:

  fhem:
    container_name: FHEM
    image: fhem/fhem:latest
    hostname: fhem
    restart: always
    deploy:
      resources:
        limits:
          memory: 1536m
    networks:
      internal:
        ipv4_address: 172.88.0.7
      external:
        ipv4_address: 192.168.200.119
    ports:
      - "8083:8083"
      - "7072:7072"
      - "6767:6767/udp"
    environment:
      PIP_PKGS: "fhem beautifulsoup4"
      PAN_PKGS: "Crypt::Cipher::AES or Crypt::Rijndael_PP"
    volumes:
      - /UserPath/FHEM:/opt/fhem
Grüße
Gear

[Otto123]

naja Du hast einen Würgaround gebaut. FHEM schreibt das state File wenn es ordentlich beendet wird. Du solltest die Ursache des Fehlers finden ...

Nochmal gefragt: Der Fehler entsteht wenn du den Container neu startest oder wenn Du in FHEM shutdown restart machst?

Du verwendest das von sidey gebaute fhem Image - das behandelt den shutdown des containers normalerweise ordentlich
https://github.com/fhem/fhem-docker/blob/dev/src/entry.sh
Welche Version setzt Du ein?

Was gibt Dir das zurück?

Code Auswählen Erweitern

list global pidfilename

[Wernieman]

@Otto: Habe mich jetzt durch den Code versucht zu wühlen ... bist Du Dir sicher?

[Otto123]

In meinem Link ab Zeile 465 ...

Wenn FHEM z.B. keinen pidfile schreibt dann rennt er dort einfach durch und beendet Container ohne auf FHEM zu warten.

[Gear]

Was gibt Dir das zurück?

Code Auswählen Erweitern

list global pidfilename

Code Auswählen Erweitern

global ./log/fhem.pidDie PID File wird auch von Änderungsdatum verändert.

Nochmal gefragt: Der Fehler entsteht wenn du den Container neu startest oder wenn Du in FHEM shutdown restart machst?

So, habe nun folgendes getestet:

> Shutdown/Restart über FHEM
>> Wird das Änderungsdatum von fhem.save verändert.

> Restart, Stop > Start über Portainer
>> Wird das Änderungsdatum von fhem.save nicht verändert.

Du verwendest das von sidey gebaute fhem Image - das behandelt den shutdown des containers normalerweise ordentlich
https://github.com/fhem/fhem-docker/blob/dev/src/entry.sh
Welche Version setzt Du ein?

Nutze das von Docker Hub, habe eben das Img neu gezogen, bleibt unverändert.

[Otto123]

Die PID File wird auch von Änderungsdatum verändert.

Das pidfile wird also wirklich geschrieben?
Im laufenden FHEM in der FHEM Kommandozeile testen:

Code Auswählen Erweitern

{qx(ls -lha ./log/fhem.pid)}Das shutdown wird über local Telnet ausgelöst, gibt es das device?

Code Auswählen Erweitern

list TYPE=telnetnormal heisst das device so

Code Auswählen Erweitern

list telnetPort