POWR2 - On-for-timer nur einmal wirksam

Begonnen von rokatz123, 25 Dezember 2019, 12:17:35

Vorheriges Thema - Nächstes Thema

rokatz123

Hallo, ich habe einen POW R2 als MQTT2 Device angelegt und dieser funktioniert inkl. Readings. Er soll einen Handtuchheizkörper steuern und den Energieverbrauch mit loggen. Ich möchte außerdem, dass er nach manuellem Einschalten für 30 Minuten ON ist und dann auf OFF geht. Und das dauerhaft. Wenn ich mit set 'device' on-fo-timer 10 einschalte, funktioniert das auch, der POW schaltet nach 10s ab. Wenn ich ihn danach über ON schalte bleibt er dauerhaft an. Wie kann ich einen Timer realisieren, der nach jedem ON nach Ablauf einer Zeit wieder abschaltet? Danke, Robert

TomLee

Vorausgesetzt du nutzt Tasmota würd ich das mit Regeln im Tasmota Device umsetzen. Egal von wo du schaltest, am Gerät oder aus Fhem oder sonstwie, bei einem on -Befehl geht der Kanal nur noch für die in der Regel programmierte Zeit an.

Schau dir einfach auch mal die vielen Beispiele an.

Gruß

Thomas

Beta-User

Hatten wir das nicht bei der Diskussion über on-for-timer @tasmota, dass manche backlog-Vorgaben dauerhaft wirken? Das könnte hier hilfreich sein...
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

TomLee

Wozu die Arbeit machen den On-Befehl (der TE mag ja nur noch on nutzen) in FHEM umzubauen wenn es dazu extra die Rules in Tasmota gibt.
"Nachteil" wär doch dann auch wieder das der Timer bei Betätigung des Button direkt am Device auch nicht greift?
Oder lieg ich falsch ?
Einmal eine Rule angelegt kommt die komplett auch als Reading rein, man sieht in FHEM auch später irgendwann einmal/wenn das Gerät mal umzieht und man mglw. vergessen hat  ;D weshalb das Gerät nach Zeit X immer ausgeht, ah ja hier bei dem Gerät hab ich besondere Einstellungen vorgenommen.

Gruß

Thomas

Beta-User

Na ja, ich hatte mit dem Hinweis auf "backlog" weniger an delay-Anweisungen gedacht, sondern an "PulseTime", wobei meine (ungeprüfte) Annahme die war, dass das auch Auswirkungen auf lokale Tastendrücke hätte. Kann auch falsch sein, hätte aber den Vorteil, dass das dann auch Teil der Status-Rückmeldungen sein müßte (und man daher nicht nur "beobachten" würde, was eine rule "veranstaltet", sondern direkte Info auch in FHEM)...
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

TomLee

Man "beobachtet" doch nicht nur bei Verwendung von Rules, das PowerX-Event wird doch immer direkt übertragen.

Nicht einen umgebogenem on -setter, sondern einen zusätzlichen rule-setter könnt ich mir für ein Template-Beispiel vorstellen.

Zitatdefmod MQTT2_Sonoff_S20 MQTT2_DEVICE DVES_12F2A2
attr MQTT2_Sonoff_S20 IODev MQTT2_Server
attr MQTT2_Sonoff_S20 alexaName zirkulation
attr MQTT2_Sonoff_S20 autocreate 0
attr MQTT2_Sonoff_S20 comment NOTE: on-for-timer is limited to 18h max duration!
attr MQTT2_Sonoff_S20 event-on-change-reading .*
attr MQTT2_Sonoff_S20 genericDeviceType switch
attr MQTT2_Sonoff_S20 homebridgeMapping clear On=state,valueOn=on,cmdOn=on-for-timer+600,cmdOff=off
attr MQTT2_Sonoff_S20 icon hue_filled_outlet
attr MQTT2_Sonoff_S20 jsonMap POWER1:state
attr MQTT2_Sonoff_S20 model tasmota_basic_state_power1
attr MQTT2_Sonoff_S20 readingList tele/sonoffs20/LWT:.* LWT\
  tele/sonoffs20/STATE:.* { json2nameValue($EVENT) }\
  tele/sonoffs20/SENSOR:.* { json2nameValue($EVENT) }\
  tele/sonoffs20/INFO.:.* { json2nameValue($EVENT) }\
  stat/sonoffs20/RESULT:.* { json2nameValue($EVENT) }
attr MQTT2_Sonoff_S20 room Homekit,MQTT2_DEVICE
attr MQTT2_Sonoff_S20 setList off:noArg    cmnd/sonoffs20/POWER1 0\
  on:noArg     cmnd/sonoffs20/POWER1 1\
  toggle:noArg cmnd/sonoffs20/POWER1 2\
  on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100;; 'cmnd/sonoffs20/Backlog pulseTime1 '.$duration.';; POWER1 1'}\
  setOtaUrl:textField cmnd/sonoffs20/OtaUrl $EVTPART1\
  upgrade:noArg   cmnd/sonoffs20/upgrade 1\
rule1:on,off {my $rule = $EVTPART1 eq "on" ? $EVTPART0." 1" : $EVTPART0." 0";; 'cmnd/sonoffs20/'.$rule}

setstate MQTT2_Sonoff_S20 on
setstate MQTT2_Sonoff_S20 2019-12-27 16:01:47 FallbackTopic cmnd/DVES_12F2A2_fb/
setstate MQTT2_Sonoff_S20 2019-12-27 16:03:30 Free 411
setstate MQTT2_Sonoff_S20 2019-12-27 16:01:47 GroupTopic cmnd/sonoffs/
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 Heap 27
setstate MQTT2_Sonoff_S20 2019-12-27 16:01:47 Hostname sonoffs20-4770
setstate MQTT2_Sonoff_S20 2019-12-27 16:01:47 IPAddress 192.168.188.64
setstate MQTT2_Sonoff_S20 2019-12-27 16:01:47 LWT Online
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 LoadAvg 19
setstate MQTT2_Sonoff_S20 2019-12-27 16:01:47 Module Sonoff Basic
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 MqttCount 1
setstate MQTT2_Sonoff_S20 2019-12-27 16:03:30 Once off
setstate MQTT2_Sonoff_S20 2019-12-27 16:07:47 POWER1 off
setstate MQTT2_Sonoff_S20 2019-12-27 16:01:47 RestartReason Power on
setstate MQTT2_Sonoff_S20 2019-12-27 16:03:30 Rule1 on
setstate MQTT2_Sonoff_S20 2019-12-27 16:03:30 Rules on power1#state do backlog power1 %value%;; RuleTimer1 5 endon   on Rules#Timer=1 do power1 off endon
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 Sleep 50
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 SleepMode Dynamic
setstate MQTT2_Sonoff_S20 2019-12-27 16:03:30 StopOnError off
setstate MQTT2_Sonoff_S20 2019-12-27 16:07:41 T1 5
setstate MQTT2_Sonoff_S20 2019-12-27 16:07:41 T2 0
setstate MQTT2_Sonoff_S20 2019-12-27 16:07:41 T3 0
setstate MQTT2_Sonoff_S20 2019-12-27 16:07:41 T4 0
setstate MQTT2_Sonoff_S20 2019-12-27 16:07:41 T5 0
setstate MQTT2_Sonoff_S20 2019-12-27 16:07:41 T6 0
setstate MQTT2_Sonoff_S20 2019-12-27 16:07:41 T7 0
setstate MQTT2_Sonoff_S20 2019-12-27 16:07:41 T8 0
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 Time 2019-12-27T16:06:50
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 Uptime 0T00:05:12
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 UptimeSec 312
setstate MQTT2_Sonoff_S20 2019-12-27 16:01:47 Version 7.1.1(tasmota)
setstate MQTT2_Sonoff_S20 2019-12-27 16:01:47 WebServerMode Admin
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 Wifi_AP 2
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 Wifi_BSSId FC:EC:DA:FD:26:1A
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 Wifi_Channel 6
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 Wifi_Downtime 0T00:00:06
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 Wifi_LinkCount 1
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 Wifi_RSSI 70
setstate MQTT2_Sonoff_S20 2019-12-27 16:06:51 Wifi_SSId FBF
setstate MQTT2_Sonoff_S20 2019-12-27 16:02:19 state on

Was ich mich hier Frage und etwas auf dem Schlauch stehe weshalb das Glühlampensymbol nicht den Status wechselt (also state), dafür war doch das jsonmap ?

Gruß

Thomas

Beta-User

Hmm, klar könnte man auch einen rule-setter generieren.

Bin aber unsicher, ob das grade für Einschaltdauern Sinn macht, da es dafür quasi intern bereits eine Art rule-set gibt (eben pulseTimex), das sich afaik auch auf lokale Tastendrücke (am Gerät selbst) auswirkt.
Schön ist jedenfalls, dass man auch dafür eine Info als Reading bekommt, egal, ob es jetzt via pulseTime der via "anderer rule" ist.


Das jsonMap wirkt nur, wenn die Rückmeldung via JSON-Blob kommt und "der 3. Parameter" in json2nameValue() gesetzt ist. Der fehlt hier (STATTOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }), und uU. ist es hier zusätzlich so, dass "stat/sonoffs20/POWER1" nach "state" zu mappen sein könnte.
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

TomLee

Nicht speziell für Einschaltdauern, generell um die möglichen "Routinen" die man sich in den Rules programmiert hat zu aktivieren/deaktivieren. Hab zwar noch kein Anwendungsfall aber der wird kommen  :) Rule Cookbook


stat/sonoffs20/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP)

Danke, so klappts.

Beta-User

Zitat von: TomLee am 27 Dezember 2019, 17:35:09
Danke, so klappts.
Thx, und etwas [OT]:

Wenn du damit etwas Erfahrung hast, wäre es nett, wenn du deine Meinung zum großflächigeren Einsatz dann auch in dem allg. template-Thread so verlautbaren könntest. Da warte ich noch auf Antwort (nicht speziell von dir, allgemein)... Vielleicht kommt dann da etwas mehr Rückmeldung, auch von anderen.
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