(gelöst) Problem mit AT Define, der sich auf ein Reading bezieht

Begonnen von jhohmann, 28 Juli 2020, 12:27:29

Vorheriges Thema - Nächstes Thema

jhohmann

Hallo,
im Wiki zu AT gibt es ein Beispiel, bei dem für die Uhrzeit des AT ein Reading eines anderes Devices genutzt wird.
Im Beispiel ist das AT aber nur ein einmaliges, ich will das wiederkehrend einrichten, also hier mit *.
define atMarkisenPruefung at *{ReadingsVal("Tag","Markisenpruefung","")} {...}
Wenn ich das eintrage, läuft auch alles wunderbar. Bis zum Neustart von FHEM.
Da wird das define mit einer Fehlermeldung im Log bemängelt und rausgeworfen.
Hier die Meldung:
: the function "ReadingsVal("Tag","Markisenpruefung","")" must return a timespec and not <empty string>.
Ich vermute, dass mein Dummy erst später initialisiert ist als dieses Element, wobei mein Dummy Tag schon deutlich älter ist.
Aber wenn das alphabetisch aufgebaut wird, spielt das Alter vermutlich keine Rolle.
Hängt das wirklich an der Reihenfolge in der fhem.cfg?
Oder wie kann man so eine Abhängigkeit noch auflösen?
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Beta-User

Korrekt, ist (auch) ein Reihenfolgeproblem. Um es aufzulösen bzw. auch die Fehlermeldung wegzubekommen brauchst du zwei Dinge:

1. eine default-Rückgabe, die tatsächlich eine Zeit ist ("23:59") und
2. computeAfterInit (siehe commandref zu at).
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

jhohmann

Danke für die schnelle Rückmeldung.
Zwischenzeitig habe ich das mit der Namensreihenfolge ausprobiert (Name vom AT fing mit einem z an), hat aber auch nichts gebracht.
Mit der Vorgabe einer Zeit, falls leer, geht es jetzt.
In der Commandref zum computeAfterInit steht leider nicht, wie man das Attribut belegen soll.
Ich habe einfach mal eine 1 reingestellt. Ist das korrekt? Oder ist es quasi egal, wie das belegt wird, hauptsache vorhanden?

Jetzt muss ich dann nur noch probieren, was passiert, wenn die Zeit im Dummy eigentlich schon abgelaufen ist.
Eventuell baue ich mir dann was sinnvolles im notify für global:INITIALIZED
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Beta-User

Die Reihenfolge hat mit dem Namen nichts zu tun, das richtet sich streng nach dem, wie die defines in der Konfiguration stehen...

Das Problem ist aber, dass bis zum $init_done gar keine Readings bekannt sind, die werden erst danach aus der statefile gelesen, daher brauchst du den default, um den Fehler zu vermeiden. Genau deswegen gibt es das Attribut (über FHEMWEB in der Detailansicht müßte auch zu erkennen sein, welche Werte der Autor sich dafür gedacht hat; müßte ein bool-Wert sein, also 0 oder "irgendwas" mit "irgendwas"=sinnvollerweise 1).

Afaik, werden at nachgeholt, wenn die Zeit abgelaufen ist, daher auch mein Vorschlag, die Zeit auf "sehr spät" zu legen.
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

jhohmann

In der Beschreibung, die bei der Pflege des Attributs erscheint, steht leider nichts zu Wertebereich:
ZitatFalls perlfunc() im timespec Readings or Statusinformationen benögt, dann wird sie eine falsche Zeit beim FHEM-Start zurückliefern, da zu diesem Zeitpunkt die Readings noch nicht aktiv sind. Mit gesetztem computeAfterInit wird perlfunc nach Setzen aller Readings erneut ausgeführt. (Siehe Forum #56706)
Ich setze des Thema auf erledigt.
Danke für die sehr schnelle Unterstützung.
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Beta-User

Hmm, vermutlich sollte man Rudi bei Gelegenheit mal darauf hinweisen, dass da nicht nur 0/1 möglich sind... (Auch das Verhalten, dass mit einiger Sicherheit auch der Wert "0" dasselbe wie eine "1" bewirken würde, finde ich etwas ungewöhnlich - das Attribut ist wirksam, wenn es nur - wie es in der cref auch heißt - "irgendwie" gesetzt ist, also eben vorhanden :o ).
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