Tasmota, Jalousiesteuerung

Begonnen von Waldmensch, 28 Oktober 2018, 20:31:14

Vorheriges Thema - Nächstes Thema

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.

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

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"

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

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:
attr stadtweg.eg.heizung publishSet_EVENT cmnd/stadtweg/eg/heizung/EVENT

Dann kann man folgendes senden:
set stadtweg.eg.heizung EVENT halbzu=10

und im Tasmota Log sieht das dann so aus

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​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Beta-User

Vielleicht könnte das Rollo Modul helfen.
Das müssze eigentlich auch mit 2 Tasmota-Relais zusammen funktionieren.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Waldmensch

Zitat von: Gisbert am 29 Oktober 2018, 07:32:08
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

Zitat von: Gisbert am 29 Oktober 2018, 07:32:08
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 board = esp01_1m ein. Ich habe in der der user_config.h noch Domoticz und Home Assistant Discovery deaktiviert, da ich das nicht nutze// -- 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: 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 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

Zitat von: Beta-User am 29 Oktober 2018, 07:52:54
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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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

#8
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

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

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

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
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
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

Zitat von: Waldmensch am 29 Oktober 2018, 09:38:25
@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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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 ;)