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:
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:
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:
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
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.
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
Zitat von: rudolfkoenig am 16 August 2022, 09:29:09
... 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:
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 deactivatedAllerdings ist das IODev bei den beiden Devices gesetzt. Wie bekomme ich die Fehlermeldung aus dem global init_errors wieder raus?
Danke und Gruß Timo
ZitatIch 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 "disable
d"). 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
Zitat von: Gisbert am 21 August 2022, 19:09:22
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.
ist dein i2cBus device auch vor dem icMCP23017_21 device -> in der fhem.cfg definiert?
sprich die Reihenfolge
Zitatist 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.
Zitat von: fhem-hm-knecht am 21 August 2022, 19:24:57
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
Der Tipp mit der Reihenfolge hat gewirkt. Bislang keine Probleme mehr trotz mehrmaligem Neustart.
Danke!
Gruß Timo