[Nachgefragt] notify soll 3 sec warten

Begonnen von grappa24, 24 Januar 2015, 16:09:14

Vorheriges Thema - Nächstes Thema

grappa24

ug_garagentor_oeffner { at +00:00:03 setstate ug_garagentor_oeffner off }

was mach ich falsch?

Das Icon für den Öffner soll nach drei Sekunden wieder auf "off" gehen ....
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

rudolfkoenig

Zitatwas mach ich falsch?

Nicht bei den Anfaengern Fragen...

1. es gibt kein perl at Befehl, siehe {}
2. es gibt auch kein FHEM at befehl, es heisst "define myAt at +00:00:03..."
3. setstate setzt zwar STATE, loest aber keinerlei Aktionen aus.

Folgendes koennte funktionieren:
define myNtfy notify ug_garagentor_oeffner sleep 3;; setstate ug_garagentor_oeffner off;; trigger ug_garagentor_oeffner off

Falls das ein FS20 Geraet ist, dann reicht ein follow-on-for-timer zu setzen.

grappa24

Danke Rudolf, Dein Vorschlag für das notify hat funktioniert.

Es handelt sich um den FS20 AS-1-2, einen funkgesteuerten Schalter mit eingebautem Timer, den ich mit dem notify jetzt nachgebildet habe. 
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

grappa24

#3
so gehts (auch) ug_garagentor_oeffner define myAt at +00:00:03 setstate ug_garagentor_oeffner off;;trigger ug_garagentor_oeffner


Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

grappa24

Das define im notity führt zur Meldung "myAT already defined, delete it first". Kann man das verhindern bzw. ohne define ein "temporäres" at im notify erzeugen?
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

rudolfkoenig

Ich kann nur empfehlen, meine Beitraege komplett zu lesen.

grappa24

Rudolf, das hab ich schon und weiß, dass es kein FHEM at gibt; hätte ja sein können, dass man die o.a. Fehlermeldung verhindern kann.

Die Lösung mit "at +00:00:03" funktioniert übrigens meiner Erfahrung nach zuverlässiger (verzögert exakt 3s) als die Lösung mit "sleep 3" (verzögert mal mehr, mal weniger ...).

Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

rudolfkoenig

Diese Beobachtung ist aber subjektiv, da beide (at und sleep) den gleichen Mechanismus verwenden.

Und folgendes habe ich nicht verstanden:
Zitatweiß, dass es kein FHEM at gibt