Dummy Variable nach Zustandsänderung speichern (Datenverlust Stromausfall o.ä.)

Begonnen von bg1704, 11 Juli 2018, 10:07:47

Vorheriges Thema - Nächstes Thema

bg1704

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

Ellert


Felix_86

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 ;)
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

nils_

zeig doch mal bitte ein list von diesen dummy-variablen bzw. wie du deren "zustand" änderst!
viele Wege in FHEM es gibt!

Byte09

Zitat von: Felix_K am 11 Juli 2018, 11:07:01
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

Felix_86

Zitatauch 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.
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

betateilchen

Zitat von: Byte09 am 11 Juli 2018, 11:22:32
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Byte09

Zitat von: betateilchen am 11 Juli 2018, 11:54:22
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

bg1704

Zitatzeig 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.

ZitatWenn 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.

Felix_86

ZitatEine 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.
Grüße von Felix

Pi3, Raspbian 11, FHEM 6.2, ca 320 Device
SIGNALduino (TCM, TX, IT), CUL (EM, FS20, HMS), JeeLink (PCA301), HUEBridge, HUEDevice, mailcheck, echodevice, alexa, TelegramBot, Weather (OWM), DWD_OpenData, FRITZBOX, TabletUI, Calendar, Abfall, Vitoconnect, LGTV_WebOS

betateilchen

Das ist typisches Denken von Windows-Anwendern... Im Zweifelsfall erstmal STRG-ALT-ENTF drücken  8)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Ellert

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.

nils_

Zitat von: betateilchen am 12 Juli 2018, 13:33:40
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!

bg1704

ZitatDas ist typisches Denken von Windows-Anwendern... Im Zweifelsfall erstmal STRG-ALT-ENTF drücken  8)
100% richtig --> Ein Boot tut gut  ;)