Featurewunsch: save <devspec> - oder alternative Lösung gesucht

[Thomas_Homepilot]

Hallo,

aktuell aktiviere ich bei Abwesenheit einen ganzen Haufen von at- und notify-devices über das disable-attribut. Da diese auch nach einem eventuellen Stromausfall noch ihren aktuellen Wert haben sollen speicher ich die Konfiguration direkt mit "save". Nun passiert es aber des Öfteren, dass ich gerade etwas von unterwegs ausprobiere und dann meine Frau das Haus verlässt. In dem Moment werden dann auch meine temporären Änderungen in die Konfiguration übernommen. Schön wäre also eine Möglichkeit, nur bestimmte devices mit "save" zu sichern.
Alternativ könnte ich in den ganzen "at"s und "notify"s den Dummy "presence" abfragen. Hierzu würde aber immer jedes der ca. 50 "at"s und "notify"s ausgeführt, obwohl es unnötig ist. Wird mir das evtl. mein FHEM blocken oder sind die beiden Methoden sowieso gleichwertig?
Gibt es evtl. noch eine bessere Lösung?

Gruß
Thomas

[rudolfkoenig]

Ich glaube nicht, dass wenn man nur die Haelfte der Konfiguration speichert (und die andere Haelfte fuers nimmerwiedersehen weg ist), die Anwender zufrieden sind

[marvin78]

Ich bin der Meinung, dass man "etwas ausprobieren" nicht von unterwegs machen und/oder man ein Testsystem für so etwas haben sollte. Es sei denn, man hat FHEM nur zum Spielen und dann ist es auch wieder egal.

[Thomas_Homepilot]

@Rudi: Danke für die Antwort, aber warum ist die andere Hälfte denn für immer weg? Die könnte ich doch bei Bedarf  mit dem normalen "save" ohne <devspec> sichern.

Gruß
Thomas

[rudolfkoenig]

Weil save dann ja nur die eine Haelfte (alles was markiert war) in die Datei schreibt. Da fhem.cfg immer komplett geschrieben wird, geht die andere Haelfte verloren.

Du willst vmtl. folgendes: FHEM soll fhem.cfg erneut reinlesen (aber nicht interpretieren), die im Hauptspeicher markierten Geraete aus diesen eingelesenen Daten entfernen, die markierten Geraete samt Attribut aus dem Hauptspeicher dazupacken, und diese Daten speichern. Viel Aufwand fuer irgendetwas, was hoechstens von Profis fuer Spezialfaelle benoetigt wird.
Ich habs z.Bsp. immer noch nicht kapiert, wozu es gut sein soll.

Falls du irgendetwas gar nicht speichern willst, dann solltest du $defs{NAME}{TEMPORARY} setzen.

[betateilchen]

Viel Aufwand fuer irgendetwas, was hoechstens von Profis fuer Spezialfaelle benoetigt wird.

Und für solche Spezialfälle nimmt man besser die configDB, denn da gibt es immer mehrere Versionen der Konfiguration, sodass man jederzeit einen "vorherigen" Zustand wiederherstellen kann.

[rudolfkoenig]

Die in configDb automatisch erstellten Versionen wuerden in diesem Fall nicht helfen, save myExperiment.cfg; rereadcfg myExperiment.cfg geht auch ohne configDb. Das Problem ist, dass er manches nicht, anderes aber doch speichern will.

[karl0123]

Eine konsequent durchgezogene Konfigurationsdatenbank (und keine Datenbank, in der die Zeilen der Config und anderer Dateien in jeweils einer Tabelle einfach nur zeilenweise abgelegt werden), würde hier schon helfen. Man wäre deutlich flexibler. Mir ist jedoch bewusst, dass dafür viel am Grundkonzept geändert werden müsste.

[Thomas_Homepilot]

Ok. Ich bin überzeugt  .
Vielleicht war der Wunsch wirklich etwas zu speziell.
Eine andere Möglichkeit, mein Problem zu lösen, wäre es, alternativ zum disable-Attribut ein "set xxx disabled" für at und notify zu ermöglichen. Dieser state könnte gleichwertig zum Attribut behandelt werden. Der Unterschied wäre, dass über den set-Befehl der state bei Bedarf im statefile landen würde, dass Attribut in der Config. Somit wäre auch das Thema mit dem roten Fragezeichen http://forum.fhem.de/index.php/topic,33937.msg262805.html#msg262805 erledigt und das kürzlich eingeführte event für das disable-attribut könnte so auf das "set xxx disabled" beschränkt werden und der Wechsel des Attributs müsste evtl. dann kein Event auslösen.

Gruß Thomas

[betateilchen]

*dagegen*

Ob ein device "disabled" ist, ist eindeutig ein Attribut des devices und kein Zustand. Und das soll bitte auch so bleiben.

Da wäre ich lieber noch für ein Attribut "dontsave".

[Thomas_Homepilot]

Das kommt auf die Sichtweise an. So wie ich die notifys und ats nutze kann man das durchaus auch als state ansehen und ich will ja auch das Attribut nicht ersetzen sondern ergänzen. Selbstverständlich ist es in anderen Anwendungsfällen ein Attribut, aber wenn man liest, dass einige sich bei diesem Attribut über das rote Fragezeichen wundern so bin ich mit meiner Sichtweise eindeutig nicht allein.

Gruß
Thomas

[Markus Bloch]

ein Attribut "dontsave" würde ich ebenfalls begrüßen, welches dann $defs{"NAME"}{TEMPORARY} = 1 setzt. Damit kann man sowas wie temporär definierte notify's oder ähnliches (ja, user machen sowas) explizit von der speicherung (und auch der Änderungserkennung) aussschließen.

[betateilchen]

ich hab da mal was vorbereitet...

fhem.pl ab Zeile 2259

Code Auswählen Erweitern



    if($attrName eq 'dontsave') {
       if($a[2] eq '1') {
          $defs{$a[0]}{TEMPORARY}  = 1;
       } else {
          delete $defs{$a[0]}{TEMPORARY} if defined($defs{$a[0]}{TEMPORARY});
       }       
    }



[Thomas_Homepilot]

... Das hat aber eigentlich nichts mit meinem Anliegen zu tun...

Gruß
Thomas

[Thomas_Homepilot]

...da das Thema disable als state oder Attribut nichts mit dem ursprünglichen Thema zu tun hat, werde ich ein neues Thema eröffnen:
http://forum.fhem.de/index.php/topic,34603.0.html

Gruß
Thomas