Tasmota, Jalousiesteuerung

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

Vorheriges Thema - Nächstes Thema

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

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

#17
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:
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
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

Gisbert

#18
Hallo Waldmensch,

noch eine weitere Frage.

Wenn ich den letzten Fahrzustand publishen will, dann geht der folgende Befehl in der Console, z.B.:
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:
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:
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
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

Gisbert

Zitat von: Beta-User am 29 Oktober 2018, 16:18:47
.... 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
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

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

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

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

Gisbert

Hallo Beta-User,

wenn ich den publish-Befehl in eine 2. rule stecke, dann kommt die Rückmeldung in Fhem an:
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
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

Waldmensch

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


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