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
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
Und wie schalte ich von FHEM aus, per MQTT?
Was ist der Unterschied zwischen stat, tele und cmnd?
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
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)
https://github.com/arendst/Sonoff-Tasmota/wiki/Commands (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
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
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
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
@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.
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
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
Fehler selbst gefunden, die Readings sind jetzt mit Anfangsbuchstaben groß geschrieben. Sehr seltsam.