Autor Thema: Dummy Variable nach Zustandsänderung speichern (Datenverlust Stromausfall o.ä.)  (Gelesen 364 mal)

Offline bg1704

  • New Member
  • *
  • Beiträge: 40
Hallo zusammen,

ich habe mehrere Dummy-Variablen und habe festgestellt wenn ich den Zustand ändere und den Raspi stromlos schalte sind die Zustände wie beim letzten "save config" und somit nicht aktuell.
Ich möchte also "save config" automatisch ausführen nach Änderung des Zustands der Dummy-Variable.

Kann mir jemand einen Tipp geben wie ich das umsetzen kann? Danke vorab für die Unterstützung.

define El_Rol_GruppeWest_Auto dummy
attr El_Rol_GruppeWest_Auto cmdIcon AutoOn:ios-on-green AutoOff:ios-off
attr El_Rol_GruppeWest_Auto devStateIcon AutoOn:time_automatic@green AutoOff:time_manual_mode@gray
attr El_Rol_GruppeWest_Auto webCmd AutoOn:AutoOff
Raspberry Pi v2 Model B
CULV3 (MAX!) / hm-usb-cfg-2 (HM) / Elero Transmitter Stick

Online Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3202
Führe den Befehl save über ein DOIF o. notify aus.

Offline Felix_K

  • New Member
  • *
  • Beiträge: 48
    • https://puresec.de
Wird der normale Dummy-Status nicht in der fhem.save hinterlegt anstelle der Config?
Werden bei dir Attribute als Variablen geändert?

Bisher setze ich ein save nur ein, wenn
- Attribute geändert werden
- Device disabled (0|1) gesetz wird
- modifyTimeSpec bei AT's geändert wird


btw:
Den Raspi auf stromlos schalten durch Stromkabel ziehen kann auf Dauer Probleme mit dem Dateisystem und Betriebssystem führen.
Über einen ordentlichen Reboot freut sich das System ;)
Mit freundlichen Grüßen,
Felix_K

Offline nils_

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 924
zeig doch mal bitte ein list von diesen dummy-variablen bzw. wie du deren "zustand" änderst!
viele Wege in FHEM es gibt!

Online Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 896
Den Raspi auf stromlos schalten durch Stromkabel ziehen kann auf Dauer Probleme mit dem Dateisystem und Betriebssystem führen.
Über einen ordentlichen Reboot freut sich das System ;)

Den Raspi auf stromlos schalten durch Stromkabel ziehen kann wird auf Dauer Probleme mit dem Dateisystem und Betriebssystem führen.
Über einen ordentlichen Reboot freut sich das System ;)

@bg1704

das 'save' wird doch beim ordnungsgemässen herunterfahren des servers ausgeführt ?! 
die readings/states werden doch beim ordnungsgemässen herunterfahren des servers gespeichert ?!
ist das dein 'Standartoff' , einfach den Stecker zu ziehen ? das solltest du , wie oben geschrieben , tunlichst vermeiden !

auch das 'save' bei jeder statusänderung des/der dummy(s) würde ich dringend vermeiden , geht aufgrund der erhöhten Schreibtätigkeit auf dauer zu Lasten der SD-Karte.

ansonsten wurde ja schon geschrieben , wie es geht - falls unvermeidbar.

gruss Byte09
« Letzte Änderung: 11 Juli 2018, 12:08:06 von Byte09 »
Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

Offline Felix_K

  • New Member
  • *
  • Beiträge: 48
    • https://puresec.de
Zitat
auch das 'save' bei jeder statusänderung des/der dummy(s) würde ich dringend vermeiden , geht aufgrund der erhöhten Schreibtätigkeit auf dauer zu Lasten der SD-Karte.
Ich habe mir dazu seinerzeit das FHEM init-Script erweitert und die häufig geschriebenen Dateien (fhem.cfg, fhem.save usw) verschoben, um einen neuen Speicherbereich zu verwenden. Das verzögert immerhin den Totalausfall einer SD um einige Monate.
Mit freundlichen Grüßen,
Felix_K

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15220
  • s/fhem\.cfg/configDB/g
das 'save' wird doch beim ordnungsgemässen herunterfahren des servers ausgeführt ?! 

wie kommst Du auf diese (absurde) Idee? Das tut FHEM glücklicherweise nicht.

Wenn es nur darum geht, geänderte Werte in readings zu speichern, reicht es, das statefile neu zu schreiben, dafür muss nicht die gesamte Konfiguration gesichert werden.

define a_writestates at +*01:00 {WriteStatefile}
attr a_writestates alignTime 00:01

schreibt beispielsweise einmal pro Stunde alle readings in das statefile.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr

Online Byte09

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 896
wie kommst Du auf diese (absurde) Idee? Das tut FHEM glücklicherweise nicht.

in der tat war diese aussage etwas ... wie du sagst ... absurd. sry, war etwas lapidar dahergeschrieben !

selbstverständlich meinte ich das speichern der states.

gruss Byte09
Fhem 5.7, 3*RPi2, Harmony, Hyperion, HM-CFG-LAN, Signalduino, SignalESP, NanoCul
MAINTAINER: 98_Siro, 98_MSwitch

Offline bg1704

  • New Member
  • *
  • Beiträge: 40
Zitat
zeig doch mal bitte ein list von diesen dummy-variablen bzw. wie du deren "zustand" änderst!
Die Dummy-Variable wird über Floorplan geändert. Es handelt sich um eine selbst gebaute Automatik/Hand Umschaltung. Diese wird zwar selten genutzt, aber der Zustand sollte trotzdem gespeichert werden, damit nicht versehentlich falsche Aktionen nach einem Stromausfall laufen.
Daher reicht mir eigentlich eine Speicherung 1x täglich.

Zitat
Wenn es nur darum geht, geänderte Werte in readings zu speichern, reicht es, das statefile neu zu schreiben, dafür muss nicht die gesamte Konfiguration gesichert werden.

Code: [Auswählen]
define a_writestates at +*01:00 {WriteStatefile}
attr a_writestates alignTime 00:01

schreibt beispielsweise einmal pro Stunde alle readings in das statefile.

Ich werde es wohl so umsetzen mit 24 Stunden Zyklus. Eine kurze Einschätzung bitte von Euch: Wäre es in meinem Fall vielleicht sinnvoller einen automatischen Neustart alle 24 Stunden anzustoßen. GGf. hat solch ein Neustart auch weitere Vorteile (z.B. Performance o.ä.).
Ansonsten würde ich es über WriteStatefile umsetzen.

Danke schonmal für Eure tolle und schnelle Unterstützung.
Raspberry Pi v2 Model B
CULV3 (MAX!) / hm-usb-cfg-2 (HM) / Elero Transmitter Stick

Offline Felix_K

  • New Member
  • *
  • Beiträge: 48
    • https://puresec.de
Zitat
Eine kurze Einschätzung bitte von Euch: Wäre es in meinem Fall vielleicht sinnvoller einen automatischen Neustart alle 24 Stunden anzustoßen. GGf. hat solch ein Neustart auch weitere Vorteile (z.B. Performance o.ä.).
Was soll denn der Hauptvorteil des Neustarts sein, wenn z.B. Performance nur ein weiterer Vorteil ist?

Ich habe bei einem Raspberry keine Vorteile in der Performance nach einem Neustart erkannt, sofern nicht ein hängender Prozess oder ähnliches Ursache für schlechte Performance war. Viel häufiger kam es vor, dass nach einem Neustart nicht alles richtig lief. Daher habe ich Neustarts seinerzeit vermieden, soweit möglich.
Mit freundlichen Grüßen,
Felix_K

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15220
  • s/fhem\.cfg/configDB/g
Das ist typisches Denken von Windows-Anwendern... Im Zweifelsfall erstmal STRG-ALT-ENTF drücken  8)
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.12.2018 - 18:30 Uhr
Gefällt mir Gefällt mir x 1 Liste anzeigen

Online Ellert

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3202
Eine Alternative zu WriteStatefile wäre, den Dummy Status per setKeyValue bei jeder Änderung zu speichern und bei global:INITIALIZED über getKeyValue einzulesen und den Dummy über set zu setzen, dann wäre die geschriebene Datenmenge geringer.

Offline nils_

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 924
Das ist typisches Denken von Windows-Anwendern... Im Zweifelsfall erstmal STRG-ALT-ENTF drücken  8)

deswegen ist keine tastatur an meinem pi :)
nicht das irgendwer auf die idee kommt sowas zu machen....


ich starte den pi eigentlich nie neu.
viele Wege in FHEM es gibt!

Offline bg1704

  • New Member
  • *
  • Beiträge: 40
Zitat
Das ist typisches Denken von Windows-Anwendern... Im Zweifelsfall erstmal STRG-ALT-ENTF drücken  8)
100% richtig --> Ein Boot tut gut  ;)
Raspberry Pi v2 Model B
CULV3 (MAX!) / hm-usb-cfg-2 (HM) / Elero Transmitter Stick