Tasmota, Jalousiesteuerung

[Waldmensch]

Hallo Leute,

Ich will, während ich auf meine Shelly2's warte, schon mal ein paar Sachen ausprobieren. Ziel ist es, eine Jalousie nur 3/4 zufahren zu lassen (wenn die Sonne draufliegt). Das geht ja in erster Linie nur zeitgesteuert. Tasmota hat den Befehl  PULSETIME(n) korrospondierend mit dem jeweiligen POWER(n). Mit dem MQTT Modul selbst kann ich IMHO keine 2 Kommandos nacheinander absetzen. Ich habe jetzt folgenden Ansatz und hätte gern Eure Meinung ob es auch anders oder besser geht, oder ob ihr sowas schonmal umgesetzt habt. Stört euch nicht an dem Devicenamen, dass ist eine NodMCU die ich zum testen mal zweckentfremdet hab. Die Steuerung wird dann über einen sowieso schon in FHEM vorhandenen Lichtstärkesensor und ein Notify oder DOIF für mehrere Jalousien ausgelöst.

Code Auswählen Erweitern

defmod stadtweg.eg.heizung MQTT_DEVICE
attr stadtweg.eg.heizung DbLogExclude SENSOR,STATE,Time,Uptime,Vcc,Wifi_AP,Wifi_BSSId,Wifi_Channel,Wifi_SSId,transmission-state
attr stadtweg.eg.heizung IODev myBroker
attr stadtweg.eg.heizung event-on-update-reading Vcc,Wifi_RSSI,SENSOR,STATE,DS18B20-1_Temperature,DS18B20-2_Temperature
attr stadtweg.eg.heizung group stadtweg.eg.heizung
attr stadtweg.eg.heizung publishSet_POWER1 cmnd/stadtweg/eg/heizung/POWER1
attr stadtweg.eg.heizung publishSet_POWER2 cmnd/stadtweg/eg/heizung/POWER2
attr stadtweg.eg.heizung publishSet_PULSETIME1 cmnd/stadtweg/eg/heizung/PULSETIME1
attr stadtweg.eg.heizung room MQTT
attr stadtweg.eg.heizung stateFormat T1:DS18B20-1_Temperature T2:DS18B20-2_Temperature
attr stadtweg.eg.heizung subscribeReading_SENSOR tele/stadtweg/eg/heizung/SENSOR
attr stadtweg.eg.heizung subscribeReading_STATE tele/stadtweg/eg/heizung/STATE

Dazu habe ich ein Notify gebaut, was die Kommandos hintereinander sendet

Code Auswählen Erweitern

defmod ntf.stadtweg.eg.heizung notify dmy.stadtweg.eg.heizung {\
if ("$EVENT" eq "halbzu") {\
  fhem("set stadtweg.eg.heizung PULSETIME1 112");;\
  fhem("set stadtweg.eg.heizung POWER1 ON");;\
}\
elsif ("$EVENT" eq "zu"){\
  fhem("set stadtweg.eg.heizung PULSETIME1 120");;\
  fhem("set stadtweg.eg.heizung POWER1 ON");;\
}\
else {\
  fhem("set stadtweg.eg.heizung PULSETIME2 120");;\
  fhem("set stadtweg.eg.heizung POWER2 ON")\
}\
}
attr ntf.stadtweg.eg.heizung group stadtweg.eg.heizung
attr ntf.stadtweg.eg.heizung room MQTT

Das ganze steuere ich dann über einen Dummy an mit "halbzu", "zu" oder "auf"

Code Auswählen Erweitern

defmod dmy.stadtweg.eg.heizung dummy
attr dmy.stadtweg.eg.heizung group stadtweg.eg.heizung
attr dmy.stadtweg.eg.heizung room MQTT

[Waldmensch]

Eine Andere Möglichkeit habe ich noch gefunden über die Tasmota Rules

Code Auswählen Erweitern

rule1
on event#halbzu do power2 off endon
on event#halbzu do power1 on endon
on event#halbzu do ruletimer1 %value% endon
on rules#timer=1 do power1 off endon

on event#zu do power2 off endon
on event#zu do power1 on endon
on event#zu do ruletimer2 30 endon
on rules#timer=2 do power1 off endon

on event#auf do power1 off endon
on event#auf do power2 on endon
on event#auf do ruletimer3 30 endon
on rules#timer=3 do power2 off endon

Das Command "EVENT" funktioniert über MQTT:

Code Auswählen Erweitern

attr stadtweg.eg.heizung publishSet_EVENT cmnd/stadtweg/eg/heizung/EVENT

Dann kann man folgendes senden:

Code Auswählen Erweitern

set stadtweg.eg.heizung EVENT halbzu=10

und im Tasmota Log sieht das dann so aus

Code Auswählen Erweitern

02:32:36 CMD: event halbzu=10
02:32:36 MQT: stat/stadtweg/eg/heizung/RESULT = {"Event":"Done"}
02:32:36 RUL: EVENT#HALBZU performs "power2 off"
02:32:36 MQT: stat/stadtweg/eg/heizung/RESULT = {"POWER2":"OFF"}
02:32:36 MQT: stat/stadtweg/eg/heizung/POWER2 = OFF
02:32:36 RUL: EVENT#HALBZU performs "power1 on"
02:32:36 MQT: stat/stadtweg/eg/heizung/RESULT = {"POWER1":"ON"}
02:32:36 MQT: stat/stadtweg/eg/heizung/POWER1 = ON
02:32:36 RUL: EVENT#HALBZU performs "ruletimer1 10"
02:32:36 MQT: stat/stadtweg/eg/heizung/RESULT = {"T1":10,"T2":0,"T3":0,"T4":0,"T5":0,"T6":0,"T7":0,"T8":0}
02:32:47 RUL: RULES#TIMER=1 performs "power1 off"
02:32:47 MQT: stat/stadtweg/eg/heizung/RESULT = {"POWER1":"OFF"}
02:32:47 MQT: stat/stadtweg/eg/heizung/POWER1 = OFF

Scheint also zu klappen und ist einfacher als ein Notify + Dummy zusätzlich im FHEM

[Gisbert]

Hallo Waldmensch,

ich habe eine solche Steuerung (Tasmota + Rules), wie du sie vorhast, noch nicht in Betrieb, wäre aber interessiert sie auf einem ESP8266-01 (Hardwareprojekt Rollladenschalter von Papa Romeo) zum Laufen zu bringen.

Dazu einige Fragen und Anmerkungen.
Läuft Tasmota auf einem ESP8266-01 mit 1MB Speicher sinnvoll? Welches Board muss ausgewählt werden?
In den Tasmota Rules müsste eine Wartezeit zur Sicherheit eingebaut werden, da sonst der Motor bei abrupten Wechsel von rauf/runter Gefahr läuft beschädigt zu werden; 250 ms reichen aus.

Viele​ Grüße​ Gisbert​

[Beta-User]

Vielleicht könnte das Rollo Modul helfen.
Das müssze eigentlich auch mit 2 Tasmota-Relais zusammen funktionieren.

[Waldmensch]

ich habe eine solche Steuerung (Tasmota + Rules), wie du sie vorhast, noch nicht in Betrieb, wäre aber interessiert sie auf einem ESP8266-01 (Hardwareprojekt Rollladenschalter von Papa Romeo) zum Laufen zu bringen.

Hallo Gisbert,
Ich habe ähnliches hiermit vor (bevor ich den Shelly2 entdeckt hab) allerdings hiermit https://github.com/Necromancer1982/SmartSwitch Die Platinen sind schon unterwegs. Soll aber ein Winterprojekt werden, ohne zeitliche Priorität

Dazu einige Fragen und Anmerkungen.
Läuft Tasmota auf einem ESP8266-01 mit 1MB Speicher sinnvoll? Welches Board muss ausgewählt werden?
In den Tasmota Rules müsste eine Wartezeit zur Sicherheit eingebaut werden, da sonst der Motor bei abrupten Wechsel von rauf/runter Gefahr läuft beschädigt zu werden; 250 ms reichen aus.

Viele​ Grüße​ Gisbert​

Ich weiß nicht wie Du flasht, aber in PlatformIO trägst Du für einen ESP01 in der platformio.ini

Code Auswählen Erweitern

board = esp01_1m ein. Ich habe in der der user_config.h noch Domoticz und Home Assistant Discovery deaktiviert, da ich das nicht nutze

Code Auswählen Erweitern

// -- MQTT ----------------------------------------
#define MQTT_TELE_RETAIN     0                   // Tele messages may send retain flag (0 = off, 1 = on)

// -- MQTT - Domoticz -----------------------------
//#define USE_DOMOTICZ                             // Enable Domoticz (+6k code, +0.3k mem)
  #define DOMOTICZ_IN_TOPIC    "domoticz/in"     // Domoticz Input Topic
  #define DOMOTICZ_OUT_TOPIC   "domoticz/out"    // Domoticz Output Topic

// -- MQTT - Home Assistant Discovery -------------
//#define USE_HOME_ASSISTANT                       // Enable Home Assistant Discovery Support (+2k code)
  #define HOME_ASSISTANT_DISCOVERY_PREFIX "homeassistant"  // Home Assistant discovery prefix
Ein "nackiger" ESP01 (bzw 3 Stück davon) mit nur einem DHT11 dran läuft reibungslos seit einer Woche um in einem Ladengeschäft einen hydraulischen Abgleich der Heizung zu machen, ohne mit Thermometer rumrennen zu müssen

Ein Delay einzubinden, geht in den Rules. Merkwürdigerweise funktioniert aber bei mir die Rule nicht, wenn ich die Komandos semikolongetrennt hintereinanderschreibe. Dann wird nur das erste Komando ausgeführt. Wenn ich das so schreibe:

Code Auswählen Erweitern

rule1
on event#halbzu do power2 off;delay 250;power1 on;ruletimer1 %value% endon
on rules#timer=1 do power1 off endon
on event#zu do power2 off;delay 250;power1 on;ruletimer2 30 endon
on rules#timer=2 do power1 off endon
on event#auf do power1 off;delay 250;power2 on;ruletimer3 30 endon
on rules#timer=3 do power2 off endon
wird nur power2 off ausgeführt. Keine Ahnung ob das ein Bug ist

Code Auswählen Erweitern

08:49:31 CMD: rule1 on event#halbzu do power2 off;delay 250;power1 on;ruletimer1 %value% endon on rules#timer=1 do power1 off endon on event#zu do power2 off;delay 250;power1 on;ruletimer2 30 endon on rules#timer=2 do power1 off endon on event#auf do power1 off;delay 250;power2 on;ruletimer3 30 endon on rules#timer=3 do power2 off endon
08:49:31 MQT: stat/stadtweg/eg/heizung/RESULT = {"Rule1":"ON","Once":"OFF","StopOnError":"OFF","Free":193,"Rules":"on event#halbzu do power2 off;delay 250;power1 on;ruletimer1 %value% endon on rules#timer=1 do power1 off endon on event#zu do power2 off;delay 250;power1 on;ruletimer2 30 endon on rules#timer=2 do power1 off endon on event#auf do power1 off;delay 250;power2 on;ruletimer3 30 endon on rules#timer=3 do power2 off endon"}
08:49:51 CMD: event halbzu=10
08:49:51 MQT: stat/stadtweg/eg/heizung/RESULT = {"Event":"Done"}
08:49:51 RUL: EVENT#HALBZU performs "power2 off;delay 250;power1 on;ruletimer1 10"
08:49:51 MQT: stat/stadtweg/eg/heizung/RESULT = {"POWER2":"OFF"}
08:49:51 MQT: stat/stadtweg/eg/heizung/POWER2 = OFF

[Waldmensch]

Vielleicht könnte das Rollo Modul helfen.
Das müssze eigentlich auch mit 2 Tasmota-Relais zusammen funktionieren.

Ich würde ungern zeitkritische Befehle über WLAN schicken. Die Jalousie sollte schon immer an der gleichen Position stoppen, unabhängig von WLAN Lags. Ich habe jetzt noch nicht die Geschwindigkeit gemessen, aber eine Sekunde sind sicher 5-10cm Fahrt. Sieht irgendwie doof aus, wenn 3 Fenster zur Straße hin, die Jalousien unterschiedlich weit zu haben.
Der Timer mit Abschaltbefehl sollte schon direkt in Tasmota laufen.

[Beta-User]

Schon klar, dass das nicht optimal ist...
Aber wenn, sollte dann die gesamte Timerlogik auf dem Aktor laufen, also z.B. nur ein Prozent-Wert dahin geschickt werden und der Aktor dann die Gesamtlaufzeit nach oben bzw unten kennt und auf Basis des aktuellen Werts dann die Laufzeit ermittelt.

[Waldmensch]

@Beta-User, naja, mein zweiter Ansatz (Tasmota Rule) macht ja genau das. Ich schicke aus FHEM das EVENT halbzu=10 für eine Laufzeit von 10 Sekunden. Den Rest macht Tasmota, indem der Wert in einen RuleTimer geschrieben wird und Jener das Relay nach 10 Sekunden abschaltet.

[Waldmensch]

Bezüglich der Tasmota rule - ich hatte das command backlog vergessen. So funktioniert die Rule und hat 300ms delay in der Relaisumschaltung, wie von @Gisbert vorgeschlagen

Code Auswählen Erweitern

rule1
on event#halbzu do backlog power2 off;delay 3;power1 on;ruletimer1 %value% endon
on rules#timer=1 do power1 off endon
on event#zu do backlog power2 off;delay 3;power1 on;ruletimer2 30 endon
on rules#timer=2 do power1 off endon
on event#auf do backlog power1 off;delay 3;power2 on;ruletimer3 30 endon
on rules#timer=3 do power2 off endon

Im MQTT Device in FHEM das EVENT zufügen

Code Auswählen Erweitern

attr stadtweg.eg.heizung publishSet_EVENT cmnd/stadtweg/eg/heizung/EVENT

Damit ist dann folgendes möglich. Die 10 entspricht der Laufzeit, die der Motor an sein soll

Code Auswählen Erweitern


set stadtweg.eg.heizung EVENT halbzu=10
set stadtweg.eg.heizung EVENT zu
set stadtweg.eg.heizung EVENT auf


Im Tasmota Device ist die "Zu-Richtung" auf Relay1 und die "Auf-Richtung" auf Relay2

Log von halbzu=10

Code Auswählen Erweitern

11:22:59 CMD: event halbzu=10
11:22:59 MQT: stat/stadtweg/eg/heizung/RESULT = {"Event":"Done"}
11:22:59 RUL: EVENT#HALBZU performs "backlog power2 off;delay 3;power1 on;ruletimer1 10"
11:22:59 MQT: stat/stadtweg/eg/heizung/RESULT = {"POWER2":"OFF"}
11:22:59 MQT: stat/stadtweg/eg/heizung/POWER2 = OFF
11:23:00 MQT: stat/stadtweg/eg/heizung/RESULT = {"Delay":3}
11:23:00 MQT: stat/stadtweg/eg/heizung/RESULT = {"POWER1":"ON"}
11:23:00 MQT: stat/stadtweg/eg/heizung/POWER1 = ON
11:23:00 MQT: stat/stadtweg/eg/heizung/RESULT = {"T1":10,"T2":0,"T3":0,"T4":0,"T5":0,"T6":0,"T7":0,"T8":0}
11:23:10 RUL: RULES#TIMER=1 performs "power1 off"
11:23:11 MQT: stat/stadtweg/eg/heizung/RESULT = {"POWER1":"OFF"}
11:23:11 MQT: stat/stadtweg/eg/heizung/POWER1 = OFF

Log von "zu" (hier sind 30 Sekunden Laufzeit in der Rule fest verdrahtet. Jalousieen haben ja in der Regel Endschalter, so dass das kein Problem ist) Eventuell muss der Wert erhöht werden, bei großen Jalousieen

Code Auswählen Erweitern

11:35:18 CMD: event zu
11:35:18 MQT: stat/stadtweg/eg/heizung/RESULT = {"Event":"Done"}
11:35:18 RUL: EVENT#ZU performs "backlog power2 off;delay 3;power1 on;ruletimer2 30"
11:35:18 MQT: stat/stadtweg/eg/heizung/RESULT = {"POWER2":"OFF"}
11:35:18 MQT: stat/stadtweg/eg/heizung/POWER2 = OFF
11:35:19 MQT: stat/stadtweg/eg/heizung/RESULT = {"Delay":3}
11:35:19 MQT: stat/stadtweg/eg/heizung/RESULT = {"POWER1":"ON"}
11:35:19 MQT: stat/stadtweg/eg/heizung/POWER1 = ON
11:35:19 MQT: stat/stadtweg/eg/heizung/RESULT = {"T1":0,"T2":30,"T3":0,"T4":0,"T5":0,"T6":0,"T7":0,"T8":0}
11:35:50 RUL: RULES#TIMER=2 performs "power1 off"
11:35:50 MQT: stat/stadtweg/eg/heizung/RESULT = {"POWER1":"OFF"}
11:35:50 MQT: stat/stadtweg/eg/heizung/POWER1 = OFF

[Beta-User]

@Beta-User, naja, mein zweiter Ansatz (Tasmota Rule) macht ja genau das. Ich schicke aus FHEM das EVENT halbzu=10 für eine Laufzeit von 10 Sekunden. Den Rest macht Tasmota, indem der Wert in einen RuleTimer geschrieben wird und Jener das Relay nach 10 Sekunden abschaltet.

Das war schon klar, setzt aber voraus, dass der Rollladen an einer ganz bestimmten Position ist. Was m.e. fehlt, ist eine interne Variable, die z.B. das Verhältnis zur Gesamtlaufzeit verwaltet.

[Waldmensch]

Eine stets aktuelle position wirst Du nicht erfassen können. Dazu ist die Steuerung über Zeit einfach zu ungenau. Ich könnte mir vorstellen, Das man immer erst die "Auf" Position anfährt und dann die "halbzu" Position je nach Bedarf. Von einer "halbzu" Position auf eine andere "halbzu" Position zu fahren halte ich für fast unmöglich. Zumal ich mir vorstellen könnte, das das hochfahren (Motorlast) der Jalousie länger dauert als das runterfahren.
Genau kann ich das aber erst feststellen, wenn ich einen Aktor habe. Die Shelly2 sind ja momentan sogut wie nicht zu bekommen.

[Beta-User]

Na ja, alles zeitabhängige ist eine Näherung, und es braucht hin und wieder eine Kalibrierung.
Auch der Einwand mit der zunehmenden Achsdicke stimmt, aber wenn man täglich eine Kalibrierung hätte (komplett geschlossen oder offen), sollte das akzeptabel sein; viel besser kann es HM auch nicht...

[Waldmensch]

Aber was machst Du, wenn zwischendurch jemand die manuellen Taster bedient? Es gibt ja kein Signal von den Endanschlägen. Somit ist eine eventuell gemerkte Zeitposition komplett hinfällig. Man könnte eventuell einen GPIO nutzen um ein Reedkontakt mit einem Magneten an Rohmotor auszulesen. Aber will man wirklich so einen Aufwand betreiben? Ich habe Seit 10 Jahren elektrische Jalousieen mit Somfy Controlern und Lichtsensoren an der Scheibe. Es gibt da nur drei Zustände:
1 auf
2 zu
3 halbzu bis da, wo der Lichtsensor an der Scheibe klebt

Bei Sonneneinstrahlung fährt die Jalousie runter, bis der Sensor verdunkelt wird. Dann wieder ein paar Zentimeter hoch, damit der Sensor wieder Licht kriegt. Wenn Die Einstrahlung für Zeit x unter Wert Y fällt fährt sie wieder in Stellung "auf"
Wenn Die Shelly2 den A0 und 3,3V (des ESP8266) auf einen Stecker rausgeführt hätten, könnte man das mit einem Fotowiderstand ganz leicht nachbauen.

[Beta-User]

Na ja, wenn jemand lokal bedient, müsste eben die Fahrzeit erfasst werden; wenn man zentrale Variablen nutzen kann (?), sollte das möglich sein. Aber wenn du mit nur 3 Zuständen auskommt, ist das auch OK.

Aber an sich habe ich zunehmend den Eindruck, dass es OK ist, wenn man für einen Rollladenaktor eben etwas mehr Geld für besseres Wissen über die aktuelle Position ausgibt... WLAN ist auch nicht so meine bevorzugte Transportart für Befehle zur Automatisierung.
Aber bestimmt findet sich auch bald jemand, der dazu besseren internen code bereitstellt.

[Waldmensch]

So wie es aussieht, braucht man auf die Shelly2 nicht mal Tasmota flashen. Die Stock Firmware stellt über MQTT schon genau dieses "zu für x Sekunden" Command zusätzlich zu "auf/zu" zur Verfügung. Sind echt auf Zack, die Bulgaren

[Beta-User]

.... wenn es jetzt noch einen %-Level als Befehl o. wenigstens Rückgabeinfo gäbe und die Option, die Laufzeiten anzugeben, wär's bis auf WLAN perfekt... *grins*

[Waldmensch]

Kannst Du doch alles in FHEM bauen, mit den geschätzten Werten. Du kannst ja wegspeichern, was Du hingeschickt hast, Die manuellen Schalter schleust Du dann halt über FHEM und speicherst sie auch weg. Du kannst die Sekunden auch in Prozent umrechnen, Dann hast Du Deinen Prozentwert. Ob der nun als Status via MQTT kommt oder ob Du ihn Dir gleich merkst, wenn Du ihn hinschickst ist doch völlig wurst. Tasmota kann Dir auch maximal den Wert zurückliefern, den Du vorher hingeschickt hast. Ohne Fahrweg Sensoren kann Dir Tasmota nur sagen, wie lange ein Relais angezogen war. Wenn Dir da noch ein Ansatz einfällt kannst Du ihn gerne posten, es macht jedoch keinen Sinn permanent eine Genauigkeit einzufordern, die nicht realisierbar ist, ohne zusätzliche Sensorik

Ich brauche es jedenfalls nicht auf den Millimeter genau, sonst würde ich Die Motoren durch Schrittmotoren ersetzen.

[Gisbert]

Hallo Waldmensch,

basierend auf dem Hardware-Projekt von Papa Romeo habe ich einen ESP8266-01 mit Tasmota geflasht.
Als Module Type wurde "18 Generic" ausgewählt.
Die beiden Relais hängen an GPIO hängen an 0 und 3, dementsprechend wurde diese ausgewählt.
Die Verdrahtung der Relais ist anders als bei deiner Hardware, das Relais 1 schaltet Strom an/aus und das Relais 2 schaltet hoch/runter.
Damit ist hardwareseitig ausgeschlossen, dass der Auf- und Zufahrbefehl am Motor gleichzeitig anliegen können.

Die Schaltung funktioniert über die Weboberfläche als auch aus Fhem von einem entsprechend angelegten MQTT_DEVICE hervorragend.
Damit sind die Grundanforderungen erfüllt.
Aus Fhem heraus muss dazu z.B. der folgende Befehl abgeschickt werden:

Code Auswählen Erweitern

set <Topic> EVENT zu

Ich habe aber noch zwei weitere Wünsche, für die ich bisher noch keine Lösung gefunden habe:

• Kann man in Fhem einen anklickbaren Schriftzug, z.B. "Runterfahren" generieren, der den obigen Befehl beim Anklicken ausführt anstatt set <Topic> EVENT zu einzutippen?
• Die Hardware sieht auch vor, dass man mit einem Drehschalter oder Taster den Rollladen weiterhin vor Ort bedienen kann.
  Das sehe ich als den größten Vorteil, neben den kompakten Abmessungen dieses Projektes an.
  Die beiden Schaltereingänge liegen an GPIO1 und 2 an.
  Wie müssen diese GPIOs in Tasmota ausgewählt werden, und wie müssten die Rules aussehen, um mit dem Rollladenschalter vor Ort die Fahrbefehle auszuführen?

Viele Grüße Gisbert

[Gisbert]

Hallo Waldmensch,

noch eine weitere Frage.

Wenn ich den letzten Fahrzustand publishen will, dann geht der folgende Befehl in der Console, z.B.:

Code Auswählen Erweitern

publish stat/<topic>/Fahrstatus offen
Damit wird ein Reading im Fhem-Device erzeugt.

Wenn ich diesen Befehl in die Rules einbaue, dann wird dieser Part rausgeschmissen:

Code Auswählen Erweitern

on event#Hochfahren do backlog delay 3; power1 off; power2 off; delay 3; power1 on; publish stat/<topic>/Fahrstatus offen; ruletimer2 40 endon führt zu:

Code Auswählen Erweitern

03:31:34 RUL: EVENT#HOCHFAHREN performs "backlog delay 3;power1 off;power2 off;delay 3;power1 on;ruletimer2 40"
03:31:35 MQT: stat/<topic>/RESULT = {"Delay":3}
03:31:35 MQT: stat/<topic>/RESULT = {"POWER1":"OFF"}
03:31:35 MQT: stat/<topic>/POWER1 = OFF
03:31:35 MQT: stat/<topic>/RESULT = {"POWER2":"OFF"}
03:31:35 MQT: stat/<topic>/POWER2 = OFF
03:31:35 MQT: stat/<topic>/RESULT = {"Delay":3}
03:31:36 MQT: stat/<topic>/RESULT = {"POWER1":"ON"}
03:31:36 MQT: stat/<topic>/POWER1 = ON
03:31:36 MQT: stat/<topic>/RESULT = {"T1":0,"T2":40,"T3":0,"T4":0,"T5":0,"T6":0,"T7":0,"T8":0}

Gibt es irgendeine Idee, wie ich das Publishen hinbekommen könnte?
Es wäre zumindest sinnvoll das oder etwas Änhliches zu haben, was als Rückmeldung des gesendeten Befehls dienen kann, und damit als Bestätigung, dass der Befehl auch ausgeführt wird bzw. wurde.
[Edit]: Mir geht es nicht um die Genauigkeit eines Fahrbefehls sondern nur darum, eine Rückmeldung zu bekommen, dass der Befehl angekommen ist.

Viele Grüße Gisbert

[Gisbert]

.... wenn es jetzt noch einen %-Level als Befehl o. wenigstens Rückgabeinfo gäbe und die Option, die Laufzeiten anzugeben, wär's bis auf WLAN perfekt... *grins*

Hallo Beta-User,
ist dir noch etwas zur Rückgabeinfo eingefallen?

Viele Grüße Gisbert

[Beta-User]

Nein. Sowas wie eine qualifizierte Rückmeldung ginge wohl nur, wenn man den code auf dem MC selbst anpasst.
Benötigt würde dazu noch die Übergabe der beiden Laufzeit-Angaben.

MaW: alles andere als trivial....

[Gisbert]

Hallo Beta-User,

mir geht es nur darum, den zuletzt empfangenen Befehl auf dem ESP zurückzumelden. Das wäre immerhin etwas mehr Information als den aus Fhem abgesetzten Befehl, der ist ja ohnehin bekannt.

Wie weiter oben beschrieben, war ich mit der Implementierung eines publish-Befehls in den Rules nicht erfolgreich. Aber vielleicht geht da doch noch was.

Viele​ Grüße​ Gisbert​

[Beta-User]

Hmmm, das verstehe ich nicht ganz:
Entweder der Befehl kam von fhem. Dann sollte man sicherstellen, dass der Aktor den auch bekommt. Das wäre aber eine Sache, die sich mit MQTT-Bordmitteln lösen lassen müßte (QoS oder so).
Oder es wird lokal geschalteten. Das sollte fhem aber - funktionierende Infrastruktur vorausgesetzt - mitbekommen. Dann ginge es darum, einen passenden Eventhandler dafür zu bauen. Auch keine Hexerei...

[Gisbert]

Hallo Beta-User,

wenn ich den publish-Befehl in eine 2. rule stecke, dann kommt die Rückmeldung in Fhem an:

Code Auswählen Erweitern

rule2
on event#Luecke do publish stat/myRollladen1/Fahrstatus Lücke endon
on event#Hochfahren do publish stat/myRollladen1/Fahrstatus offen endon
on event#Runterfahren do publish stat/myRollladen1/Fahrstatus geschlossen endon
on event#Stop do publish stat/myRollladen1/Fahrstatus gestoppt endon

Ich habe gegoogelt, aber nichts gefunden. Mir ist es schleierhaft, dass es in einer separaten rule funktioniert.

Welche anderen Möglichkeiten gibt es denn noch?

Interessant wäre noch, den manuellen Fahrbefehl am Schalter zu Fhem zu melden.
Hier habe ich noch keine Idee, wie ich die beiden GPIOs deklarieren muss.
Ich hatte bei dem Testaufbau bisher noch keinen manuellen Schalter angeschlossen, das werde ich jetzt nachholen.

Viele Grüße Gisbert

[Waldmensch]

@Gisbert, versuch doch mal das publish in eine zweite Zeile zu packen, mit dem gleichen Event vorn

Code Auswählen Erweitern


on event#Hochfahren do backlog delay 3; power1 off; power2 off; delay 3; power1 on; ruletimer2 40 endon
on event#Hochfahren do publish stat/<topic>/Fahrstatus offen endon


Ich beschäftige mich auch erst seit ein paar Tagen mit Tasmota

Ich habe mal deine Rule in ein Time Event gepackt, das alle 1 Minute ausgeführt wird (power2 umbenannt in power1, weil es nur eine Funkdose mit einem relay ist)

Sieht eigentlich gut aus (vorletzte Zeile):

Code Auswählen Erweitern

14:20:00 RUL: TIME#MINUTE performs "backlog delay 3; power1 off; power1 off; delay 3; power1 on; publish stat/stadtweg/Fahrstatus offen; ruletimer2 40"
14:20:00 MQT: stat/stadtweg/sonoff/s20/steckdose1/RESULT = {"Delay":3}
14:20:00 MQT: stat/stadtweg/sonoff/s20/steckdose1/RESULT = {"POWER":"OFF"}
14:20:00 MQT: stat/stadtweg/sonoff/s20/steckdose1/POWER = OFF
14:20:00 MQT: stat/stadtweg/sonoff/s20/steckdose1/RESULT = {"POWER":"OFF"}
14:20:00 MQT: stat/stadtweg/sonoff/s20/steckdose1/POWER = OFF
14:20:01 MQT: stat/stadtweg/sonoff/s20/steckdose1/RESULT = {"Delay":3}
14:20:01 MQT: stat/stadtweg/sonoff/s20/steckdose1/RESULT = {"POWER":"ON"}
14:20:01 MQT: stat/stadtweg/sonoff/s20/steckdose1/POWER = ON
14:20:01 MQT: stat/stadtweg/Fahrstatus = offen
14:20:02 MQT: stat/stadtweg/sonoff/s20/steckdose1/RESULT = {"T1":0,"T2":40,"T3":0,"T4":0,"T5":0,"T6":0,"T7":0,"T8":0}

Habe die allerneueste Tasmota OTA installiert