MCP23017 Port Expander - Datenverlust

[Timo_FHEM]

Hallo FHEM Gemeinde,

ich habe zwei MCP23017 Portexpander, an denen meine Fensterkontakte angeschlossen sind. Letztens hatte ich einen Stromausfall (FI ausgelöst) und der FHEM Raspi wurde hart ausgeschaltet (ich weiß, als nächstes steht eine USV an...). Nach dem Neustart meldeten alle Fenster geöffnet! Ich habe dann festgestellt, dass die beiden devices in FHEM einige Attribute verloren haben. Es fehlten die Definitionen der Ein-Ausgänge und der Interupts. Ich hatte das schon mal. Da fehlte dann das IO Device.

Es gehen also Daten verloren bei einem harten Ausschalten (Stromversorgung ausgefallen). Die Frage ist: warum gehen hier Daten verloren? Die Konfiguration hab ich gespeichert. Damit müsste das doch beim Neustart wieder geladen werden, oder?

Hier ein List eines MCP Devices nach dem Stromausfall:

Code Auswählen Erweitern


Internals:
   DEF        0x21
   FUUID      5c44b208-f33f-9c22-a946-315769284f80f5b9
   I2C_Address 33
   IODev      i2cBus
   NAME       icMCP23017_21
   NR         58
   STATE      Ok
   TYPE       I2C_MCP23017
   eventCount 5
   i2cBus_SENDSTAT Ok
   Helper:
     DBLOG:
       state:
         DBLogging:
           TIME       1660591750.22446
           VALUE      Ok
   READINGS:
     2022-08-09 19:20:06   IODev           i2cBus
     2022-04-13 20:48:32   PortA0          off
     2022-04-13 20:48:32   PortA1          off
     2022-04-13 20:48:32   PortA2          off
     2022-04-13 20:48:32   PortA3          off
     2022-04-13 20:48:32   PortA4          off
     2022-04-13 20:48:32   PortA5          off
     2022-04-13 20:48:32   PortA6          off
     2022-04-13 20:48:32   PortA7          off
     2022-08-08 15:33:52   PortB0          off
     2022-08-09 19:20:06   PortB1          off
     2022-08-09 19:20:06   PortB2          off
     2022-04-13 20:48:32   PortB3          off
     2022-08-09 19:20:06   PortB4          off
     2022-04-13 20:48:32   PortB5          off
     2022-08-09 19:20:06   PortB6          off
     2022-04-13 20:48:32   PortB7          off
     2022-08-15 21:29:10   state           Ok
Attributes:
   DbLogInclude .*
   IODev      i2cBus
   alias      icMCP23017_21
   group      Portexpander MCP23017
   room       Geräte
   verbose    3


Nachdem ich die Attribute neu gesetzt habe mit:

Code Auswählen Erweitern


defmod icMCP23017_21 I2C_MCP23017 0x21
attr icMCP23017_21 DbLogInclude .*
attr icMCP23017_21 IODev i2cBus
attr icMCP23017_21 Interrupt A0,A1,A2,A3,A4,A5,A6,A7,B0,B1,B2,B3,B4,B5,B6,B7
attr icMCP23017_21 InterruptOut connected_active-low
attr icMCP23017_21 Pullup A0,A1,A2,A3,A4,A5,A6,A7,B0,B1,B2,B3,B4,B5,B6,B7
attr icMCP23017_21 group Portexpander MCP23017
attr icMCP23017_21 invert_input A0,A1,A2,A3,A4,A5,A6,A7,B0,B1,B2,B3,B4,B5,B6,B7
attr icMCP23017_21 room Geräte
attr icMCP23017_21 verbose 3


... funktioniert alles wieder. Das List sieht dann wieder so aus:

Code Auswählen Erweitern


Internals:
   DEF        0x21
   FUUID      5c44b208-f33f-9c22-a946-315769284f80f5b9
   I2C_Address 33
   IODev      i2cBus
   NAME       icMCP23017_21
   NR         58
   STATE      Ok
   TYPE       I2C_MCP23017
   eventCount 26
   i2cBus_SENDSTAT Ok
   Helper:
     DBLOG:
       PortA0:
         DBLogging:
           TIME       1660591836.4066
           VALUE      off
       PortA1:
         DBLogging:
           TIME       1660591836.4066
           VALUE      off
       PortA2:
         DBLogging:
           TIME       1660591836.4066
           VALUE      off
       PortA3:
         DBLogging:
           TIME       1660591836.4066
           VALUE      off
       PortA4:
         DBLogging:
           TIME       1660591836.4066
           VALUE      off
       PortA5:
         DBLogging:
           TIME       1660591836.4066
           VALUE      off
       PortA6:
         DBLogging:
           TIME       1660591836.4066
           VALUE      off
       PortA7:
         DBLogging:
           TIME       1660591836.4066
           VALUE      off
       PortB0:
         DBLogging:
           TIME       1660591836.08704
           VALUE      off
       PortB1:
         DBLogging:
           TIME       1660591836.08704
           VALUE      on
       PortB2:
         DBLogging:
           TIME       1660591836.08704
           VALUE      on
       PortB3:
         DBLogging:
           TIME       1660591836.08704
           VALUE      off
       PortB4:
         DBLogging:
           TIME       1660591836.08704
           VALUE      on
       PortB5:
         DBLogging:
           TIME       1660591836.08704
           VALUE      off
       PortB6:
         DBLogging:
           TIME       1660591836.08704
           VALUE      on
       PortB7:
         DBLogging:
           TIME       1660591836.08704
           VALUE      off
       state:
         DBLogging:
           TIME       1660591840.57655
           VALUE      Ok
   READINGS:
     2022-08-15 21:30:35   IODev           i2cBus
     2022-08-15 21:30:36   PortA0          off
     2022-08-15 21:30:36   PortA1          off
     2022-08-15 21:30:36   PortA2          off
     2022-08-15 21:30:36   PortA3          off
     2022-08-15 21:30:36   PortA4          off
     2022-08-15 21:30:36   PortA5          off
     2022-08-15 21:30:36   PortA6          off
     2022-08-15 21:30:36   PortA7          off
     2022-08-15 21:30:36   PortB0          off
     2022-08-15 21:30:36   PortB1          on
     2022-08-15 21:30:36   PortB2          on
     2022-08-15 21:30:36   PortB3          off
     2022-08-15 21:30:36   PortB4          on
     2022-08-15 21:30:36   PortB5          off
     2022-08-15 21:30:36   PortB6          on
     2022-08-15 21:30:36   PortB7          off
     2022-08-15 21:30:40   state           Ok
Attributes:
   DbLogInclude .*
   IODev      i2cBus
   Interrupt  A0,A1,A2,A3,A4,A5,A6,A7,B0,B1,B2,B3,B4,B5,B6,B7
   InterruptOut connected_active-low
   Pullup     A0,A1,A2,A3,A4,A5,A6,A7,B0,B1,B2,B3,B4,B5,B6,B7
   alias      icMCP23017_21
   group      Portexpander MCP23017
   invert_input A0,A1,A2,A3,A4,A5,A6,A7,B0,B1,B2,B3,B4,B5,B6,B7
   room       Geräte
   verbose    3


Kennt jemand das Problem und kann mir einen Tipp geben?
Ich bin schon versucht ein Skript zu schreiben: ... wenn alle Fenster offen anzeigen: definiere die beiden devices neu.
Das kanns ja aber nicht sein...

Jemand eine Idee?

Danke und Gruß Timo

[rudolfkoenig]

Ich kann zu diesem Problem nichts konkret sagen, nur Grundsaetzliches schreiben, damit darueber keine Unsicherheit gibt:

- FHEM speichert von sich aus weder Definitionsaenderungen (define bzw. attr) noch Zustandsaenderungen (Readings, Internals), Ausnahme ist autocreate, s.u.

- mit dem save Kommando werden alle aktiven Definitionen in fhem.cfg geschrieben, und die Readings in log/fhem.save. Mit configDB landet beides in der Datenbank. Aktiv heisst, dass beim FHEM-Start das define/attr keinen Fehler verursacht hat, diese Anweisungen gehen beim save verloren. Die Fehler stehen in der global init_errors Attribut, was beim FHEMWEB oder telnet Aufruf angezeigt wird.

- falls autocreate aktiv ist, und was Neues anlegt, dann  wird automatisch ein save ausgeloest, es sei denn, beim FHEM-Start wurden Fehler festgestellt, s.o.

Dass beim harten Ausschalten des Rechners Dateien kaputtgehen, ist nicht unerhoert.
Bei Filesystemen mit logging (ext4, xfs, btrfs, etc) sollte die Datei nicht mehr kaputt sein, stattdessen wird eine aeltere Version aktiv.
Natuerlich nur dann, wenn die Daten vom Log es nicht mehr in die Datei geschafft haben.

[Timo_FHEM]

Hallo,

irgendwie lädt FHEM bei einem Neustart (shutdown restart) nicht die richtige fhem.cfg. Ich habe Gestern überprüft, dass die Attribute zu den Devices in der Datei stehen. Heute hab ich ein shutdown restart gemacht und die Attribute sind weg.
Interessanterweise sind die Attribute weg, aber die Statusänderungen funktionieren trotzdem?! Wenn ich also ein Fenster schließe, wird das reading korrekt gesetzt.
Wenn ich jetzt den Rechner komplett neu starte sind vermutlich wieder alle Fenster offen (mach ich jetzt nicht).
Ich hab auch öfter das Problem mit dem cannot fork, cannot allocate Memory. Dann greift ein notify und macht einen shutdown restart. Danach sind vermutlich auch die Attribute weg.

Wie kann ich dem Problem auf den Grund gehen?

Danke und Gruß Timo

[Timo_FHEM]

... Aktiv heisst, dass beim FHEM-Start das define/attr keinen Fehler verursacht hat, diese Anweisungen gehen beim save verloren. Die Fehler stehen in der global init_errors Attribut, was beim FHEMWEB oder telnet Aufruf angezeigt wird.

Hier liegt dann wohl mein Problem. Ich hatte das nie gesehen, weil motd auf none stand und damit die Meldungen beim Start nicht kamen. Jetzt kommt:

Code Auswählen Erweitern

Messages collected while initializing FHEM:configfile: no IODev assigned to 'icMCP23017_20'
no IODev assigned to 'icMCP23017_20'
no IODev assigned to 'icMCP23017_20'
no IODev assigned to 'icMCP23017_20'
no IODev assigned to 'icMCP23017_20'
no IODev assigned to 'icMCP23017_21'
no IODev assigned to 'icMCP23017_21'
no IODev assigned to 'icMCP23017_21'
no IODev assigned to 'icMCP23017_21'

Autosave deactivated

Allerdings ist das IODev bei den beiden Devices gesetzt. Wie bekomme ich die Fehlermeldung aus dem global init_errors wieder raus?

Danke und Gruß Timo

[Gisbert]

Ich hab auch öfter das Problem mit dem cannot fork, cannot allocate Memory.

Könnte das ein Problem mit zu wenig Speicher auf der SD-Karte sein, oder einen sich anbahnenden Defekt selbiger?

Das folgende ist zwar offtopic, geht aber vom Problem her in die gleiche Richtung. Nach einem Neustart hab ich bei einem Device ein Attribut "disable", was dieses Device aber nicht hat (es hat ein Attribut "disabled"). Ich lösche das erstere Attribut, mache ein Fhem save - und nach einem Neustart ist es wieder da, wie ein Zombie, der nicht sterben kann.

Viele​ Grüße​ Gisbert​

[Timo_FHEM]

Könnte das ein Problem mit zu wenig Speicher auf der SD-Karte sein, oder einen sich anbahnenden Defekt selbiger?

Das folgende ist zwar offtopic, geht aber vom Problem her in die gleiche Richtung. Nach einem Neustart hab ich bei einem Device ein Attribut "disable", was dieses Device aber nicht hat (es hat ein Attribut "disabled"). Ich lösche das erstere Attribut, mache ein Fhem save - und nach einem Neustart ist es wieder da, wie ein Zombie, der nicht sterben kann.

Viele​ Grüße​ Gisbert​

Auf der SD Karte sind 8,5 GB Platz frei. Platzmangel ist es eher nicht.

Ich denke das "cannot fork..." ist ein ganz anderes und noch viel seltsameres Problem. Dazu gibt es ja einen anderen langen thread. Bei mir kommt das von Zeit zu Zeit. Dann tritt das öfter am Tag auf und ist dann plötzlich wieder verschwunden obwohl am System nichts verändert wurde. Hab mich schon fast dran gewöhnt

Nur dass dann dabei durch den Neustart mein anderes Problem auftritt stört schon.

[LuckyDay]

ist dein i2cBus device auch vor dem icMCP23017_21 device  -> in der fhem.cfg definiert?
sprich die Reihenfolge

[rudolfkoenig]

ist dein i2cBus device auch vor dem icMCP23017_21 device  -> in der fhem.cfg definiert?

Im Normalfall sollte das irrelevant sein, da das FHEM Framework nach Einlesen der fhem.cfg die IODev Zuweisung erneut versucht.

FHEM/52_I2C_MCP23017.pm verwendet das Framework fuer die Zuweisung, allerdings ist das Attribut IODev mAn wirkungslos, da das Testen auf init_done beim Start die Zuweisung verhindert.
Das ist dann relevant, falls mehrere IO-Geraete vorhanden sind, und Reihenfolge der Geraete ungluecklich ist.

[Timo_FHEM]

ist dein i2cBus device auch vor dem icMCP23017_21 device  -> in der fhem.cfg definiert?
sprich die Reihenfolge

Das ist definitiv nicht so! Das i2cBus device ist viel weiter hinten definiert. Ich habe das jetzt in der fhem.cfg vor den beiden icMCP23017 devices definiert. Der erste Test sah schon mal ganz gut aus. Ich werde das weiter beobachten und morgen noch mal ein restart machen. Vielleicht ist das die Lösung. Danke schon mal für den Tipp.

Gruß Timo

[Timo_FHEM]

Der Tipp mit der Reihenfolge hat gewirkt. Bislang keine Probleme mehr trotz mehrmaligem Neustart.

Danke!
Gruß Timo