fhem-Start, Initialwert einem dummy device zuweisen [erledigt]

Begonnen von Eckat, 31 Mai 2022, 11:33:23

Vorheriges Thema - Nächstes Thema

Eckat

Hallo zusammen,

besteht die Möglichkeit einem dummy-Device beim fhem-Start einen Wert zuzuweisen?

Ich steuere mit dem dummy-Device, ob Aktionen erfolgen sollen, wenn ein Bewegungsmelder auslöst.
Beim fhem-Start hat der aber immer den Wert "???" und somit greifen die Abfragen nicht.

Bei einem at Device habe ich ein "ähnlich" gelagertes Problem mal gehabt. Dort prüfe ich auf Sonnenauf- und Sonnenuntergang im perl-Teil auf ein twilight device. Das klappte nach einem Neustart auch in der ersten Nacht nicht, bis ich das Attribut computeAfterInit auf 1 gesetzt habe. Aber das macht für einen Initialwert bei einem dummy-Device ja keinen Sinn.

Vielen Dank und viele Grüße
Carsten

Beta-User

Hmmm, wenn über den FHEM-Neustart hinaus Reading-Werte eines Gerätes verloren gehen, ist eigentlich was faul.... Der letzte Wert sollte  aus der statefile gelesen werden können.

Ansonsten gibt es viele Wege, einer wäre, eine Kopie von "initialUsbCheck" zu verwenden und die anzupassen.
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

Eckat

Sorry, habe lange gesucht und nichts gefunden.
Nach dem Erstellen vom Thread hab ich's sofort gefunden.  :-[

https://forum.fhem.de/index.php?topic=18819.0

define global_init_notify notify global:INITIALIZED|REREADCFG set xy motion

Eckat

Zitat von: Beta-User am 31 Mai 2022, 11:40:37
Hmmm, wenn über den FHEM-Neustart hinaus Reading-Werte eines Gerätes verloren gehen, ist eigentlich was faul.... Der letzte Wert sollte  aus der statefile gelesen werden können.

Ansonsten gibt es viele Wege, einer wäre, eine Kopie von "initialUsbCheck" zu verwenden und die anzupassen.
Ja, bei Readings und einem "normalen" Device. Bei dummy-Device habe ich da immer/öfter Probleme. Sollte das bei denen auch klappen?

Beta-User

#4
Zitat von: Eckat am 31 Mai 2022, 11:42:16
Bei dummy-Device habe ich da immer/öfter Probleme. Sollte das bei denen auch klappen?
An sich sollte das keinen Unterschied machen, zumindest, wenn "echte Readings" gesetzt werden (also z.B. "state" in der readingList vorhanden ist).
Ansonsten kann ich nicht viel dazu sagen, dummy kommen in meiner Installation vielleicht eine Handvoll vor; bisher hat sich meistens eine bessere Lösung für die ehemals damit "gelösten" Problemchen gefunden...

EDIT: Vielleicht "spuckt" dir deine eigene Logik (zum Umstellen des dummy) da irgendwo in die Suppe? (Falls es eine gibt)
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