Tasmota auf Wemos-D1 Mini mit 4 Relais/ Wie in FHEM einbinden

Begonnen von Typ1er, 17 Februar 2019, 20:53:41

Vorheriges Thema - Nächstes Thema

Typ1er

Ich habe meine Klingel über einen Wemos D1 Mini gelöst (3 Taster, und 4 Relais angeschlossen), ich möchte gern die Klingel zu bestimmten Zeiten und bei Nachtschicht abschalten.

Als erstes habe den MQTT2_FHEM_Server definiert.
Dieser findet im Anschluss meine Klingel, und füllt ein paar Readings, so sehe ich die Relais, als Power1-4.

Ab hier habe Probleme, welches Template sollte man nutzen? Und wie schaltet man die Relais am Wemos? Muss ich die Aufsplittern auf weitere Dummys?

Internals:
   CFGFN     
   CID        DVES_476256
   DEF        DVES_476256
   DEVICETOPIC MQTT2_DVES_476256
   FUUID      5c69b74c-f33f-06ea-967a-3e133ce3b8f59173
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 25
   MQTT2_FHEM_Server_TIME 2019-02-17 20:47:34
   MSGCNT     25
   NAME       MQTT2_DVES_476256
   NR         2833
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-02-17 20:34:36   LWT             Online
     2019-02-17 20:47:34   LoadAvg         19
     2019-02-17 20:34:36   POWER           
     2019-02-17 20:47:34   POWER1          Off
     2019-02-17 20:47:34   POWER2          Off
     2019-02-17 20:47:34   POWER3          Off
     2019-02-17 20:47:34   POWER4          On
     2019-02-17 20:47:34   Sleep           50
     2019-02-17 20:47:34   SleepMode       Dynamic
     2019-02-17 20:47:34   Time            2019-02-17T20:47:34
     2019-02-17 20:47:34   Uptime          6T23:18:50
     2019-02-17 20:47:34   Vcc             3.054
     2019-02-17 20:47:34   Wifi_AP         1
     2019-02-17 20:47:34   Wifi_BSSId      F0:B0:14:52:CA:06
     2019-02-17 20:47:34   Wifi_Channel    6
     2019-02-17 20:47:34   Wifi_RSSI       100
     2019-02-17 20:47:34   Wifi_SSId       F********
Attributes:
   IODev      MQTT2_FHEM_Server
   readingList DVES_476256:tele/Klingel/LWT:.* LWT
DVES_476256:cmnd/Klingel/POWER:.* POWER
DVES_476256:stat/Klingel/RESULT:.* { json2nameValue($EVENT) }
DVES_476256:stat/Klingel/POWER4:.* POWER4
DVES_476256:stat/Klingel/POWER1:.* POWER1
DVES_476256:stat/Klingel/POWER2:.* POWER2
DVES_476256:stat/Klingel/POWER3:.* POWER3
DVES_476256:tele/Klingel/STATE:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE


Wie gehe jetzt am besten weiter vor?
LG Typ1er


Gisbert

Hallo Typ1er,

anscheinend hast du schon alle notwendigen Readings in deinem Device vorhanden.

MQTT-Devices kann man per http- oder per MQTT-Befehle schalten, zumindest wenn als Software ESPEasy oder Tasmota läuft. Schau hierzu im Fhem-Wiki und bei ESPEasy nach.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

Typ1er

Und wie schalte ich von FHEM aus, per MQTT?


Was ist der Unterschied zwischen stat, tele und cmnd?

supernova1963

Hallo Typ1er,

versuche es doch zunächst mit set <devicename> -> attrTemplate -> A_04a_tasmota_4ch_unified_text.
Dann sollte die Verwendung der tasmota MQTT Steuerung klarer werden.
Die 3 Taster werden voraussichtlich erst bei Betätigung sichtbar (dem Attribut readingsList hinzugefügt).

Stark vereinfacht:
cmnd = command, über dieses %prefix% erhält das %topic% einen Befehl (an den Wemos). Verwendung z.B. im setList Attribut.
stat/tele = results, Meldungen zu dem %topic% von dem Wemos (regelmäßig, eventbasiert, bei Neustart, ...) Verwendung: erzeugt Readings und wird z.B. im eventMap benötigt.

Ich würde (ggf. zunächst zusätzlich zum vorhandenen) 7 einzelne MQTT2_DEVICE allein wegen der Übersichtlichkeit anlegen, und, diesen die jeweils die entsprechenden readingsList Einträge (ggf. aus dem vorhandenen kopiert) sowie ggf. setList, eventmap, stateFormat usw. Attribute zuordnen.

Bitte korrigiert mich, ich bin auch eher Anfänger.

Danke,

Gernot

Gisbert

Hallo Typ1er,

ich hab gerätselt, welche Software auf deinem Wemos D1 min läuft, aber im Titel hast du es ja geschrieben, das hatte ich übersehen.
Als erstes würde ich den Thread in das richtige Board verschieben: Bastelecke --> Untergeordnete Boards: ESP8266

Für Tasmota gibt es ein sehr gutes Wiki bei github, dass du noch nicht durchgelesen hast, zumindest lassen deine Fragen darauf schließen:
https://github.com/arendst/Sonoff-Tasmota/wiki
https://github.com/arendst/Sonoff-Tasmota/wiki/Commands

stat und tele sind Status-Informationen, stat zu den Relais und tele zum ESP8266 selbst (z.B. UPTIME und dergleichen), cmnd beschreibt die Readings für das Senden von Kommandos.

Ich hänge hier mal die Defintion eines meiner Geräte, es ist ein Sonoff Dual mit 2 Relais, an. Ich nutze das Modul MQTT_DEVICE. Ob es bei den später eingeführten MQTT-Varianten genaus ist, kann ich an der Stelle nur vermuten.
defmod Heizung MQTT_DEVICE
attr Heizung IODev MyBroker
attr Heizung autoSubscribeReadings +/Heizung/+
attr Heizung publishSet_POWER1 ON OFF cmnd/Heizung/POWER1
attr Heizung publishSet_POWER2 ON OFF cmnd/Heizung/POWER2
attr Heizung subscribeReading_INFO1 tele/Heizung/INFO1
attr Heizung subscribeReading_INFO2 tele/Heizung/INFO2
attr Heizung subscribeReading_INFO3 tele/Heizung/INFO3
attr Heizung subscribeReading_LWT tele/Heizung/LWT
attr Heizung subscribeReading_POWER cmnd/Heizung/POWER
attr Heizung subscribeReading_POWER1 stat/Heizung/POWER1
attr Heizung subscribeReading_POWER2 stat/Heizung/POWER2
attr Heizung subscribeReading_RESULT stat/Heizung/RESULT
attr Heizung subscribeReading_SENSOR tele/Heizung/SENSOR
attr Heizung subscribeReading_STATE tele/Heizung/STATE
attr Heizung subscribeReading_UPTIME tele/Heizung/UPTIME


Für das Senden, d.h. das Schalten der Relais, sind diese beiden Kommandos wichtig:
attr Heizung publishSet_POWER1 ON OFF cmnd/Heizung/POWER1
attr Heizung publishSet_POWER2 ON OFF cmnd/Heizung/POWER2

Hier besteht u.U. die Schwierigkeit das Attribut genau in dieser Form anzulegen.

Das Schalten der Relais, z.B. in DOIF schaut dann so aus:
defmod Warmwasser.Zirkulation DOIF (([Heizung:System.Info] <= 5 and [?06:30-22:00]) or \
(([?Heizung:Warmwasserspeicher] - [Heizung:Warmwasseraustritt] >= 5.25) and ([?06:30-22:00|8] or [?07:30-22:00|7]) and ([?Anwesenheit.dum:state] eq "on")) or \
(([?06:30-22:00|8] or [?07:30-22:00|7]) and [+[2]:00] and ([Anwesenheit.dum:state] eq "off") and ([?Heizung:POWER1] eq "OFF")) or \
(([?06:30-22:00|8] or [?07:30-22:00|7]) and [+[1]:00] and ([Anwesenheit.dum:state] eq "on") and ([?Heizung:POWER1] eq "OFF")) or \
([06:25|8] or [07:25|7])) \
(set Heizung POWER1 on) \
DOELSEIF \
((([?Heizung:Warmwasserspeicher] - [Heizung:Warmwasseraustritt] <= 4.0) and  ([?06:30-22:00|8] or [?07:30-22:00|7])) or \
(([?06:30-22:00|8] or [?07:30-22:00|7]) and ([Anwesenheit.dum:state] eq "off")) or \
([22:01-06:24|8] or [22:01-07:24|7])) \
(set Heizung POWER1 off

Ich hab hier bewusst meine DOIF-Definition nicht eingekürzt. So kannst du sehen, wie ich verschiedene Bedingungen miteinander verknüpft habe.

Für das eigentliche Schalten dienen dann die Befehle:
set Heizung POWER1 off
set Heizung POWER1 on


Wenn noch Fragen sind, aber bitte vorher den Wiki-Artikel in github durchlesen, dann frag gerne nochmals.
Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

Gisbert

ZitatIch würde (ggf. zunächst zusätzlich zum vorhandenen) 7 einzelne MQTT2_DEVICE allein wegen der Übersichtlichkeit anlegen, und, diesen die jeweils die entsprechenden readingsList Einträge (ggf. aus dem vorhandenen kopiert) sowie ggf. setList, eventmap, stateFormat usw. Attribute zuordnen.
@supernova1963: Ich habe alle Informationen eines ESPs in einem Device, also z.B. mehrere Temperatursensoren und mehrere Relais. Ich kann mir nicht vorstellen, wie es die Übersichtlichkeit bei 10-20 ESPs erhöhen soll, wenn daraus 50-100 Devices in Fhem werden, ganz davon abgesehen, wüßte ich gar nicht, wie ich das realiseren sollte.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

Beta-User

Moin zusammen,

wie man "gesplittete" MQTT2-Devices aus einem ESP macht, kann man an dem 2-Kanaligen Tasmota-template oder dem für den Shelly4pro entnehmen, das ist kein Hexenwerk...

(Ein Tasmota-split würde ich btw. auch gerne noch haben wollen...)
Zitat von: Gisbert am 18 Februar 2019, 07:42:46@supernova1963: Ich habe alle Informationen eines ESPs in einem Device, also z.B. mehrere Temperatursensoren und mehrere Relais. Ich kann mir nicht vorstellen, wie es die Übersichtlichkeit bei 10-20 ESPs erhöhen soll, wenn daraus 50-100 Devices in Fhem werden, ganz davon abgesehen, wüßte ich gar nicht, wie ich das realiseren sollte.
Das Problem ist also weniger das Realisieren, sondern die Sinnhaftigkeit.
Es gibt namhafte Entwickler, die die gesplittete Variante bevorzugen, Rudi hat sogar was in den allg. Code eingebaut, um die hardwareseitigen "Verwandtschaftsbeziehungen" dauerhaft sichtbar halten zu können (einfach mal den template-Code ansehen...).
Gerade bei schaltbaren Devices sind die als einkanalige Einzeldevices leichter zu handhaben, es kommt aber im Ergebnis eigentlich immer darauf an, was man damit eigentlich tun will, für eine Rollladensteuerung würde ich die z.B. auch nicht vereinzeln (was ausdrücklich keine Empfehlung für den Einsatz für eine Rollladensteuerung ist!), ähnliches gilt für andere eher technisch orientierte Einsatzgebiete.

(Im übrigen ist Beispielcode für MQTT_DEVICE nicht so aufschlußreich, wenn jemand einen MQTT2_SERVER nutzt, die Syntax ist doch in Teilen anders...)

Gruß, Beta-User
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

Gisbert

Hallo Beta-User,

vielen Dank für die erklärenden Worte.
Da sich gestern niemand gefunden hat, der eine Hilfestellung geben wollte, bin ich mit meinem laienhaften Verständnis in diese Lücke gesprungen.

ZitatDas Problem ist also weniger das Realisieren, sondern die Sinnhaftigkeit.
Das scheint also Geschmackssache zu sein. Über ein mögliches Spliten bin ich noch nicht gestolpert, vielleicht kann ich es ja mal gebrauchen.

Zitat(Im übrigen ist Beispielcode für MQTT_DEVICE nicht so aufschlußreich, wenn jemand einen MQTT2_SERVER nutzt, die Syntax ist doch in Teilen anders...)
Danke für die Richtigstellung. Der Threadersteller muss dann auf andere praktische Unterstützung hoffen. Ich bin nur von mir ausgegangen, mir helfen immer konkrete Beispiele weiter.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

Beta-User

@Gisbert:
Kein Ding, und wir lernen alle jeden Tag noch was dazu, und das mit dem "associatedWith" gibt es erst seit ein paar Wochen, das muß man nicht auf dem Schirm haben...

Es gibt übrigens für mehrkanalige Devices auch ein allgemein nutzbares Modul: ReadingsProxy.
M.E. ist es aber jedenfalls für MQTT(2)-DEVICE(s) einfacher, direkt geteilte Devices anzulegen, wie von supernova1963 bereits angeregt - wenn es denn z.B. für das UI oder eine Sprachsteuerung als Einzeldevice einfacher zu handhaben ist.

Ich war früher übrigens auch ein Verfechter der "unified"-Variante (und habe es eher als umständilich empfunden, dass z.B. CUL_HM mehrere Devices für einzelne Kanäle anlegt). Zwischenzeitlich habe ich die "internen" Dinge einfach in einen Unterraum bei "Steuerung" verschoben, da stört es mich nicht mehr, wie viele Devices es im Endeffekt sind. In den "normalen" Räumen ist dann nur noch, was eben bedienbar sein soll, und da ist es fast egal, ob ein Kanal jetzt als ein Device angezeigt wird oder mehrere in einem - Tendenz geht zu ein Kanal => ein Device; da kann man dann auch einfacher mit Icons hantieren. Nur, was logisch zusammengehört, bleibt auch beeinander.

Muß man halt selbst rausfinden, was man besser findet bzw. zum jeweiligen Einsatz paßt.
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

Typ1er

Habe es hinbekommen, erst mal wieder stundenlang probiert, das senden der cmmd ging erst nicht. Nach dem es dann lief die anderen Relais zusätzlich angelegt, habe alle Einzel da ich sie über HomeKit steuern will.

Hier ein Auszug von einem:
Internals:
   CFGFN     
   CID        DVES_476256
   DEF        DVES_476256
   DEVICETOPIC MQTT2_DVES_476256_CH4
   FUUID      5c73277b-f33f-06ea-8282-915f53e39b487723
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 9
   MQTT2_FHEM_Server_TIME 2019-02-25 00:30:44
   MSGCNT     9
   NAME       MQTT2_DVES_476256_CH4
   NR         1047
   STATE      on
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-02-25 00:30:44   LoadAvg         19
     2019-02-25 00:30:44   POWER1          off
     2019-02-25 00:30:44   POWER2          off
     2019-02-25 00:30:44   POWER3          off
     2019-02-25 00:30:44   POWER4          on
     2019-02-25 00:30:44   Sleep           50
     2019-02-25 00:30:44   SleepMode       Dynamic
     2019-02-25 00:30:44   Time            2019-02-25T00:30:44
     2019-02-25 00:30:44   Uptime          14T03:02:00
     2019-02-25 00:30:44   Vcc             3.054
     2019-02-25 00:30:44   Wifi_AP         1
     2019-02-25 00:30:44   Wifi_BSSId      F0:B0:14:52:CA:06
     2019-02-25 00:30:44   Wifi_Channel    6
     2019-02-25 00:30:44   Wifi_RSSI       100
     2019-02-25 00:30:44   Wifi_SSId       Funkloch
     2019-02-25 00:28:49   state           set_on
Attributes:
   IODev      MQTT2_FHEM_Server
   alias      Klingel an/aus
   devStateIcon off:ios-off:on on:ios-on-green:off
   readingList tele/Klingel/LWT:.* LWT
  tele/Klingel/STATE:.* { json2nameValue($EVENT) }
  tele/Klingel/SENSOR:.* { json2nameValue($EVENT) }
  tele/Klingel/INFO.:.* { json2nameValue($EVENT) }
  stat/Klingel/RESULT:.* { json2nameValue($EVENT) }
DVES_476256:stat/Klingel/POWER4:.* POWER4
   room       MQTT2_DEVICE
   setList    off:noArg    cmnd/Klingel/POWER4 0
  on:noArg     cmnd/Klingel/POWER4 1
  toggle:noArg cmnd/Klingel/POWER4 2
   setStateList on off toggle
   stateFormat POWER4

Typ1er

Ich brauche mal einen Tip, Anfang der Woche hat es Sohneman geschafft den Wemos zu reseten.

Habe ein Backup auf dem Wemos eingespielt, seitdem habe ich nicht wirklich eine Verbindung, die Readings aktualisieren sich, schalten ist nicht möglich. irgendwo habe noch einen Fehler in der Konfiguration.


Internals:
   CID        DVES_476256
   DEF        DVES_476256
   DEVICETOPIC MQTT2_DVES_476256_CH3
   FUUID      5c732673-f33f-06ea-d161-a8e1b41eb338dcb0
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 10
   MQTT2_FHEM_Server_TIME 2019-05-11 20:07:23
   MSGCNT     10
   NAME       MQTT2_DVES_476256_CH3
   NR         233
   STATE      Off
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-05-11 20:00:50   FallbackTopic   cmnd/DVES_476256_fb/
     2019-05-11 20:00:50   GroupTopic      sonoffs
     2019-05-11 20:00:50   Hostname        sonoff-0598
     2019-05-11 20:00:50   IPAddress       192.168.178.46
     2019-05-11 20:04:10   LWT             Online
     2019-05-11 20:05:58   LoadAvg         19
     2019-05-11 20:00:50   Module          Generic
     2019-05-11 20:04:10   POWER           
     2019-05-11 20:07:23   POWER1          Off
     2019-05-11 20:05:58   POWER2          Off
     2019-05-11 20:05:58   POWER3          Off
     2019-05-11 20:05:58   POWER4          Off
     2019-05-11 20:00:39   RESULT_BASE     18
     2019-05-11 20:00:39   RESULT_FLAG     1
     2019-05-11 20:00:39   RESULT_GPIO_1   255
     2019-05-11 20:00:39   RESULT_GPIO_10  255
     2019-05-11 20:00:39   RESULT_GPIO_11  255
     2019-05-11 20:00:39   RESULT_GPIO_12  255
     2019-05-11 20:00:39   RESULT_GPIO_13  255
     2019-05-11 20:00:39   RESULT_GPIO_2   255
     2019-05-11 20:00:39   RESULT_GPIO_3   255
     2019-05-11 20:00:39   RESULT_GPIO_4   255
     2019-05-11 20:00:39   RESULT_GPIO_5   255
     2019-05-11 20:00:39   RESULT_GPIO_6   255
     2019-05-11 20:00:39   RESULT_GPIO_7   255
     2019-05-11 20:00:39   RESULT_GPIO_8   255
     2019-05-11 20:00:39   RESULT_GPIO_9   255
     2019-05-11 20:00:39   RESULT_NAME     Generic
     2019-05-11 20:01:01   RESULT_POWER1   Off
     2019-05-11 20:01:03   RESULT_POWER2   Off
     2019-05-11 20:00:50   RESULT_POWER3   Off
     2019-05-11 20:00:50   RESULT_POWER4   Off
     2019-05-06 20:35:53   Reset           Reset and Restarting
     2019-05-11 20:00:50   RestartReason   Software/System restart
     2019-05-11 20:05:58   Sleep           50
     2019-05-11 20:05:58   SleepMode       Dynamic
     2019-05-11 20:05:58   Time            2019-05-11T19:05:59
     2019-05-11 20:05:58   Uptime          0T00:05:17
     2019-05-11 20:05:58   Vcc             2.814
     2019-05-11 20:00:50   Version         6.5.0(release-sonoff)
     2019-05-11 20:00:50   WebServerMode   Admin
     2019-05-11 20:05:58   Wifi_AP         1
     2019-05-11 20:05:58   Wifi_BSSId      F0:B0:14:52:CA:06
     2019-05-11 20:05:58   Wifi_Channel    6
     2019-05-11 20:05:58   Wifi_Downtime   0T00:00:07
     2019-05-11 20:05:58   Wifi_LinkCount  1
     2019-05-11 20:05:58   Wifi_RSSI       100
     2019-05-11 20:05:58   Wifi_SSId       Funkloch
     2019-05-11 20:06:17   state           set_on
Attributes:
   IODev      MQTT2_FHEM_Server
   alias      Gartentor-Summer
   devStateIcon off:ios-off:on on:ios-on-green:off
   genericDeviceType switch
   homebridgeMapping On=POWER3,valueOn=on,cmdOn=on,cmdOff=off
E863F10A-079E-48FF-8F27-9C2605A29F52=Vcc,name=Voltage,factor=1000,format=FLOAT
history:size=1024
   readingList tele/Klingel/LWT:.* LWT
  tele/Klingel/STATE:.* { json2nameValue($EVENT) }
  tele/Klingel/SENSOR:.* { json2nameValue($EVENT) }
  tele/Klingel/INFO.:.* { json2nameValue($EVENT) }
  stat/Klingel/RESULT:.* { json2nameValue($EVENT) }
DVES_476256:tele/sonoff/STATE:.* { json2nameValue($EVENT) }
DVES_476256:stat/sonoff/RESULT:.* { json2nameValue($EVENT) }
DVES_476256:stat/sonoff/POWER1:.* POWER1
   room       Homekit,MQTT2_DEVICE
   setList    off:noArg    cmnd/Klingel/POWER3 0
  on:noArg     cmnd/Klingel/POWER3 1
  toggle:noArg cmnd/Klingel/POWER3 2
   setStateList on off toggle
   stateFormat POWER3

Typ1er

Fehler selbst gefunden, die Readings sind jetzt mit Anfangsbuchstaben groß geschrieben. Sehr seltsam.