Sonoff Tasmota über MQTT2 on-for-timer Zeitbegrenzung

[Skusi]

Hallo,

ich habe am WE alle meine MQTT devices zu MQTT2 migriert.

Alles gut soweit, aber heute morgen war schon zum 2. mal der Kaffee nicht fertig. Meine Sonoff S20 mit Tasmota hat vor dem Umzug zu MQTT2 immer morgen schön brav per on-for-timer 900 den Kaffee gekocht.

Nun bin ich der Sache auf den Grund gegangen und mußte feststellen, das alle Sekunden Werte über 360 von dem Befehl zu 1 gewandelt werden.
Also wurde aus on-for-timer 900, on-for-timer 1. Und so schnell ist keine Kaffeemaschine.

Ich bin mir nicht sicher ob das schon irgendwo erwähnt wurde, aber ist das ein Bug oder Feature ?

...

[TomLee]

Hallo,

lass den Timer besser im Aktor laufen 

Gruß

Thomas

[rudolfkoenig]

@Skusi: kannst du bitte das betroffene setList zeigen?

[TomLee]

Ups, sry.

Wsl. verwendest du ihn ja schon

[Skusi]

Gerne doch:

Code Auswählen Erweitern

off:noArg    cmnd/DVES_575127/POWER1 0
  on:noArg     cmnd/DVES_575127/POWER1 1
  toggle:noArg cmnd/DVES_575127/POWER1 2
  on-for-timer {my $duration = $EVTPART1*10; 'cmnd/DVES_575127/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}

Ich hoffe das ist das was du meinst...

[Beta-User]

Hmmm, vorab mal sorry, dass du eine erste und noch nicht vollständig ausgetestete Variante erwischt hast.

Habe grade mal in die Doku zu delay (https://github.com/arendst/Sonoff-Tasmota/wiki/Commands#management) bzw. pulsetime gesehen.

Der Code mit delay ist zwischenzeitlich dahingehend geändert, dass jetzt pulseTime verwendet wird:

Code Auswählen Erweitern

on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100; 'CMNDTOPIC/Backlog pulseTime1 '.$duration.'; POWER1 1'}
Aber auch da gibt es eine interne Beschränkung auf 18h. (= 64900-100 Sekunden)

Unter diesen Bedingungen: Macht es Sinn, den on-for-timer-Code drinzulassen (oder auszukommentieren?), sollte dazu was in ein Comment-Attribut?
Ich finde 18 h für die allermeisten Fälle völlig ausreichend und würde zur "Kommentarvariante" neigen, aber es wird trotzdem immer Leute geben, die darüber stolpern...

Meinungen dazu?

[Skusi]

Also ich hab das ganze nun mit dem geänderten Code laufen.

Vielen dank für die schnelle Aufklärung. Nun wo ich mir die setList Zeilen mal genauer angesehen habe, verstehe ich auch wie das ganze funktioniert.
Ich hab eben auch erstmal nachgelesen was auf der Seite mit den Tasmota Commands dazu geschrieben steht.
Ich frage mich zwar warum das so kompitiert aufgelöst wird:

1..111 = set PulseTime for the corresponding Relay in 0.1 second increments
112..64900 = set PulseTime for the corresponding Relay, offset by 100, in 1 second increments.

aber egal, die Zeile in der setList macht genau was sie soll und 18 Stunden sollen mir genug sein.

Also ich denke den Code drin lassen und per Comments auf die 18 Stunden Grenze hinweisen.

[Otto123]

Hi,

das Kommando für pulseTime1 hat ein Problem: Es wird im Aktor gespeichert und bleibt dort. D.h. jeder weitere on Befehl ist keiner - sondern der letzte on-for-timer.
Zumindest ist das bei mir in meinen Tests so.

Man muss den Timer mit on-for-timer 0 wieder löschen.

Keine Ahnung wie man das einbauen könnte - oder lieg ich daneben?

Gruß Otto

P.S: nochmal getestet, der pulseTime1 wird in den Flash geschrieben. Der überlebt auch einen stromlos Zustand des Plug

[Beta-User]

Danke für den Hinweis, dann macht das m.E. so keinen Sinn, zumal davon auszugehen ist, dass das dem ESP nicht sooo gut tun dürfte, wenn man das ständig sendet. M.E. müßte sonst auch ein normaler "on"-Befehl via backlog gehen und die Zeit vorher umstellen, wir hätten also einen doppelten "Schreibzyklenverbrauch" für alle user.

Neige dazu, das in einen "config_on_duration"-Setter umzuwandeln, der dann (ohne den on-Befehl zu senden) "einfach" die maximale Anschaltdauer festlegt (wie, wenn man ein entsprechendes Register bei den HM-Teilen setzt).

Meinungen dazu?

[sigma415]

Bin heute über das gleiche Problem gestolpert, dass PulseTime<x> resistent alle darauffolgenden ON's zeitlich begrenzt.
Passiert übrigens auch bei einem Toggle von Off nach On.
(Erinnert mich irgendwie an das Thema mit den vergessenen globalen Variablen .... )

Ich habe jetzt die Setlist geändert, so dass der Timer bei allen "normalen" Schaltbefehlen auf 0 gesetzt wird:

Code Auswählen Erweitern

off:noArg    cmnd/DVES_036BB0/Backlog pulseTime1 0;POWER1 0
  on:noArg     cmnd/DVES_036BB0/Backlog pulseTime1 0;POWER1 1
  toggle:noArg cmnd/DVES_036BB0/Backlog pulseTime1 0;POWER1 2
  on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100; 'cmnd/DVES_036BB0/Backlog pulseTime1 '.$duration.'; POWER1 1'}
  setOtaUrl:textField cmnd/DVES_036BB0/OtaUrl $EVTPART1
  upgrade:noArg   cmnd/DVES_036BB0/upgrade 1

Ich hätte eigentlich erwartet, dass Tasmota unterschiedliche Commands hat für ON und "On for PulseTime". (ist aber nicht so )
Oder dass man dort durch Setzen eines Parameters das Verhalten anpassen kann (SetOptionxx)
Wen muss man dazu überreden ?

@Beta-User: Was meinst Du mit "in einen "config_on_duration"-Setter umzuwandeln" ?
Das "on-for-timer" einfach umbenennen und nur das PulseTime Command als reine Einstellung ohne Aktion zu senden ?
Würde sicher verhindern, dass weitere User darüber stolpern, aber wie kann man dann (als alter HM-ler) ein "on-for timer" realisieren ?

[Beta-User]

Hmm, dass mal wieder jemand darüber gestolpert ist, spricht dafür, das "on-for-timer" aus dem template zu nehmen...

Was ich bis hierher bzgl. der Optionen bei Tasmota verstanden habe, kann man

- delay verwenden.

Code Auswählen Erweitern

on-for-timer {my $duration = $EVTPART1*10; 'cmnd/DVES_575127/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}Ohne Auswirkungen auf alles, was danach kommt, hat aber den Nachteil, dass delay auf 3600 1/10 Sekunden begrenzt ist (siehe https://github.com/arendst/Tasmota/wiki/Commands#delay)

- das mit pulseTimex lösen
Hat aber ebenfalls eine Begrenzung, allerdings auf 18h (?) und den Nachteil, dass sich der Tasmota das merkt für alle weiteren Schaltvorgänge (aber das wohl nur dann speichert/EEPROM-Schreib-Zyklen verbraucht, wenn man auch "save" anweist), also in der Regel bis zum nächsten reboot (=> auch erklärungsbedürftig bzw. leicht zu vergessen...).

- SetExtensions arbeiten lassen
Dann überwacht FHEM den timer (was manche als Nachteil empfinden mögen; mir ist im Moment auf die Schnelle nicht klar, ob das einen FHEM-Neustart überlebt).

Vorschlag:
- on-for-timer kommt aus dem attrTemplate (zu fehleranfällig bzw. erklärungsbedürftig);
- obige Varianten werden im Wiki (Praxisbeispiele) aufgenommen, dann kann das jeder nach dem jeweiligen Bedarf so übernehmen, wie es für seinen Anwendungsfall paßt (darf gerne auch jemand anders machen...).

Zu klären wäre dann noch, ob wir eine Konfigurationsoption für die auf dem ESP zu speichernde Anschaltdauer über das template anbieten wollen (conf_max_on_duration). Dann würde das via backlog auf den ESP geschoben, aber ein sinnvollerweise mit einem "save" dazu.
Habe aber zugegebenermaßen etwas Skrupel, weil das meinem Empfinden nach eher ein Spezialfall ist, der damit "zu prominent" präsentiert würde. Im Wiki wäre das aber in jedem Fall auch gut aufgehoben.

Meinungen dazu?

[rudolfkoenig]

Dann überwacht FHEM den timer (was manche als Nachteil empfinden mögen; mir ist im Moment auf die Schnelle nicht klar, ob das einen FHEM-Neustart überlebt).

Ja, "set off" wird als einmaliges AT definiert, und shutdown speichert sowas automatisch im statefile.
Funktioniert natuerlich nicht bei einem FHEM Crash, oder wenn Funk beim Ausschalten gestoert ist.
Meiner Ansicht nach sollte man die Tasmota-Jungs ueberzeugen, ein "richtiges" on-for-timer zu implementieren.

[Beta-User]

@Rudi: Thx für die Aufklärung.

Dann ist es aber aus FHEM-Sicht m.E. im Moment eigentlich klar, dass man das (wieder) via SetExtensions macht.

Wäre natürlich toll, wenn jemand, der das auch nutzt damit an Theo&Co herantreten würde, dass da gleich z.B. "1 4500" als Befehl für "anschalten für 4500 Sek." akzeptiert würde. Es ist aber anzunehmen, dass man sich von der Seite her schon Gedanken gemacht hatte, wie man mit timern umgehen will. Sonst habe ich keine Erklärung dafür, dass es dazu gleich zwei - unterschiedliche - Implementierungen gibt.

[Beta-User]

Zur Info: on-for-timer habe ich eben beim allgemeinen Tasmota-template aus der setList genommen, dafür den Kommentar erweitert.
Im Wiki@Praxisbeispiele gibt's einen kleinen Abschnitt dazu, in dem die Varianten kurz erläutert sind.

[mmi]

Hallo zusammen,

ich bin über das 360s (3600 Zehntelsekunden) Limit bei der backlog/delay Methode gestolpert. Bei der Einrichtung habe ich mich an den Praxisbeispielen im Wiki https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#delay und am Kommentar im angelegten Gerät https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L888 orientiert, was bei einem gewünschten Intervall von 2700s zu Problemen geführt hat.

Den Thread habe ich dann erst bei der Ursachenforschung entdeckt. Ich werde jetzt ersteinmal auf setExtention ausweichen. Könnt ihr bitte die Hinweise im Wiki und im Tempate so anpassen, dass bei der delay Methode eine Obergrenze von 6min/360s angegeben wird?

Vielen Dank!