fhem config speichern via command

Begonnen von Oliver1985, 03 Juni 2021, 22:32:11

Vorheriges Thema - Nächstes Thema

Oliver1985

Guten Abend zusammen.

Ich habe soeben festgestellt, dass mein dilettantischer Versuch die fhem config automatisiert zu speichern seit Wochen fehlschlägt.

Dabei habe ich naiv in einem notify folgendes versucht:
fhem "save";

Auch wenn ich den Grund gerade nicht verstehe, nehme ich dennoch an, dass das nicht-funktionieren by-design ist. Daher meine Frage: Gibt es irgendeine Möglichkeit die Konfigurationsdatei via Kommando in einem at/notify zu sichern?

VG, Oliver

MadMax-FHEM

Mal abgesehen davon, dass automatisches Speichern nicht unbedingt zu empfehlen ist aber dein Problem liegt verm. daran: attr global autosave 0 -> attr global autosave 1

https://forum.fhem.de/index.php/topic,114091.msg1083505.html#msg1083505

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

betateilchen

Zitat von: Oliver1985 am 03 Juni 2021, 22:32:11
Ich habe soeben festgestellt, dass mein dilettantischer Versuch die fhem config automatisiert zu speichern

Warum um alles in der Welt will man sowas tun?

Zitat von: Oliver1985 am 03 Juni 2021, 22:32:11
Dabei habe ich naiv in einem notify folgendes versucht:
fhem "save";

Warum schreibst Du vor einen FHEM Befehl extra noch einen Funktionsaufruf von fhem() ? Das ist komplett überflüssig.

define n_save notify <regexp> save

Zitat von: MadMax-FHEM am 04 Juni 2021, 02:10:25
Mal abgesehen davon, dass automatisches Speichern nicht unbedingt zu empfehlen ist

*unterschreib*
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Oliver1985

Danke für eure Antworten.
"Man" möchte das tun, um den aktuellen Zustand des Systems abzuspeichern, bevor man dieses Neustartet.
+*12:00:00 {
my $count = 0;
my $SELF = "PushSystemError_Din";
foreach my $ars (devspec2array("TYPE=XiaomiBTLESens")){
if (Value($ars) =~ m/error/){
$count++
}
}
if ($count > 3){
if (InternalVal("PushSystemError_Liv","TIMESPEC","") ne "00:00:30"){
fhem "set $SELF modifyTimeSpec 00:00:30";
fhem "save";
fhem "define DelayedReboot at +00:00:10 { system\(\"sudo reboot \&\"\) }";
}else{
fhem "attr $SELF comment $count";
}
}else{
if (InternalVal($SELF,"TIMESPEC","") ne "01:00:00"){
fhem "set $SELF modifyTimeSpec 01:00:00";
fhem "save";
}
fhem "attr $SELF comment ok";
}
}


Die Idee ist, dass die Ausführung von modifyTimeSpec gesichert wird und nach dem Neustartet prüft das System dann direkt nach 30 Sekunden, ob das Problem behoben ist und nicht erst wieder nach 12 Stunden. Natürlich könnte ich die at-Zeit allgemein auf 30 Sekunden belassen jedoch soll der Reboot-Befehl nur ein einiges Mal ausgeführt werden. Ist das Problem dadurch nicht behoben, möchte ich darüber in Kenntnis gesetzt werden, damit ich mir dieses ansehen kann. Es handelt sich um FHEM2FHEM Embeeded-Systems, die nur der Server VM die Sensordaten übermitteln. Ich würde sonst ebenfalls von einem automatisierten Save-Befehl absehen. Allerdings hängen sich diese Systeme immer wieder mal auf. (hci tool I/O error).

@betateilchen: Danke für den Hinweis. Mit dem global Attribut funktioniert es nun.