FHEM Forum

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

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()}

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

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

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

Oder eine ganz andere Möglichkeit?

Danke!

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

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

Zitat von: Gear am 06 Mai 2023, 19:31:28Gibt 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.

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

Vielen Dank für die Hilfe!

Zitat von: Gear am 06 Mai 2023, 17:24:26Bei 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.

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:
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

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?
list global pidfilename

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

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.

Zitat von: Otto123 am 12 Mai 2023, 23:01:32Was gibt Dir das zurück?

Code Auswählen Erweitern

list global pidfilename

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

Zitat von: Otto123 am 12 Mai 2023, 23:01:32Nochmal 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.

Zitat von: Otto123 am 12 Mai 2023, 23:01:32Du 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.

Zitat von: Gear am 13 Mai 2023, 09:33:34Die PID File wird auch von Änderungsdatum verändert.

Das pidfile wird also wirklich geschrieben?
Im laufenden FHEM in der FHEM Kommandozeile testen:
{qx(ls -lha ./log/fhem.pid)}Das shutdown wird über local Telnet ausgelöst, gibt es das device?
list TYPE=telnetnormal heisst das device so
list telnetPort

Zitat von: Otto123 am 13 Mai 2023, 10:55:58

Code Auswählen Erweitern

{qx(ls -lha ./log/fhem.pid)}

-rw-r-----+ 1 fhem fhem 5 Mai 13 09:26 ./log/fhem.pid

Zitat von: Otto123 am 13 Mai 2023, 10:55:58

Code Auswählen Erweitern

list TYPE=telnet

telnetForBlockingFn_1683962819.63944
telnetPort

Zitat von: Otto123 am 13 Mai 2023, 10:55:58

Code Auswählen Erweitern

list telnetPort

Internals:
   CONNECTS   1359
   DEF        7072
   FD         9
   FUUID      63c39ec9-f33f-cc91-f34f-ba3960a15938f513
   FVERSION   98_telnet.pm:0.257540/2022-02-27
   NAME       telnetPort
   NR         46
   PORT       7072
   STATE      Initialized
   TYPE       telnet
   READINGS:
     2023-05-13 09:26:57   state           Initialized
Attributes:
   DbLogExclude .*
   room       20 System

mir fehlen weitere Ideen. Offenbar ist alles vorhanden.
Einziger Unterschied der mir auffällt: Du hast offenbar ACLs aktiv auf deinem FHEM Pfad. (-rw-r-----+)

Wenn Du den Container stoppst, hast Du dann solche Einträge im Containerlog?
SIGTERM signal received, sending "shutdown" command to FHEM!
Waiting for FHEM process to terminate before stopping container:
2023.05.13 16:33:20.184 0: Server shutdown
FHEM process terminated, stopping container. Bye!

@Otto, ja so ähnlich.

Du könntest das Verhalten mal in den docker Thread (https://forum.fhem.de/index.php?topic=89745.msg1275445) einwerfen, vielleicht hat Sidey eine einfache Idee wie man das debuggen könnte.

Zitat von: Otto123 am 13 Mai 2023, 18:16:08Du könntest das Verhalten mal in den docker Thread (https://forum.fhem.de/index.php?topic=89745.msg1275445) einwerfen, vielleicht hat Sidey eine einfache Idee wie man das debuggen könnte.

Getan, danke!

Zitat von: Gear am 13 Mai 2023, 17:12:05@Otto, ja so ähnlich.

Das so ähnlich interessiert mich. Könntest Du das log bitte posten?


Andere Idee die ich mal habe zum Probieren:

Lege das Pidfile mal in den container

Sowas wäre dafür passend:
attr global pidfilename /tmp/fhem.pid
Und probiere es dann mal.

Grüße Sidey

Zitat von: Sidey am 18 Mai 2023, 20:21:14Das so ähnlich interessiert mich. Könntest Du das log bitte posten?

Immer diese Extawünsche... :P ;D
Kein Problem, sind angehängt.  ;)

Zitat von: Sidey am 18 Mai 2023, 20:21:14Lege das Pidfile mal in den container

Diese war schon drin, kann aber auch nichts verändern.
pidfilename is readonly, it is set in the FHEM_GLOBALATTR environment
Danke
Grüße
Gear

Zitat von: Gear am 19 Mai 2023, 08:18:27Kein Problem, sind angehängt.  ;)

Okay, ich denke ich weiss was passiert. Ich weiss aber nicht genau warum es passiert, aber das spielt keine große Rolle.

FHEM erhält aus entry.sh einen Shutdown Befehl:

SIGTERM signal received, sending "shutdown" command to FHEM!
Waiting for FHEM process to terminate before stopping container:

FHEM scheint den prinzipiell auch zu verarbeiten,
2023.05.19 07:54:53.508 2: DbLog DBLogging - Wait for last database cycle due to shutdown ...
2023.05.19 07:55:02.574 1: Server shutdown delayed due to d_rpc000008HmIP_RF,HMccu,d_rpc000008BidCos_RF,d_rpc000008VirtualDevices,DBLogging for max 10 sec

Es sieht aber so aus, als ob die Verarbeitung, bis alle delayedShutdownFNs aufgerufen zu werden, etwa 9 Sekunden dauert.
Das erkenne ich daran, dass nach 9 Sekunden der verzögerte shutdown (maximal 10 Sekunden) protokolliert wird.
Dass die 10 Sekunden hier schon abgelaufen sind, interessiert nicht, denn FHEM startet erst mit dieser Protokollierung den Timeout.

2023.05.19 07:55:02.574 1: Server shutdown delayed due to d_rpc000008HmIP_RF,HMccu,d_rpc000008BidCos_RF,d_rpc000008VirtualDevices,DBLogging for max 10 sec



Das entry.sh script sucht allerdings nach der Zeichenfolge "Server shutdown" und die findet es ja um 7:55:02 im Log und denkt, alles klar, FHEM ist beendet und ich kann ein kill senden.
  [ -n "$1" ] && grep -q "$1" <(tail -n "$LINES" "$(date +"${LOGFILE}")") && FOUND=true || FOUND=false

Ich habe das nun selbst nicht nachgestellt, aber es sieht so aus, als ob ein delayed Shutdown aktuell nicht kompatibel mit dem Docker Image ist.
Wenn ich das nachgestellt bekomme, dann kann ich es auch beheben :)

Grüße Sidey

Wenn du da noch etwas von mir brauchst, dann stehe ich gerne bereit.
Danke =D

Kurzer Zwischenstand.

Ich habe das Verhalten mit einem simplen 8 Sekunden Delay nachgestellt.

Grüße Sidey