define .. at - interessantes Verhalten

[wost]

hallo,

zuerst mal ein gruß an alle von einem neuling

ich habe folgendes interessante verhalten beim define ... at befehl vorgefunden.

wenn man z.b.  define ddd at 06:45 set bu.jalousie.1 dim 50 schreibt und nachträglich das at periodic macht, dann wird beim ändern des eintrages und einem neustart von fhem der at befehl nicht mehr angezeigt.

wenn man hingegen gleich define ddd at *06:45 set bu.jalousie.1 dim 50 schreibt, dann bleiben änderunge auch nach einem neustart erhalten.

der grund scheint zu sein, dass beim erst genannten der befehl (define) nicht in die fhem.cfg geschrieben wird, sondern nur in die fhem.save. beim neustart verschwindet dann der define befehl aus dieser datei und es bleiben nur die setstate befehle über. fhem meckert dann über das fehlende define.
wenn man den zweiten ansatz macht, wird der define befehl in die fhem.cfg geschrieben und alles ist gut.

dieses verhalten lässt sich reproduzieren und ich kann es bei bedarf näher beschreiben.
frage nun : was ist der hintergrund für dieses verhalten?

lg wost

[Otto123]

Das ist so interessant, dass es sogar jemand in die commandref geschrieben hat:

Hinweise:
wenn kein * angegeben wird, wird der Befehl nur einmal ausgeführt und der entsprechende at Eintrag danach gelöscht. In diesem Fall wird der Befehl im Statefile gespeichert (da er nicht statisch ist) und steht nicht im Config-File (siehe auch save).

Handbuchleser von Heute sind die Gewinner von Morgen. 

Gruß Otto

[wost]

das mit dem * ist mir schon klar.

ich hab aber auch geschrieben, dass ich nach dem eintrag mit define (ohne stern) im Timespec wizard das periodic angeklickt habe. und dann steht der stern sehrwohl im befehl, wird aber dann trotzdem nicht mehr in die cfg geschrieben. es scheint also so zu sein, dass der stern beim ersten mal ausschlag gebend ist. das hätte ich jetzt mal so nicht aus der doku rausgelesen.

und vielleicht hilfts ja dem einen oder anderen, der so wie ich, das nicht so rausgelesen hat.

lg wost

[franky08]

@wost
Nö, weil das schon uralt und bekannt ist.

VG
Frank

[rudolfkoenig]

wenn man z.b.  define ddd at 06:45 set bu.jalousie.1 dim 50 schreibt und nachträglich das at periodic macht, dann wird beim ändern des eintrages und einem neustart von fhem der at befehl nicht mehr angezeigt.

Das kann ich so nicht nachvollziehen, gerade getestet. Wenn man in diesem Zitat nach "befehl" den Text "in fhem.cfg" einfuegt, dann ist das klar, siehe commandref Erklaerung. Dieses Verhalten ist mAn ein Schoenheitsfehler, und bin noch nicht sicher, ob es geaendert werden muss.
Falls man nach dem Neustart "save" drueckt, dann landet die Definition wieder in der fhem.cfg.

[betateilchen]

@Rudi: Ich kann das grundsätzliche Problem des Benutzers schon nachvollziehen.

Wenn man aus einem einmaligen at ein periodisches at macht, wird das Flag "VOLATILE" in den Internals nicht gelöscht.
Dieses Internal führt dazu, dass das at auch nach der Änderung des at beim erstmaligen Speichern  wieder in der fhem.save landet.
Erst nach einem "shutdown restart" verschwindet das Flag "VOLATILE" aus dem device und ein dann ausgeführtes save schreibt das device in die Konfigurationsdatei.

Ob das wirklich nur ein "Schönheitsfehler" ist? Da bin ich mir nicht so ganz sicher.

Grundsätzlich führte eine Änderung des "Zeittyps" eines at immer zu irgendwelchen merkwürdigen Effekten, man könnte ja aus einem periodischen auch per Mausklick ein relatives at machen. Ob das wirklich Sinn macht und ob es wirklich möglich ist, jede mögliche Änderung abzufangen und gradezuziehen? Meines Erachtens ist der Aufwand dafür nicht gerechtfertigt. Es ist viel leichter und nachvollziehbarer, ein "falsch" angelegtes at einfach zu löschen und neu anzulegen.

Den at-Wizard konnte ich genau aus den daraus möglichen Problemkonstallationen, die überhaupt nicht geprüft werden, seit seiner Einführung nicht leiden 

[rudolfkoenig]

Dem Benutzer sollte bitte egal sein, wo was gespeichert wird, bei einer DB fragt er das auch nicht.

Einmal-At-Definitionen werden oefters fuer Verzoegerungen verwendet, z.Bsp. bei follow-on-for-timer wird eins automatisch angelegt, und sie sollte shutdown restart ueberleben. Wenn sie im fhem.cfg landet, dann muesste fhem.cfg bei shutdown geschrieben werden, und damit gebe es keine (einfache) Moeglichkeit fuer ein undo. Natuerlich kann man alles komplett umbauen, ist mir aber z.Zt nicht danach.

[betateilchen]

Dem Benutzer sollte bitte egal sein, wo was gespeichert wird, bei einer DB fragt er das auch nicht.

Da gebe ich Dir 100% recht. Aber Du siehst, dass es eben nicht immer egal ist.

Einmal-At-Definitionen werden oefters ...

Mir ist schon klar, wozu man welche at verwendet. Von einem vollständigen Umbau war nie die Rede (wenn auch eine komplette Überarbeitung des at-Moduls sicher nicht die schlechtestes Idee wäre).

Wenn man im Frontend das Einmal-at auf den Typ "periodic" ändert, indem man die Checkbox aktiviert und dann mit Klick auf "modify" die Änderung übernimmt, wird das vorhandene Internal "PERIODIC" von no auf yes geändert. Exakt zu dem Zeitpunkt sollte einfach das ebenfalls vorhandene INTERNAL VOLATILE gelöscht werden, dann tritt der beschriebene Effekt nicht mehr auf.

Für diese Änderung ist nur eine einzige Zeile Coding in at_Define notwendig, die niemandem wehtut:

Code Auswählen Erweitern


  $rel = "" if(!defined($rel));
  $rep = "" if(!defined($rep));
  $cnt = "" if(!defined($cnt));
+  delete $hash->{VOLATILE} if (defined($hash->{VOLATILE}));
  $hash->{RELATIVE} = ($rel ? "yes" : "no");
  $hash->{PERIODIC} = ($rep ? "yes" : "no");
  $hash->{TIMESPEC} = $tspec;
  $hash->{COMMAND} = $command;


[rudolfkoenig]

Habs eingecheckt.