AT verschwunden trotz "*"

Begonnen von ralfix, 04 März 2021, 22:41:53

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Zitatweniger wie "0" geht halt nicht
Und das steht wo genau ? :)

Ich kann InitFn() einbauen, aber nur, damit ich nicht immer wieder erklaeren muss, dass es nicht hilft.

Wenn Astro gettimeofday()+5 fuer die Initialisierung verwendet, dann wird das mit InitFn nicht besser. Um die richtige Reihenfolge zu berechnen, muessten alle Instanzen (und nicht nur die Module) angeben, von welchen Anderen sie abhaengen. Das ist Konfigurations und damit Benutzer abhaengig, und kann nicht ernsthaft von einem Benutzer verlangt werden. Mit etwas "Glueck" darf man auch eine zyklische Abhaengigkeit aufloesen.

Beta-User

Habe dazu jetzt mal was in https://forum.fhem.de/index.php/topic,120603.msg1151891.html#msg1151891 geschrieben. Kann schon sein, dass ich was wichtiges übersehe...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Wolfgang Hochweller

Danke.

Zitat
Beim FHEM-Start werden erst alle Definitionen (gefolgt von den jeweiligen Attributen) abgearbeitet, und dann die alten Reading- und STATE Werte  eingelesen.

at berechnet beim define(!) die naechste Ausfuehrungszeit. Wenn die Zeit dynamisch berechnet wird und diese Berechnung einen nicht als Zeit interpretierbaren Wert zurueckliefert (wie im o.g. Beispiel, ReadingsVal default ""), dann wird at beim rereadcfg / FHEM Neustart nicht angelegt, und beim naechsten save aus fhem.cfg entfernt. Eine Fehlermeldung wird zwar an mehreren Stellen angezeigt, aber das wird gerne uebersehen.


Ich glaube, das verstehe ich : Wenn ich also ReadingsVal ohne Default verwende, und auch sonst nichts weiter angebe, verschwindet das at-Kommando moeglicherweise bei einem Neustart.
Ok, passiert mir nicht wieder.

Zitat
Konkret fuer diesen Fall
- die ReadingsVal Version mit Astro ist problematisch: Astro aktualisiert die Werte fuer at zu spaet (InternalTimer(gettimeofday()+5, ...)). Mit computeAfterInit koennte die Zeit, genommen aus dem eingelesenen Readingswert trotzdem richtig sein, wenn das FHEM-downtime nicht zu lang war.

Das verstehe ich wohl auch; die Werte sind dann aber maximal um  einen Tag verschoben, es sei denn, 'at' sollte waehrend der Downtime ausgefuehrt werden.

Zitat
- die asunset() Version muss sicherstellen, dass Astro in fhem.cfg vor dem at definiert ist.

Dafuer kann ich sorgen.