Sensor als UserReading in einen Actor eingebaut -> Verzögerung

[grappa24]

Ich hab einen HMS Sensor (ug_garagentor) und einen Shelly1 als Aktor (ug_garagentor_oeffner).
Ziel war ein Icon zu haben, was sowohl als Aktor fungiert als auch den Zustand anzeigt.

Den Sensor hab ich als UserReading in den Aktor eingebaut:

Code Auswählen Erweitern

attr ug garagentor_oeffner userReadings ug_garagentor_sensor {if(ReadingsVal("ug_garagentor","switch_detect","") eq "off") {return "geschlossen"} else {return "offen"}}
attr ug_garagentor_oeffner stateFormat ug_garagentor_sensor
attr devStateIcon .*offen:garage_offen:on .*geschlossen:garage_geschlossen:on

Frage: Während der Sensor selbst "sofort" den Statuswechsel anzeigt reagiert das "devStateIcon" mit einer Verzögerung von 3-4 Sekunden. Kann man diese Verzögerung eliminieren?

P.S. Der shelly läuft im Auto-Modus und schaltet sich jeweils bei "on" nach 2 Sekunden ab, d.h. ich starte den Öffnen- bzw. Schließen-Vorgang jeweils mit 2 Sekunden Power auf meinen Garagenantrieb

[MadMax-FHEM]

Das userReadings bei DeviceA wird nur aktualisiert, wenn ein passender Event bei DeviceA kommt!

(du hast keinen Trigger, daher aktualisiert JEDES Event bei DeviceA aber eben nur Events bei DeviceA)

D.h. du machst etwas bzw. beim Sensor (DeviceB) "passiert" etwas.

Dann kommt irgendwann (glücklicherweise) ein Event bei DeviceA und das userReadings wird aktualisiert mit dem Wert aus DeviceB.

D.h. dass es "nur" 2-3 Sekunden Verzögerung sind ist reiner Zufall (oder es passiert halt auch immer nach 2-3 Sekunden in DeviceA etwas), es könnten auch Tage oder Wochen sein
(je nachdem wie viele Events in DeviceA kommen)

Besser wäre ein notify, das eben auf DeviceB lauscht und dann sofort den Wert bei DeviceA setzt: setreading DeviceA Reading Wert

(oder, aber "böse": ein userReadings MIT TRIGGER! bei DeviceB, das dann ein: sleep 0.1; setreading DeviceA Reading Wert; ausführt. Der sleep, weil setreading in einem userReadings verhindert/verzögert wird/würde, zumindest meine Erfahrung)

Gruß, Joachim

[Otto123]

Hi,

btw: der Code ist komplett fake  bitte echte Copy & Paste posten

attr ug garagentor_oeffner
attr ug_garagentor_oeffner
attr devStateIcon

Warum kommt es bei Dir zur Verzögerung? Weil dein Device das userReadings triggert aber nicht das Device welches abgefragt wird. Dein shelly triggert ev. alle 3-4 Sekunden, das wird eine Art polling

ja: Wirkungsrichtung umkehren (nicht getestet und nochmal geändert: Danke Joachim):

Code Auswählen Erweitern

attr ug_garagentor userReadings ug_garagentor_sensor:switch_detect.* { fhem("setreading ug_garagentor_oeffner ug_garagentor_sensor {(ReadingsVal($name,'switch_detect','') eq 'off'?'geschlossen':'offen')} ") }
Ich glaube das geht ohne sleep - böse ist das eigentlich nicht.

Gruß Otto

[Beta-User]

...hatten wir dafür nicht irgendwo einen "speziellen" readingsProxy?...

Ansonsten sind userReadings ohne trigger (na ja)....

[MadMax-FHEM]

Ist setreading nicht ein fhem-Befehl?

Müsste dann nicht {fhem("setreading...")}  ?

Oder die geschweifte Klammer vor setreading weg?
Wobei ich dann wieder nicht weiß ob man fhem und Perl "innerhalb" von setreading mischen kann...

EDIT: und fehlt nicht beim setreading der Readingname? setreading Devicename Readingname Wert

So geht es auf jeden Fall:

Code Auswählen Erweitern


transferStaus:switch_detect.* {my $value=ReadingsVal($name,"switch_detect","n.a.") eq "off" ? "geschlossen":"offen";fhem("sleep 0.1; setreading ug_garagentor_oeffner switch_detect $value");return "done"}

(wobei das mit dem Fragezeichenoperator nicht getestet ist, den Rest habe ich so mal bei mir)

Dann steht auf der Seite des Sensors im "neuen" transferStatus "done" wenn immer eine Aktualisierung passiert ist und im anderen Device ug_garagentor_oeffner der übertragene Status...

Gruß, Joachim

[grappa24]

Ihr seid schon Spitze, vielen Dank.

Mit dem "transferStatus" klappt es jetzt ohne Verzögerung

Schönes Wochenende
Dieter

P.S. D. h. aber auch, dass ich mir mein userReading

Code Auswählen Erweitern

attr ug_garagentor_oeffner userReadings ug_garagentor_sensor {if(ReadingsVal("ug_garagentor","switch_detect","") eq "off") {return "geschlossen"} else {return "offen"}}

sparen kann, weil dessen Rolle jetzt vom switch_detect im ug_garagentor_oeffner übernommen wird?

[Otto123]

ja 

[grappa24]

Code Auswählen Erweitern


transferStaus:switch_detect.* {my $value=ReadingsVal($name,"switch_detect","n.a.") eq "off" ? "geschlossen":"offen";fhem("sleep 0.1; setreading ug_garagentor_oeffner switch_detect $value");return "done"}


Das ist ja ein UserReading mit Trigger, soweit verstanden. Was passiert denn aber, wenn im System noch andere Devices mit Reading "switch_detect" sind?

[Otto123]

userReadings werden nur vom eigenem Device getriggert. mit der Angabe des Readings wird aber nur bei Änderung dieses Readings getriggert.

[MadMax-FHEM]

Jep, so wie hier schon geschrieben: https://forum.fhem.de/index.php/topic,128492.msg1228989.html#msg1228989

notify lauscht global, ein userReadings nur lokal bei Events des Devices wo es dranhängt...

Gruß, Joachim