Hallo an alle,
inspiriert durch unseren letzten Leipziger Stammtisch möchte ich einiges in FHEM mithilfe eines externen MQTT-Servers schalten.
Mein 4-Kanal Sonoff habe ich nach https://wiki.fhem.de/wiki/Sonoff#Sonoff_4CH_4-Kanal_Schaltmodul (https://wiki.fhem.de/wiki/Sonoff#Sonoff_4CH_4-Kanal_Schaltmodul) zum laufen gebracht:
defmod MQTT_4_1_ch1 MQTT_DEVICE
attr MQTT_4_1_ch1 IODev Mosquitto.MQTT
attr MQTT_4_1_ch1 comment https://wiki.fhem.de/wiki/Sonoff#Sonoff_4CH_4-Kanal_Schaltmodul
attr MQTT_4_1_ch1 devStateIcon on:on:off off:off:on
attr MQTT_4_1_ch1 eventMap ON:on OFF:off ON:Ein OFF:Aus
attr MQTT_4_1_ch1 icon light_ceiling
attr MQTT_4_1_ch1 publishSet ON OFF cmnd/fhem01/MQTT2_4_1pro/POWER1
attr MQTT_4_1_ch1 room 00-aussen,MQTT2_DEVICE
attr MQTT_4_1_ch1 stateFormat state
attr MQTT_4_1_ch1 subscribeReading_ tele/fhem01/MQTT2_4_1pro/STATE
attr MQTT_4_1_ch1 subscribeReading_Netz tele/fhem01/MQTT2_4_1pro/LWT
attr MQTT_4_1_ch1 subscribeReading_Power tele/fhem01/MQTT2_4_1pro/POWER1
attr MQTT_4_1_ch1 subscribeReading_sensor tele/fhem01/MQTT2_4_1pro/SENSOR1
attr MQTT_4_1_ch1 subscribeReading_sensor2 tele/fhem01/MQTT2_4_1pro/#
attr MQTT_4_1_ch1 subscribeReading_state cmnd/fhem01/MQTT2_4_1pro/POWER1
attr MQTT_4_1_ch1 webCmd Ein:Aus
setstate MQTT_4_1_ch1 off
setstate MQTT_4_1_ch1 2020-04-18 17:09:30 Netz Online
setstate MQTT_4_1_ch1 2020-04-18 17:26:18 state OFF
setstate MQTT_4_1_ch1 2020-04-18 17:26:18 transmission-state incoming publish received
defmod MQTT_4_1_ch2 MQTT_DEVICE
attr MQTT_4_1_ch2 IODev Mosquitto.MQTT
attr MQTT_4_1_ch2 comment https://wiki.fhem.de/wiki/Sonoff#Sonoff_4CH_4-Kanal_Schaltmodul
attr MQTT_4_1_ch2 devStateIcon on:on:off off:off:on
attr MQTT_4_1_ch2 eventMap ON:on OFF:off ON:Ein OFF:Aus
attr MQTT_4_1_ch2 icon light_ceiling
attr MQTT_4_1_ch2 publishSet ON OFF cmnd/fhem01/MQTT2_4_1pro/POWER2
attr MQTT_4_1_ch2 room 00-aussen,MQTT2_DEVICE
attr MQTT_4_1_ch2 stateFormat state
attr MQTT_4_1_ch2 subscribeReading_ tele/fhem01/MQTT2_4_1pro/STATE
attr MQTT_4_1_ch2 subscribeReading_Netz tele/fhem01/MQTT2_4_1pro/LWT
attr MQTT_4_1_ch2 subscribeReading_Power tele/fhem01/MQTT2_4_1pro/POWER2
attr MQTT_4_1_ch2 subscribeReading_sensor tele/fhem01/MQTT2_4_1pro/SENSOR
attr MQTT_4_1_ch2 subscribeReading_sensor2 tele/fhem01/MQTT2_4_1pro/#
attr MQTT_4_1_ch2 subscribeReading_state cmnd/fhem01/MQTT2_4_1pro/POWER2
attr MQTT_4_1_ch2 webCmd Ein:Aus
setstate MQTT_4_1_ch2 off
setstate MQTT_4_1_ch2 2020-04-18 17:09:30 Netz Online
setstate MQTT_4_1_ch2 2020-04-18 17:26:18 state OFF
setstate MQTT_4_1_ch2 2020-04-18 17:26:18 transmission-state incoming publish received
defmod MQTT_4_1_ch3 MQTT_DEVICE
attr MQTT_4_1_ch3 IODev Mosquitto.MQTT
attr MQTT_4_1_ch3 comment https://wiki.fhem.de/wiki/Sonoff#Sonoff_4CH_4-Kanal_Schaltmodul
attr MQTT_4_1_ch3 devStateIcon on:on:off off:off:on
attr MQTT_4_1_ch3 eventMap ON:on OFF:off ON:Ein OFF:Aus
attr MQTT_4_1_ch3 icon light_ceiling
attr MQTT_4_1_ch3 publishSet ON OFF cmnd/fhem01/MQTT2_4_1pro/POWER3
attr MQTT_4_1_ch3 room 00-aussen,MQTT2_DEVICE
attr MQTT_4_1_ch3 stateFormat state
attr MQTT_4_1_ch3 subscribeReading_ tele/fhem01/MQTT2_4_1pro/STATE
attr MQTT_4_1_ch3 subscribeReading_Netz tele/fhem01/MQTT2_4_1pro/LWT
attr MQTT_4_1_ch3 subscribeReading_Power tele/fhem01/MQTT2_4_1pro/POWER3
attr MQTT_4_1_ch3 subscribeReading_sensor tele/fhem01/MQTT2_4_1pro/SENSOR
attr MQTT_4_1_ch3 subscribeReading_sensor2 tele/fhem01/MQTT2_4_1pro/#
attr MQTT_4_1_ch3 subscribeReading_state cmnd/fhem01/MQTT2_4_1pro/POWER3
attr MQTT_4_1_ch3 webCmd Ein:Aus
setstate MQTT_4_1_ch3 off
setstate MQTT_4_1_ch3 2020-04-18 17:09:30 Netz Online
setstate MQTT_4_1_ch3 2020-04-18 17:26:18 state OFF
setstate MQTT_4_1_ch3 2020-04-18 17:26:18 transmission-state incoming publish received
defmod MQTT_4_1_ch4 MQTT_DEVICE
attr MQTT_4_1_ch4 IODev Mosquitto.MQTT
attr MQTT_4_1_ch4 comment https://wiki.fhem.de/wiki/Sonoff#Sonoff_4CH_4-Kanal_Schaltmodul
attr MQTT_4_1_ch4 devStateIcon on:on:off off:off:on
attr MQTT_4_1_ch4 eventMap ON:on OFF:off ON:Ein OFF:Aus
attr MQTT_4_1_ch4 icon light_ceiling
attr MQTT_4_1_ch4 publishSet ON OFF cmnd/fhem01/MQTT2_4_1pro/POWER4
attr MQTT_4_1_ch4 room 00-aussen,MQTT2_DEVICE
attr MQTT_4_1_ch4 stateFormat state
attr MQTT_4_1_ch4 subscribeReading_ tele/fhem01/MQTT2_4_1pro/STATE
attr MQTT_4_1_ch4 subscribeReading_Netz tele/fhem01/MQTT2_4_1pro/LWT
attr MQTT_4_1_ch4 subscribeReading_Power tele/fhem01/MQTT2_4_1pro/POWER4
attr MQTT_4_1_ch4 subscribeReading_sensor tele/fhem01/MQTT2_4_1pro/SENSOR
attr MQTT_4_1_ch4 subscribeReading_sensor2 tele/fhem01/MQTT2_4_1pro/#
attr MQTT_4_1_ch4 subscribeReading_state cmnd/fhem01/MQTT2_4_1pro/POWER4
attr MQTT_4_1_ch4 webCmd Ein:Aus
setstate MQTT_4_1_ch4 off
setstate MQTT_4_1_ch4 2020-04-18 17:09:30 Netz Online
setstate MQTT_4_1_ch4 2020-04-18 17:26:18 state OFF
setstate MQTT_4_1_ch4 2020-04-18 17:26:18 transmission-state incoming publish received
nur ein Problem ist noch, wenn ich ch1 schalte gehen alle 4 icons auf dieselbe Farbe. Schalten tut nur ch1. ch2 bis ch4 schalten ihre icons richtig, nur bei Druck auf ch1 schaltet 1 und alle 4 icons.
Ich finde einfach keinen Fehler.
Gerne nehme ich auch Optimierungen entgegen, oder wo ich etwas sinnfreies eingetragen habe.
Dankeschön
Ich nochmal,
ich merke gerade, die icons wecheln nur die Farbe, wenn ich über FHEM schalte. Wenn ich über die WEB-Oberfläche oder die Fernbedienung (ist ein Pro) schalte, ändern sich die Anzeige-Icons nicht.
Dankeschön
[OT]
Zitatinspiriert durch unseren letzten Leipziger Stammtisch
Interessant, war das bei dem Treffen der präferierte Weg ein MQTT-Device einzubinden oder gibts es einen Grund weshalb du jetzt auf Mosquitto setzt und nicht auf MQTT2_SERVER setzt ?
Gruß
Thomas
[/OT]
[OT]Heiko hat zuerst die "alte" Variante und danach die MQTT2 Variante gezeigt. Beim Nacharbeiten hat man dann 2 Möglichkeiten :)[\OT]
Ich würde empfehlen: Mach nochmal alles mit MQTT2 da kannst Du mit attrTemplate arbeiten und bist wahrscheinlich im Handumdrehen am Ziel.
Gruß Otto
Hallo an alle,
Ich würde gerne MQTT2 nehmen, aber habe noch keine Info gefunden, wie man das auf einem externen Server installiert. Hintergrund ist, das ich an mehreren Standorten FHEM-Installationen habe, aber alle per DS-Lite angebunden sind und ich somit über DYNDNS keine Chance habe. Ich möchte aber gerne auch Standort übergreifend steuern können.
Ich habe einen Server angemietet, mit freiem Betriebssytem und auf dem habe ich Mosquitto installiert habe. Darauf möchte ich von allen FHEM zugreifen. Wenn das auch mit MQTT2 möglich ist, sehr gerne.
Beste Grüße
Und bleibt gesund.
ach so :)
geht mit MQTT2_CLIENT - siehe meine Notiz (https://heinz-otto.blogspot.com/2019/11/mqtt-ich-muss-das-testen.html).
Abschnitt MQTT über Internet
Gruß Otto
Hi,
Du wertest bei allen das subsribe reading 2.4.2Pro/STATE aus.
Nimm mal die Zeile bei 2-4 raus. Sind die Icons dann immer noch gekoppelt?
Schalten Sie dann noch? Sonst musst Du die Power2-4 für den dtate verwenden.
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Hallo Arnd,
Zitat von: RaspiLED am 18 April 2020, 21:55:20
Hi,
Du wertest bei allen das subsribe reading 2.4.2Pro/STATE aus.
Nimm mal die Zeile bei 2-4 raus. Sind die Icons dann immer noch gekoppelt?
Schalten Sie dann noch? Sonst musst Du die Power2-4 für den dtate verwenden.
Gruß Arnd
Das
attr MQTT2_4_1_ch1 subscribeReading_ tele/fhem01/MQTT2_4_1pro/STATEhabe ich jetzt mal rausgenommen, es ändert sich nichts. Aber nach kurzer Zeit ist es wie von Geisterhand wieder da.
Gruß aus Grimma
Moin,
so, jetzt habe ich nochmal begonnen:
defmod MQTT2_4_1_ch1 MQTT_DEVICE
attr MQTT2_4_1_ch1 IODev Mosquitto.MQTT
attr MQTT2_4_1_ch1 comment https://www.tpdesign.de/sonoff-in-fhem-integrieren-tasmota-und-mqtt-device
attr MQTT2_4_1_ch1 event-on-change-reading state,status,Zeit
attr MQTT2_4_1_ch1 eventMap on:an off:aus
attr MQTT2_4_1_ch1 icon light_ceiling
attr MQTT2_4_1_ch1 publishSet ON OFF toggle cmnd/fhem01/MQTT2_4_1pro/POWER1
attr MQTT2_4_1_ch1 room 00-aussen,MQTT2_DEVICE
attr MQTT2_4_1_ch1 stateFormat state
attr MQTT2_4_1_ch1 subscribeReading_ tele/fhem01/MQTT2_4_1pro/STATE
attr MQTT2_4_1_ch1 subscribeReading_online tele/fhem01/MQTT2_4_1pro/LWT
attr MQTT2_4_1_ch1 subscribeReading_sensor tele/fhem01/MQTT2_4_1pro/SENSOR
attr MQTT2_4_1_ch1 subscribeReading_sensor2 tele/fhem01/MQTT2_4_1pro/#
attr MQTT2_4_1_ch1 subscribeReading_state stat/fhem01/MQTT2_4_1pro/POWER1
attr MQTT2_4_1_ch1 subscribeReading_status stat/fhem01/MQTT2_4_1pro/STATE1
attr MQTT2_4_1_ch1 webCmd an:aus
setstate MQTT2_4_1_ch1 aus
setstate MQTT2_4_1_ch1 2020-04-19 09:40:55 online Online
setstate MQTT2_4_1_ch1 2020-04-18 15:54:32 sensor {"Time":"2020-04-18T14:54:31","ENERGY":{"TotalStartTime":"2019-12-10T14:13:05","Total":0.010,"Yesterday":0.000,"Today":0.010,"Period":0,"Power":4,"ApparentPower":11,"ReactivePower":10,"Factor":0.39,"Voltage":281,"Current":0.040}}
setstate MQTT2_4_1_ch1 2020-04-19 09:51:45 state off
setstate MQTT2_4_1_ch1 2020-04-19 09:55:25 transmission-state incoming publish received
Klappt. Auch die Fernbedienung des pro. Wird auch alles richtig angezeigt.
Danach
copy MQTT2_4_1_ch1 MQTT2_4_1_ch2
und die Attribute:
publishSet
subscribeReading_state
subscribeReading_status
jeweils auf 2 gesetzt.
defmod MQTT2_4_1_ch2 MQTT_DEVICE
attr MQTT2_4_1_ch2 IODev Mosquitto.MQTT
attr MQTT2_4_1_ch2 comment https://www.tpdesign.de/sonoff-in-fhem-integrieren-tasmota-und-mqtt-device
attr MQTT2_4_1_ch2 event-on-change-reading state,status,Zeit
attr MQTT2_4_1_ch2 eventMap on:an off:aus
attr MQTT2_4_1_ch2 icon light_ceiling
attr MQTT2_4_1_ch2 publishSet ON OFF toggle cmnd/fhem01/MQTT2_4_1pro/POWER2
attr MQTT2_4_1_ch2 room 00-aussen,MQTT2_DEVICE
attr MQTT2_4_1_ch2 stateFormat state
attr MQTT2_4_1_ch2 subscribeReading_ tele/fhem01/MQTT2_4_1pro/STATE
attr MQTT2_4_1_ch2 subscribeReading_online tele/fhem01/MQTT2_4_1pro/LWT
attr MQTT2_4_1_ch2 subscribeReading_sensor tele/fhem01/MQTT2_4_1pro/SENSOR
attr MQTT2_4_1_ch2 subscribeReading_sensor2 tele/fhem01/MQTT2_4_1pro/#
attr MQTT2_4_1_ch2 subscribeReading_state stat/fhem01/MQTT2_4_1pro/POWER2
attr MQTT2_4_1_ch2 subscribeReading_status stat/fhem01/MQTT2_4_1pro/STATE2
attr MQTT2_4_1_ch2 webCmd an:aus
setstate MQTT2_4_1_ch2 aus
setstate MQTT2_4_1_ch2 2020-04-19 09:40:55 online Online
setstate MQTT2_4_1_ch2 2020-04-19 09:51:45 state off
setstate MQTT2_4_1_ch2 2020-04-19 10:00:24 transmission-state incoming publish received
Schalten alles wieder ok. Nur die Farbe der Icons: bei Betätigung 1 ändert sich Farbe (nur Farbe, nicht das Relais) bei ch1 und ch2.
Bei Betätigung ch2 nur 2.
Nun wird es interessant:
copy MQTT2_4_1_ch2 MQTT2_4_1_ch3
und die Attribute:
publishSet
subscribeReading_state
subscribeReading_status
jeweils auf 3 gesetzt.
defmod MQTT2_4_1_ch3 MQTT_DEVICE
attr MQTT2_4_1_ch3 IODev Mosquitto.MQTT
attr MQTT2_4_1_ch3 comment https://www.tpdesign.de/sonoff-in-fhem-integrieren-tasmota-und-mqtt-device
attr MQTT2_4_1_ch3 event-on-change-reading state,status,Zeit
attr MQTT2_4_1_ch3 eventMap on:an off:aus
attr MQTT2_4_1_ch3 icon light_ceiling
attr MQTT2_4_1_ch3 publishSet ON OFF toggle cmnd/fhem01/MQTT2_4_1pro/POWER3
attr MQTT2_4_1_ch3 room 00-aussen,MQTT2_DEVICE
attr MQTT2_4_1_ch3 stateFormat state
attr MQTT2_4_1_ch3 subscribeReading_ tele/fhem01/MQTT2_4_1pro/STATE
attr MQTT2_4_1_ch3 subscribeReading_online tele/fhem01/MQTT2_4_1pro/LWT
attr MQTT2_4_1_ch3 subscribeReading_sensor tele/fhem01/MQTT2_4_1pro/SENSOR
attr MQTT2_4_1_ch3 subscribeReading_sensor2 tele/fhem01/MQTT2_4_1pro/#
attr MQTT2_4_1_ch3 subscribeReading_state stat/fhem01/MQTT2_4_1pro/POWER3
attr MQTT2_4_1_ch3 subscribeReading_status stat/fhem01/MQTT2_4_1pro/STATE3
attr MQTT2_4_1_ch3 webCmd an:aus
setstate MQTT2_4_1_ch3 aus
setstate MQTT2_4_1_ch3 2020-04-19 09:40:55 online Online
setstate MQTT2_4_1_ch3 2020-04-19 09:48:05 state off
setstate MQTT2_4_1_ch3 2020-04-19 10:00:24 transmission-state incoming publish received
Bei Betätigen ch1 ändert sich Farbe ch1 und ch2, ch3 nicht - prima.
aber:
Bei Betätigen ch2 ändert sich Farbe ch2 und ch3, ch1 nicht ???.
als nächstes:
copy MQTT2_4_1_ch3 MQTT2_4_1_ch4
und die Attribute:
publishSet
subscribeReading_state
subscribeReading_status
jeweils auf 4 gesetzt.
defmod MQTT2_4_1_ch4 MQTT_DEVICE
attr MQTT2_4_1_ch4 IODev Mosquitto.MQTT
attr MQTT2_4_1_ch4 comment https://www.tpdesign.de/sonoff-in-fhem-integrieren-tasmota-und-mqtt-device
attr MQTT2_4_1_ch4 event-on-change-reading state,status,Zeit
attr MQTT2_4_1_ch4 eventMap on:an off:aus
attr MQTT2_4_1_ch4 icon light_ceiling
attr MQTT2_4_1_ch4 publishSet ON OFF toggle cmnd/fhem01/MQTT2_4_1pro/POWER4
attr MQTT2_4_1_ch4 room 00-aussen,MQTT2_DEVICE
attr MQTT2_4_1_ch4 stateFormat state
attr MQTT2_4_1_ch4 subscribeReading_ tele/fhem01/MQTT2_4_1pro/STATE
attr MQTT2_4_1_ch4 subscribeReading_online tele/fhem01/MQTT2_4_1pro/LWT
attr MQTT2_4_1_ch4 subscribeReading_sensor tele/fhem01/MQTT2_4_1pro/SENSOR
attr MQTT2_4_1_ch4 subscribeReading_sensor2 tele/fhem01/MQTT2_4_1pro/#
attr MQTT2_4_1_ch4 subscribeReading_state stat/fhem01/MQTT2_4_1pro/POWER4
attr MQTT2_4_1_ch4 subscribeReading_status stat/fhem01/MQTT2_4_1pro/STATE4
attr MQTT2_4_1_ch4 webCmd an:aus
setstate MQTT2_4_1_ch4 aus
setstate MQTT2_4_1_ch4 2020-04-19 09:40:55 online Online
setstate MQTT2_4_1_ch4 2020-04-19 10:05:09 state off
setstate MQTT2_4_1_ch4 2020-04-19 10:05:24 transmission-state incoming publish received
Bei Betätigen ch3 ändert sich Farbe ch3 und ch4, ch1 sowie ch2 nicht.
aber:
Bei Betätigen ch4 ändert sich nur die Farbe ch4.
Ich scheine beim 1. Kopieren (ch1 auf ch2) einen Fehler mitzuschleppen, der beim nachfolgenden Kopieren (ch2 auf ch3) weg/anders ist.
Beim ersten Versuch hatte ich ch1 direkt jeweils auf 2, 3 und 4 kopiert. Daher änderten sich bei Betätigung ch1 alle drei anderen.
Es ist bestimmt irgendein Fehler meinerseits, aber ich sehe den Wald vor lauter Bäumen nicht.....
Dankeschön
Moin Otto,
Zitat von: Otto123 am 18 April 2020, 21:07:40
ach so :)
geht mit MQTT2_CLIENT - siehe meine Notiz (https://heinz-otto.blogspot.com/2019/11/mqtt-ich-muss-das-testen.html).
Abschnitt MQTT über Internet
Gruß Otto
Das schaue ich mir dann mal an. Nur mal eine Frage vorweg, ist dann an den anderen Standorten auch ein FHEM notwendig? So wie ich es hier möchte, ist, das ich in meinen Häusern sozusagen MQTT-Geräte einbauen kann, die sich nur über einen Internetzugang mit dem MQTT oder MQTT2 "unterhalten".
Mein gemieteter Server ist der Einzige, der von aussen zugängig ist. Kann ich auf diesem gemieteten Server ohne FHEM (oder mit?) einen MQTT2 installieren? Ich ging bisher davon aus, das MQTT2 nur mit FHEM auf dem selben Rechner funzt.
Sonnige Grüße aus Grimma
Moin,
der MQTT2_CLIENT verbindet sich mit einem fremden MQTT Server und stellt den IO für FHEM dar. Das macht genau das was Du willst.
Bei MQTT2_DEVICE macht es die Sache mit den Templates aus meiner Sicht viel leichter.
Gruß Otto
Hallo Otto,
Super, läuft prima. Ein grosses Dankeschön. Bestens.
Eine Frage noch, die Templates sind 10 Stück? Ich probiere gerade noch Deine geflashten (Danke nochmals) Gosubs. So ein Template auch zur Messung ist (noch) nicht dabei?
Viele Grüße aus Grimma
Zwei stellen mit Templates, die fürs fhem device und die für tasmota.
Du hast die 16 A Variante da brauchst Du was extra in tasmota. Schau in meinem Blog, anderer Artikel etwas früher. Habe ich extra mit/für deine Dose erweitert.
Moin,
Du meinst:
1. Menüpunkt: Configure Module
Gosund SP1 - direkt als SP1 vorhanden
Gosund SP111 - als BlitzWolf SHP konfigurieren
SP111 neue Version (3450 Watt) - Für diese Dose braucht man ein Template!
1.1 Menüpunkte: Configure Other / Template
Ich habe hier ein Template gefunden:
Rot Wlan, Blau Status
{"NAME":"Gosund SP111 2","GPIO":[56,0,57,0,132,134,0,0,131,17,0,21,0],"FLAG":0,"BASE":18}
Rot Status, Blau Wlan
{"NAME":"Gosund SP111 2","GPIO":[57,0,56,0,132,134,0,0,131,17,0,21,0],"FLAG":0,"BASE":45}
Super, Dankeschön, läuft alles wie gewünscht.
Ich wünsche eine schöne Woche, und bleibt gesund.
Grüße aus Grimma
genau :) :D ;D
Schöne Woche
Otto
Moin,
muss schon wieder nerven... sorry.
Ich versuche gerade meinen 2. Gosund einzubinden.
Das Device wird mit autocreate gefunden.
Als Template nehme ich tasmota_basic oder tasmota_basic_state_power1
dann werde ich gefragt:
Replace
CMNDTOPIC: with the Command topic prefix, without trailing /
TELETOPIC: with the info topic prefix, without trailing /
STATTOPIC: with the ack topic prefix, without trailing /
und
Replace
CMNDTOPIC: with the Command topic prefix, without trailing /
hier komme ich nicht weiter, das kann ich nicht deuten.
beim MQTT.fx kommt z.B. an:
stat/fhem01/VDR_1/POWER/on
Dankeschön
Am einfachsten sorgst du erst dafür, dass eine LWT-Message eingeht; die wird bei attrTemplate@Tasmota nämlich dafür genutzt, diese drei Parameter aufzulösen, nach denen du hier gefragt wirst.
Kurz: Erst den ESP nochmal booten...
Es kann auch sein, dass du über eine "Spezialität" von MQTT2_CLIENT stolperst, weil der nicht wissen kann, von welchem Device die Message ursprünglich kam. Dazu gibt es ein "Hilfstemplate", siehe die Hinweisbox hier: https://wiki.fhem.de/wiki/MQTT2_CLIENT#Anwendung
Du musst auch darauf achten, dass der topic in tasmota unikat ist! Leider ist da die Voreinstellung bescheuert: Da steht einfach tasmota drin, damit laufen dann alle Dosen synchron :)
Siehe Anhang :) so mach ich das.
@Otto:
Das scheint hier nicht das Problem zu sein, zumindest sieht das hier so aus, als wäre was individuelles (VDR_1) vergeben:
stat/fhem01/VDR_1/POWER/on
Die attrTemplates sollten auch mit dieser Struktur klarkommen, allerdings vermute ich, dass es noch kein "general_bridge"-Device gibt und daher alles ungeordnet auf das eine "Sammeldevice" läuft.
Hier wären lists (RAW ist hier besser) der Devices hilfreich, so ist es noch etwas "Glaskugel" (ist kein Vorwurf).
@Otto
Ich mein das ist seit kurzem die default-Einstellung das die CID an tasmota angehängt ist.
Aha ok interessant :) ich nehme das bescheuert zurück ;D
@Beta-User Du bist auf der richtigen Richtung FHEM-User22 hat ja einen MQTT2_CLIENT an einem externen mqtt Server da sind die Dinge ein klein wenig anders. Aber autocreate hatte er ja gemacht.
Wahrscheinlich wirklich einfach nochmal die Dose "booten"?
Ich hatte das irgendwie auch schon mal ganz hartnäckig. Da ging dann auch simpel: Device löschen und nochmal anlegen lassen (Dose booten)
Gruß Otto
Zitat von: Otto123 am 21 April 2020, 11:42:33
Aha ok interessant :) ich nehme das bescheuert zurück ;D
Nun ja, es war nicht grade glücklich, dass es solange gedauert hat, bis es (scheinbar) geändert wurde...
Zitat
@Beta-User Du bist auf der richtigen Richtung FHEM-User22 hat ja einen MQTT2_CLIENT an einem externen mqtt Server da sind die Dinge ein klein wenig anders. Aber autocreate hatte er ja gemacht.
Wahrscheinlich wirklich einfach nochmal die Dose "booten"?
Jein. Man sollte bei einer "CLIENT"-Konstruktion mMn. immer ein "Sortierdevice" dazwischenschalten (s.u. a)) und sich neuerdings am besten auch noch etwas um "ignoreRegexp" am IO kümmern, (s.u. b)) ;) .
Zitat
Ich hatte das irgendwie auch schon mal ganz hartnäckig. Da ging dann auch simpel: Device löschen und nochmal anlegen lassen (Dose booten)
Nochmal: Das Problem ist, dass die CID@m2-CLIENT "irreführend" ist, da "getauscht".
a) "Mein" Sortier-Template (MQTT2_CLIENT_general_bridge) wird hier auch nicht direkt weiterhelfen, weil das für "unveränderte" Topic-Trees gemacht ist. Hier müßte man also statt des 2. Teils des Trees den 3. "abgreifen", was aber als "Trockenübung" ohne Bezugspunkt für den TE wenig erhellend ist.
Wir brauchen also eine RAW-Definition von so einem Gerät, dann können wir das ggf. zur allg. Weiterbildung zusammen ändern ;) .
b) Will man in diesen verteilten Konstruktionen (für autocreate) "unsinnige" Messages aussortieren, kann man neuerdings eine ignoreRegexp an MQTT2_(SERVER|CLIENT) setzen. Diese Idee hatte zwei Anwendungsfälle (="unsinnige Messages") im Auge:
1. die für uns nutzlosen "autodiscovery"-Messages für homeassistant und
2. "Befehle von dritter Seite" = z.B. cmnd-Anweisungen aus FHEM-Instanz 1 an Gerät xyz, die man typischerweise nicht in FHEM-Instanz 2 irgendwie auswerten will (es reicht, wenn das Zielgerät die Bestätigung sendet, dass sie das erhalten und verarbeitet hat).
Würde mich freuen, wenn wir das hier einmal exemplarisch darstellen könnten, wie diese Dinge zusammenspielen sollten ;) . Vielleicht kann ich dann auch b) 2. "vertemplaten"...
Einverstanden?
Ja gern. Ich muss das erst mal sacken lassen und mir in Ruhe anschauen. Ich melde mich zurück :)
Zitat von: Otto123 am 21 April 2020, 12:10:07
Ja gern. Ich muss das erst mal sacken lassen und mir in Ruhe anschauen. Ich melde mich zurück :)
Klar. Scheint auf den ersten Blick recht abstrakt zu sein, aber wenn du "live" austesten kannst, wird sich vermutlich der Nebel schnell lichten.
Falls du verwertbare Erkenntnisse hast/generieren magst: Von mir aus kann das bridgeRegexp-Ding gleich in die "Praxisbeispiele" (ganz oben) mir rein und ein ignoreRegexp-template-Vorschlag für "m2-IO" wäre die Krönung!
(Was mir eigentlich vorschweben würde, wäre die Möglichkeit, das nach und nach _individuell_ ergänzen zu können - "cmnd" muß ja z.B. nicht bei jedem user an derselben Stelle stehen, und über die Shellys haben wir noch gar nicht gesprochen... Man müßte also die einzelnen Zeilen (z.B. aus einem Tasmota-Gerät raus) ermitteln, schauen, ob die spezielle-Topic-Tree-Struktur schon erfaßt ist, und ggf. ergänzen. (Code, um bestehende Attributwerte zu übernehmen und ggf. zu ergänzen gab's mind. übergangsweise mal in den Sprachsteuerungstemplates...).
Have fun :P .
Zitat von: TomLee am 21 April 2020, 12:20:17
sicher
Ist ja gut... Wollte es nicht verifizieren, war nicht irgendwie wertend gemeint ;D .
ganz sicher :)
Zitat von: Otto123 am 21 April 2020, 11:26:09
Du musst auch darauf achten, dass der topic in tasmota unikat ist! Leider ist da die Voreinstellung bescheuert: Da steht einfach tasmota drin, damit laufen dann alle Dosen synchron :)
Siehe Anhang :) so mach ich das.
Hallo,
es ist also nicht gut, in alle Geräte bei topic fhem01 einzutragen und dann beim full_topic den Gerätenamen?
Grüße
Nun ja, eigentlich ist es wohl anders rum gedacht... Aber im Ergebnis sollte auch diese Variante ja eindeutige Pfade je Gerät geben - unterstellt, das VDR1 ist "unique". Dann wäre es zwar "falsch", aber ok für FHEM.
Aus dem Ergebnis hätte ich eher abgeleitet, dass du %prefix% um "/fhem01" erweitert hattest...
Moin,
wenn ich zu sehr auf den Senkel gehe, bitte sagen.....
Wie wären den dann meine Einstellungen richtiger?
Ich habe das hier mit probiert und mich daran gehalten:
https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway+-+Alle+FHEM-Readings+weitergeben (https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway+-+Alle+FHEM-Readings+weitergeben)
Internals:
FUUID 5e8195ab-f33f-6033-16ce-e1d84837193f5c37
IODev Mosquitto.MQTT
NAME mqttGeneric
NR 328
NTFY_ORDER 50-mqttGeneric
STATE ???
TYPE MQTT_GENERIC_BRIDGE
devspec .*
prefix mqtt
READINGS:
2020-04-20 17:08:44 device-count 0
2020-04-20 17:08:42 incoming-count 0
2020-04-22 09:01:12 outgoing-count 807112
2020-04-22 09:01:12 transmission-state outgoing publish sent
2020-04-20 17:08:42 updated-reading-count 0
2020-04-20 17:08:42 updated-set-count 0
devices:
:global:
:defaults:
pub:qos 0
pub:retain 1
sub:qos 2
sub:retain 1
:publish:
*:
mode R
topic {"fhem01/$device/$reading"}
globalDeviceExcludes:
globalReadingExcludes:
globalTypeExcludes:
pub:
FHEMWEB *
Global *
MQTT transmission-state
MQTT_BRIDGE transmission-state
MQTT_DEVICE transmission-state
MQTT_GENERIC_BRIDGE *
telnet *
sub:
FHEMWEB *
Global *
MQTT transmission-state
MQTT_BRIDGE transmission-state
MQTT_DEVICE transmission-state
MQTT_GENERIC_BRIDGE *
telnet *
message_ids:
subscribe:
subscribeExpr:
subscribeQos:
Attributes:
IODev Mosquitto.MQTT
comment https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway+-+Alle+FHEM-Readings+weitergeben
FHEM-Dienststatus per MQTT publishen
Der Status von FHEM selbst kann auf diese Weise an den Broker übergeben werden:
attr Mosquitto.MQTT on-connect retain:1 {Log3("mqtt",3,"connected to MQTT server");;1} fhem01/connection/status connected
attr Mosquitto.MQTT on-disconnect retain:1 {Log3("mqtt",3,"disconnected from MQTT server");;1} fhem01/connection/status disconnected
attr Mosquitto.MQTT room MQTT2_DEVICE,y-Devices,y-MQTT
globalDefaults sub:qos=2 pub:qos=0 retain=1
globalPublish *:topic={"fhem01/$device/$reading"}
room MQTT2_DEVICE,y-MQTT
um alles von meinem FHEM im MQTT zu haben.
Dort kommt es so an:
fhem01/handy_XY01/presence
Vom anderen FHEM:
fhem03/sysmon/cpu_temp
Daher habe ich es auch so in meine Tasmota-Dosen eingetragen, das dieses Prinzip auch so ankommt.
Also: Hauptstandort/Gerät/Aktion
Wie mache ich es besser?
Dankeschön
Moin,
vorab: ich kann das auch nur vom theoretischen Standpunkt aus beurteilen...
Grundsätzlich: Die Topic-Struktur an sich kommt mir sinnvoll vor, ich hätte den "fhem0x"-Anteil nur eben eher in "Full topic" untergebracht und nicht in %topic%. Aber wenn es so funktioniert, sollte es auch ok sein (es muß nur eindeutig sein, was ja der Fall zu sein scheint, und die cmnd's müssen eben auch (eindeutig) ankommen, wovon ich aber im Moment auch ausgehe).
Es sollte auch "ok" sein, gleich die Geräte, die direkt MQTT sprechen, so zu konfigurieren, dass "der richtige Standort" dort vercoded ist; das mit der MQTT_GENERIC_BRIDGE (MGB) betrifft ja eher nur Geräte, die nicht von sich aus "MQTT können". Dass es durch die Einstellungen an der MGB aber ggf. "gedoppelt" wird, ist m.E. nicht ganz optimal (vermutlich verhindert die MGB das selbst). (An sich hätte ich vermutet, dass das globalPublish nicht mehr funktioniert, ich meine mich zu erinnern, dass Hexenmeister da irgendwas ändern wollte; kann aber auch den "subscribe"-Teil betreffen).
Vielleicht eine doofe Frage: der Tasmota spricht mit demselben Broker wie die MGB's, es läuft also zentral alles über diesen einen Server? Oder gibt es je lokal einen und das wird dann über die MGB's an den zentralen "externen" weitergeleitet? Und wie hast du dann die Tasmota-Geräte in den anderen FHEM's eingerichtet?
Hallo,
kann erst heute gegen Abend antworten. Vorab, was meinst Du mit MGB (bin bisschen im Streß)?
Beste Grüße
@Beta-User Er hat doch gar keine MQTT_GENERIC_BRIDGE (MGB) !? Er hat doch nur den MQTT2_CLIENT
Zitat von: Otto123 am 22 April 2020, 10:23:10
@Beta-User Er hat doch gar keine MQTT_GENERIC_BRIDGE (MGB) !? Er hat doch nur den MQTT2_CLIENT
? Er hat doch oben eine DEF gepostet...! Und nach dem "count" zu gehen, sendet die auch fleißig...
Zitat von: FHEM-User22 am 22 April 2020, 09:08:22
Internals:
[...] TYPE MQTT_GENERIC_BRIDGE
[...]
2020-04-22 09:01:12 outgoing-count 807112[...]
Und der m2_CLIENT ist doch nur in der einen "Zielinstallation" vorhanden, oder bin ich jetzt auf dem Holzweg?
Zitat von: FHEM-User22 am 22 April 2020, 09:08:22
wenn ich zu sehr auf den Senkel gehe, bitte sagen.....
An sich nicht, aber du solltest bitte das Gesamtbild so pinseln, dass "alle auf Ballhöhe" sind (dich eingeschlossen). Bin zugegebenermaßen irritiert, dass du ein list postest, meine Antwort liest (in der die Abkürzung extra genannt ist) und dann die Frage kommt. Da scheint dir auch nicht so klar zu sein, was die MQTT_GENERIC_BRIDGE denn eigentlich für eine Funktion hat. Das bitte vorab vergegenwärtigen ;) .
Oh ja - jetzt bin ich auch verwirrt. Da meine ich auch: Zwischendecke einziehen und nochmal den Stand skizzieren :)
Mein letzter Stand war zentraler MQTT , MQTT2_CLIENT und Du hattest ihm dort MQTT2_CLIENT_general_bridge und ignoreRegexp empfohlen. Ich dachte das wollten wir in Ruhe aufarbeiten :)
Es gibt einfach zu viele Möglichkeiten :)
Hallo,
oh Mann, da habe ich mit meinem Nichtwissen ja was angerichtet.
Was gebt Ihr mir jetzt als Hausaufgabe auf? Gibts da irgend was zum nachlesen? Was kann ich liefern? Alles was ich bisher gefunden habe, war (für mich) nur bruchstückhaft und ich fand schwer Zusammenhang.
Erstmal nochmal meine Ausgangssituation: Ich hätte gerne die MQTT-Dosen direkt mit meinem Mosquitto-Server verbunden. Von dort sollen sich die FHEM oder andere "MQTT-Bediener" (auf mehrere Grundstücke verteilt) "bedienen" und auch jeweils schalten können.
Direkt, da ich nicht an jedem Standort einen extra-FHEM haben möchte, der auch wiederum nur über MQTT mit der Aussenwelt kommunizieren kann.
Hintergrund ist, das ich die Internetzugänge nicht über DYNDNS anbinden kann und somit auch nicht von ausserhalb darauf zugreifen kann. Es sind alles DS-Lite Anschlüsse. Daher bin ich der Meinung, das ich zumindest einiges über einen gemieteten Server mit Mosquitto abdecken kann.
Wenn ich auf dem falschen Pferd sitze, bin gerne für neue Ideen offen.
Dankeschön für Eure Hilfeund sorry für mein nerven....
...aus meiner Sicht alles gut, da wurde nichts "angerichtet"... ;D
Faktenlage also:
1. Es gibt nur den einen Server (mosquitto, irgendwo im Internet).
2. An den senden alle ESP-basierten Geräte direkt;
3. alle anderen FHEM-Devices sind via MQTT_GENERIC_BRIDGE "ver-mqtt-t" (es gibt also in jeder der FHEM-Instanzen so eine MGB).
Du hast jetzt "irgendwo in einem der FHEM's" den Versuch gestartet, eines der "nativen" MQTT-Geräte (den 4Ch-Sonoff) nicht mehr "klassisch" mit MQTT_DEVICE anzubinden (oder Dummy+MGB), sondern mit MQTT2_DEVICE.
Daraus ergeben sich für mich ein paar Fragen bzw. offene Flanken:
- gibt es weitere "native" MQTT-Geräte, die bereits eingebunden sind? Wenn ja: Bitte ein Beispiel und auch Info zur Frage, ob das dann in allen FHEM-Instanzen als MQTT_DEVICE angelegt war.
- Wie sind dann die per MGB "ver-mqtt-ten" Devices in anderen Instanzen eingebunden? Auch als MQTT_DEVICE oder dort Dummy+MBG?
- Das Konzept sieht vor, dass alle Info in allen Instanzen verfügbar ist und auch alles von überall her geschaltet werden kann. Kommt mir zum einen sehr offen vor, und zum anderen werden dadurch eine ganze Menge mehr Daten kreuz und quer erzeugt und übermittelt (und geloggt?) als notwendig, aber das sind eher Fragen, die mit Datenschutz und Absicherung zu tun haben. Zumindest letzteres sollte so oder so richtig gemacht werden, egal, ob jetzt nur ein Device schaltbar gemacht wird oder viele.
- Wie gehst du mit Verbindungsabbrüchen um? (Konkret: Ist der Mosquitto nicht zu erreichen, kannst du die Tasmota-Dosen nur noch lokal schalten, z.B. über das Web-Interface des jeweiligen ESP. Oder irre ich mich?).
Da mit letzerer Frage latent auch die Frage im Raum schwebt, wie es anders gehen könnte:
- Man kann auch mit mehreren MQTT-Servern arbeiten, also z.B. für jede "FHEM-Insel" einen MQTT2_SERVER aktivieren (z.B. Port 1884). Da senden alle "nativen" MQTT-Geräte ihre Daten hin.
Vorteile:
-- alles ist zumindest lokal verfügbar, selbst wenn der mosquitto weg ist.
-- Man kann die "nach außen" gehenden Daten auf das beschränken, was wirklich "kreuzweise" verfügbar sein soll/muß.
- Diesen "externen" Kanal kann man weiter über die MGB (Port 1883) machen, ich würde dann aber nicht mehr "alles" rauspusten, sondern nur noch das, was auch wirklich "extern" verfügbar sein soll...
Soweit nachvollziehbar?
Zitatwerden dadurch eine ganze Menge mehr Daten kreuz und quer erzeugt und übermittelt (und geloggt?) als notwendig
Nicht, wenn die Subscriptions richtig spezifiziert sind.
Zitat von: rudolfkoenig am 22 April 2020, 17:22:42
Nicht, wenn die Subscriptions richtig spezifiziert sind.
Jein. Wenn ich das richtig sehe, gehen aus allen FHEM-Instanzen über die MQTT_GENERIC_BRIDGES alle Daten erst mal raus (=kreuz). Die Subscriptions bestimmen dann, ob sie auch "quer" gehen. Da aber lt. Beschreibung alles von überall schaltbar sein soll, klingt das nicht nach Datensparsamkeit bei den subscriptions, sondern erst mal nach der großen Freude, dass es (überhaupt) "klappt".
Meine Anmerkung ging aber auch in die Richtung, hier ggf. mehr Sorgfalt bei der Frage walten zu lassen, was wo zu sehen sein soll, also die subscriptions mal näher anzusehen, damit die Freude auch länger währt...
Ich dachte die MQTT_GENERIC_BRIDGES braucht man nicht?
Ich würde es nur mit einem MQTT2_CLIENT machen - oder geht das nicht?
No. MGB kann mit allen drei IO-Modulen und hat einen ganz anderen Zweck.
Ich habe jetzt mal folgendes Setup probiert:
FHEM und MQTT Instanzen
- mqtt broker in der cloud (cloudmqtt)
- MQTT2_CLIENT FHEM Instanz1 verbunden mit cloudmqtt standard, autocreate nicht aktiv
- MQTT2_SERVER intern FHEM Instanz2
2 Geräte
- shellyplug s verbunden zu MQTT2_SERVER intern FHEM Instanz2, MQTT2_DEVICE vorhanden mit autocreate und attrTemplate eingerichet
- gosund sp111 mit tasmota verbunden zu MQTT2_SERVER intern FHEM Instanz2, MQTT2_DEVICE vorhanden mit autocreate und attrTemplate eingerichet
Umzug in die cloud
- Beide Definitionen aus Instanz2 kopiert, IODev geändert auf den MQTT2_CLIENT, in Raw Definition der Instanz1 ausgeführt.
- shellyplug s und gosund sp111 verbunden zu cloudmqtt
Fertig - läuft :)
@Beta-User Ist das so ein möglicher sinnvoller Weg? Umständlich - aber ohne zusätzliche Devices und ohne Gefahr was falsch zu machen mit "kreiselnden" MQTT Messages.
Gruß Otto
Zitat von: Otto123 am 26 April 2020, 21:33:37
@Beta-User Ist das so ein möglicher sinnvoller Weg? Umständlich - aber ohne zusätzliche Devices und ohne Gefahr was falsch zu machen mit "kreiselnden" MQTT Messages.
Für reine MQTT-Geräte (hier: Tasmota-firmware) sollte das passen; ist ja im Prinzip genau das, was ich bei den "wie stelle ich um?"-Threads gerne schreibe.
Aber hier sind bei den Anforderungen des TE noch zwei "Besonderheiten" drin:
Zum einen sind auch ein paar "nicht-native-MQTT-" Geräte im Spiel, jedenfalls deutet die Existenz der MQTT_GENERIC_BRIDGE stark in diese Richtung.
Zweitens war meine Frage ja auch in die Richtung, wie man die Tasmota-Geräte auch vom lokalen FHEM aus schaltbar hält, wenn der zentrale Broker weg ist (insbesondere: Mobilfunknetz fällt aus). Ist bei deinem Vorschlag völlig offen.
Das kann man m.E. nur lösen, wenn man entweder
- den MQTT-Weg "doppelt" (also via MGB noch einen zweiten Pfad zu einem ANDEREN Broker generiert, auf den jeweils Status-updates erfolgen bzw. auf dem Schaltanweisungen erwartet werden, oder
- die Broker "brückt". Das kenne ich nur vom "vorbeilesen" aus der Mosquitto-Welt... Was ich dazu verstanden habe: Man kann einen Mosquitto auch als "MQTT-Client" eines anderen Broker konfigurieren und so Nachrichten weiterleiten. Müßte mich da auch eindenken/einlesen, aber mMn. wäre das "der Königsweg" für solche Installationen:
Jeweils einen lokalen MQTT2_SERVER, und am Mosquitto dann die Entscheidung, was jeweils (nur!) abboniert wird bzw. weitergeleitet an eine andere Instanz.
Kann aber nicht sagen, inwieweit M2_Server das unterstützt... (_sollte_ aber gehen, wenn die Subscriptions und "Publish-Forwards" auf der zentralen Mosquitto-Seite konfiguriert werden können).
Ziemlich abstrakt, das ganze, aber hoffentlich nachvollziehbar?
Ich denke die Anforderung vom TE:
ZitatErstmal nochmal meine Ausgangssituation: Ich hätte gerne die MQTT-Dosen direkt mit meinem Mosquitto-Server verbunden. Von dort sollen sich die FHEM oder andere "MQTT-Bediener" (auf mehrere Grundstücke verteilt) "bedienen" und auch jeweils schalten können.
Direkt, da ich nicht an jedem Standort einen extra-FHEM haben möchte, der auch wiederum nur über MQTT mit der Aussenwelt kommunizieren kann.
ist durch mein Beispiel Szenario relativ simpel und genau abgedeckt?!
Zum Thema: "Internet ist weg" lokale Bedienung ist entweder nur der Taster am Gerät oder noch die HTTP Schnittstelle. Die bleibt ja lokal erreichbar (wie auch immer) und mqtt ist eben nur mit der Zentrale und nur wenn Internet verfügbar.
Wird mal irgendwann wie Strom: Kein Strom - nix geht mehr, kein Internet - nix geht mehr.
--------------------------------------------------
Eigentliche Frage zu deiner Antwort:
Ich glaube so langsam verstehe ich :) aber da ist noch viel zu tun in meinem Kopf :)
Könnte man vielleicht einen MQTT2_CLIENT auch als Mittler zwischen zwei MQTT Servern implementieren?
Also ein MQTT2_Server lokal, ein MQTT2_CLIENT Lokal und ein MQTT Server in der cloud?
ZitatKönnte man vielleicht einen MQTT2_CLIENT auch als Mittler zwischen zwei MQTT Servern implementieren?
Klar, fuer die Weitergabe kann man je nach Praeferenz MQTT_GENERIC_BRIDGE oder notify verwenden.
Man sollte nur die Topics gut ueberlegen und die MQTT2_CLIENT subscriptions richtig setzen, sonst baut man eine Endlosschleife.
Zitat von: rudolfkoenig am 28 April 2020, 08:57:17
Klar, fuer die Weitergabe kann man je nach Praeferenz MQTT_GENERIC_BRIDGE oder notify verwenden.
Das versuche ich (mit Schwerpunkt auf MGB) hier die ganze Zeit zu erklären.
Zitat von: Otto123 am 27 April 2020, 22:38:49
Ich denke die Anforderung vom TE:ist durch mein Beispiel Szenario relativ simpel und genau abgedeckt?!
Schon, wobei ich zugeben muß, dass mich die Anforderung "ohne lokales FHEM" etwas irritiert, weil der TE ja gerade eine MQTT_GENERIC_BRIDGE als "Beispiel" hier gelistet hatte - und die setzt zwingend voraus, dass ein FHEM vorhanden ist. Für einen "FHEM-losen" "Satelliten" erfüllt dein Szenario aber in jedem Fall die Anforderung ;) .
Ich würde nur eben hinterfragen, ob es überhaut Sinn macht, FHEM-lose Satelliten zu haben ::) . Sobald das Risiko besteht, dass die Verbindung abbricht und irgendeine Art lokaler Logik laufen soll, die nicht durch direkte Hardware-to-Hardware-Kommunikation (HM-Sprech: Peering) gelöst werden kann, würde ich den "Verbesserungsvorschlag" machen wollen, das mit lokaler FHEM-Installation+"doppeltem Broker" zu lösen, wobei die Anbindung des 2. Brokers mMn. am einfachsten über MQTT_GENERIC_BRIDGE+MQTT2_CLIENT zu machen ist. Das kann universell die Sende- und Empfangsrichtung abdecken und die Angaben, was (über diesen 2. Weg) zu senden und was zu empfangen ist, sind dann direkt beim "Zieldevice" zu finden. Das ist mMn. übersichtlicher als eine notify+IO-publish/supscribe-Lösung. Das "Zieldevice" der MGB kann eine Vielzahl beliebiger FHEM-Devices beliebigen TYPEs sein, also CUL_HM, ZWave oder eben auch MQTT2_DEVICEs, die mit einem anderen Broker (z.B. TYPE=MQTT2_SERVER) sprechen.
Hoffe, das hilft für das Sortieren der Gedanken?
Es wäre aber ganz gut, wenn der TE sich mal wieder meldet ;D . Sonst ist das alles nur theoretischer Kauderwelsch...
Zitat von: Beta-User am 28 April 2020, 09:47:58
Es wäre aber ganz gut, wenn der TE sich mal wieder meldet ;D . Sonst ist das alles nur theoretischer Kauderwelsch...
Vielleicht gibt es am Donnerstag ne "Leipziger Videoschalte" dann kann man einfach mal reden :)
Und Du weisst doch wie das ist: mach die Kiste auf wo MQTT drauf steht, nimm ein paar Bausteine raus zum Spielen und fang mal an. ;D
Zitat von: Otto123 am 28 April 2020, 14:54:24
Vielleicht gibt es am Donnerstag ne "Leipziger Videoschalte" dann kann man einfach mal reden :)
Reden geht vermutlich schneller ;) . Mal sehen, ob es zeitlich reinpaßt, aber ihr habt ungeschickte Uhrzeiten (18:00 Uhr)...
Zitat
Und Du weisst doch wie das ist: mach die Kiste auf wo MQTT drauf steht, nimm ein paar Bausteine raus zum Spielen und fang mal an. ;D
*grins* eigentlich bin ich froh, wenn ich diese Kiste grade nicht brauche (ich hoffe, dass den RFHEM/FHEM2FHEM/Multi-FHEM-over-MQTT-Teil für die "Einsteiger"-Doku jemand anderes beisteuert und ich dem betr. MQTT nur das Baumaterial vor die Füße kippen kann... :P )
Moin Otto,
Moin an Alle,
Zitat von: Otto123 am 26 April 2020, 21:33:37
Ich habe jetzt mal folgendes Setup probiert:
FHEM und MQTT Instanzen
- mqtt broker in der cloud (cloudmqtt)
- MQTT2_CLIENT FHEM Instanz1 verbunden mit cloudmqtt standard, autocreate nicht aktiv
- MQTT2_SERVER intern FHEM Instanz2
2 Geräte
- shellyplug s verbunden zu MQTT2_SERVER intern FHEM Instanz2, MQTT2_DEVICE vorhanden mit autocreate und attrTemplate eingerichet
- gosund sp111 mit tasmota verbunden zu MQTT2_SERVER intern FHEM Instanz2, MQTT2_DEVICE vorhanden mit autocreate und attrTemplate eingerichet
Umzug in die cloud
- Beide Definitionen aus Instanz2 kopiert, IODev geändert auf den MQTT2_CLIENT, in Raw Definition der Instanz1 ausgeführt.
- shellyplug s und gosund sp111 verbunden zu cloudmqtt
Fertig - läuft :)
Gruß Otto
Ich habe es jetzt auch so gemacht, allerdings nur mit einer Instanz.
Das Gerät mit mqtt2_Server des Fhem verbunden. Das Device anlegen lassen und alles funktioniert.
Danach
- Die Dose auf den MQTT-Server ausserhalb und ebenfalls das FHEM-Device auf ausserhalb umgestellt.
Läuft fast. Wenn ich die Dose über die WEB-Oberfläche der Dose bediene sehe ich in FHEM alle Änderungen. Diese Richtung klappt.
Nur wenn ich in FHEM bedienen will, kommt die Lampe mit dem Ausrufezeichen und kein Schaltvorgang.
Dies ist bei allen 3 Dosen, die ich probiert habe der Fall.
RAW:
defmod MQTT2_DVES_24CE7B MQTT2_DEVICE DVES_24CE7B
attr MQTT2_DVES_24CE7B IODev Mosquitto.MQTT
attr MQTT2_DVES_24CE7B alias Gar01
attr MQTT2_DVES_24CE7B autocreate 0
attr MQTT2_DVES_24CE7B comment NOTE: on-for-timer is limited to 18h max duration!
attr MQTT2_DVES_24CE7B icon hue_filled_outlet
attr MQTT2_DVES_24CE7B model tasmota_basic_state_power1
attr MQTT2_DVES_24CE7B readingList tele/fhem03/gar01/LWT:.* LWT\
tele/fhem03/gar01/STATE:.* { json2nameValue($EVENT) }\
tele/fhem03/gar01/SENSOR:.* { json2nameValue($EVENT) }\
tele/fhem03/gar01/INFO.:.* { json2nameValue($EVENT) }\
stat/fhem03/gar01/RESULT:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_24CE7B room 00-aussen,MQTT2_DEVICE
attr MQTT2_DVES_24CE7B setList off:noArg cmnd/fhem03/gar01/POWER1 0\
on:noArg cmnd/fhem03/gar01/POWER1 1\
toggle:noArg cmnd/fhem03/gar01/POWER1 2\
on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100;; 'cmnd/fhem03/gar01/Backlog pulseTime1 '.$duration.';; POWER1 1'}\
setOtaUrl:textField cmnd/fhem03/gar01/OtaUrl $EVTPART1\
upgrade:noArg cmnd/fhem03/gar01/upgrade 1
attr MQTT2_DVES_24CE7B setStateList on off toggle
attr MQTT2_DVES_24CE7B stateFormat POWER1
setstate MQTT2_DVES_24CE7B off
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:12 FallbackTopic cmnd/DVES_24CE7B_fb/
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:12 GroupTopic cmnd/sonoffs/gar01/
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 Heap 27
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:12 Hostname Gar01
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:12 IPAddress 172.18.2.155
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:12 LWT Online
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 LoadAvg 27
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:12 Module Sonoff Basic
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 MqttCount 1
setstate MQTT2_DVES_24CE7B 2020-05-02 09:31:11 POWER1 off
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:12 RestartReason Software/System restart
setstate MQTT2_DVES_24CE7B 2020-05-02 09:29:26 SaveData on
setstate MQTT2_DVES_24CE7B 2020-05-02 09:29:26 SetOption26 on
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 Sleep 50
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 SleepMode Dynamic
setstate MQTT2_DVES_24CE7B 2020-05-02 09:29:24 StateText1 off
setstate MQTT2_DVES_24CE7B 2020-05-02 09:29:25 StateText2 on
setstate MQTT2_DVES_24CE7B 2020-05-02 09:29:25 StateText3 toggle
setstate MQTT2_DVES_24CE7B 2020-05-02 09:29:25 StateText4 hold
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 Time 2020-05-02T09:30:16
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 Uptime 0T00:00:12
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 UptimeSec 12
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:12 Version 8.2.0(tasmota)
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:12 WebServerMode Admin
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 Wifi_AP 2
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 Wifi_BSSId A0:F3:C1:A0:07:66
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 Wifi_Channel 9
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 Wifi_Downtime 0T00:00:06
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 Wifi_LinkCount 1
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 Wifi_RSSI 58
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 Wifi_SSId fritz
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:16 Wifi_Signal -71
setstate MQTT2_DVES_24CE7B 2020-05-02 09:31:06 state set_on
Das hier scheint nicht zu passen:
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:12 FallbackTopic cmnd/DVES_24CE7B_fb/
setstate MQTT2_DVES_24CE7B 2020-05-02 09:30:12 GroupTopic cmnd/sonoffs/gar01/
Aber wie kann ich das Ändern?
Hier nochmal das List:
Internals:
CFGFN
CID DVES_24CE7B
DEF DVES_24CE7B
DEVICETOPIC MQTT2_DVES_24CE7B
FUUID 5ead2139-f33f-6033-d992-8dd03c649480b7f2
IODev Mosquitto.MQTT
LASTInputDev mqtt2c
MSGCNT 31
NAME MQTT2_DVES_24CE7B
NR 18727
STATE off
TYPE MQTT2_DEVICE
mqtt2c_MSGCNT 14
mqtt2c_TIME 2020-05-02 09:31:11
mqtt2s_MSGCNT 17
mqtt2s_TIME 2020-05-02 09:30:05
OLDREADINGS:
READINGS:
2020-05-02 09:30:12 FallbackTopic cmnd/DVES_24CE7B_fb/
2020-05-02 09:30:12 GroupTopic cmnd/sonoffs/gar01/
2020-05-02 09:30:16 Heap 27
2020-05-02 09:30:12 Hostname Gar01
2020-05-02 09:30:12 IPAddress 172.18.2.155
2020-05-02 09:30:12 LWT Online
2020-05-02 09:30:16 LoadAvg 27
2020-05-02 09:30:12 Module Sonoff Basic
2020-05-02 09:30:16 MqttCount 1
2020-05-02 09:31:11 POWER1 off
2020-05-02 09:30:12 RestartReason Software/System restart
2020-05-02 09:29:26 SaveData on
2020-05-02 09:29:26 SetOption26 on
2020-05-02 09:30:16 Sleep 50
2020-05-02 09:30:16 SleepMode Dynamic
2020-05-02 09:29:24 StateText1 off
2020-05-02 09:29:25 StateText2 on
2020-05-02 09:29:25 StateText3 toggle
2020-05-02 09:29:25 StateText4 hold
2020-05-02 09:30:16 Time 2020-05-02T09:30:16
2020-05-02 09:30:16 Uptime 0T00:00:12
2020-05-02 09:30:16 UptimeSec 12
2020-05-02 09:30:12 Version 8.2.0(tasmota)
2020-05-02 09:30:12 WebServerMode Admin
2020-05-02 09:30:16 Wifi_AP 2
2020-05-02 09:30:16 Wifi_BSSId A0:F3:C1:A0:07:66
2020-05-02 09:30:16 Wifi_Channel 9
2020-05-02 09:30:16 Wifi_Downtime 0T00:00:06
2020-05-02 09:30:16 Wifi_LinkCount 1
2020-05-02 09:30:16 Wifi_RSSI 58
2020-05-02 09:30:16 Wifi_SSId fritz
2020-05-02 09:30:16 Wifi_Signal -71
2020-05-02 09:31:06 state set_on
subscribeExpr:
Attributes:
IODev Mosquitto.MQTT
alias Gar01
autocreate 0
comment NOTE: on-for-timer is limited to 18h max duration!
icon hue_filled_outlet
model tasmota_basic_state_power1
readingList tele/fhem03/gar01/LWT:.* LWT
tele/fhem03/gar01/STATE:.* { json2nameValue($EVENT) }
tele/fhem03/gar01/SENSOR:.* { json2nameValue($EVENT) }
tele/fhem03/gar01/INFO.:.* { json2nameValue($EVENT) }
stat/fhem03/gar01/RESULT:.* { json2nameValue($EVENT) }
room 00-aussen,MQTT2_DEVICE
setList off:noArg cmnd/fhem03/gar01/POWER1 0
on:noArg cmnd/fhem03/gar01/POWER1 1
toggle:noArg cmnd/fhem03/gar01/POWER1 2
on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100; 'cmnd/fhem03/gar01/Backlog pulseTime1 '.$duration.'; POWER1 1'}
setOtaUrl:textField cmnd/fhem03/gar01/OtaUrl $EVTPART1
upgrade:noArg cmnd/fhem03/gar01/upgrade 1
setStateList on off toggle
stateFormat POWER1
Was kann ich noch liefern?
Freu mich, ganz kurz vor der Lösung. :-)
liebe Grüße
Hi,
ich sehe jetzt irgendwie noch keinen MQTT2_CLIENT
Das hier Mosquitto.MQTT ist Dein MQTT IO - richtig?
Gruß Otto
Zitat von: Otto123 am 02 Mai 2020, 11:26:14
Hi,
ich sehe jetzt irgendwie noch keinen MQTT2_CLIENT
Das hier Mosquitto.MQTT ist Dein MQTT IO - richtig?
Gruß Otto
Ja, Mosquitto.MQTT ist der ausserhalb-Server.
Gruß
Naja Du musst aber die MQTT2_DEVICES mit einem MQTT2_CLIENT auf den MQTT Server im Internet verbinden und nicht einfach den "alten" MQTT nehmen.
mosquitto im Inet <- MQTT2_CLIENT <- MQTT2_DEVICE
^
+-- MQTT Dose
Wenn ich mir das tasmota_basic_state_power1-Template anschaue, sehe ich das damit auch tasmota_set_lowercase_texts_and_state1 ausgeführt wird, welches folgende ReadingList erstellt:
Zitatattr DEVICE readingList \
TELETOPIC/LWT:.* LWT\
TELETOPIC/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
TELETOPIC/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
STATTOPIC/POWER1:.* state\
STATTOPIC/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
Warum ist das bei dir nicht so ?
Wenn du im jetzigen Device die ReadingList um
stat/fhem03/gar01/POWER1:.* { json2nameValue($EVENT) }
oder
stat/fhem03/gar01/POWER1:.* POWER1erweiterst, bekommst dann immer noch das Ausrufezeichen ?
Gruß
Thomas
Zitat von: TomLee am 02 Mai 2020, 12:31:43
Wenn ich mir das tasmota_basic_state_power1-Template anschaue, sehe ich das damit auch tasmota_set_lowercase_texts_and_state1 ausgeführt wird, welches folgende ReadingList erstellt:
Warum ist das bei dir nicht so ?
Wenn du im jetzigen Device die ReadingList um
stat/fhem03/gar01/POWER1:.* { json2nameValue($EVENT) }
oder
stat/fhem03/gar01/POWER1:.* POWER1
erweiterst, bekommst dann immer noch das Ausrufezeichen ?
Gruß
Thomas
Hallo,
warum das so ist, weiss ich nicht.
Das ReadingList habe ich geändert, aber keine Veränderung.
Grüße
Hallo Otto,
Zitat von: Otto123 am 02 Mai 2020, 12:06:23
Naja Du musst aber die MQTT2_DEVICES mit einem MQTT2_CLIENT auf den MQTT Server im Internet verbinden und nicht einfach den "alten" MQTT nehmen.
mosquitto im Inet <- MQTT2_CLIENT <- MQTT2_DEVICE
^
+-- MQTT Dose
Dankeschön, das war es. Ich habe lange probiert, nichts ging. Dann mal den FHEM mit shutdown restart neu gestartet uuuuund....
es geht. SUPI.
Wer weiss, wo er sich verklemmt hatte.
Dankeschön nochmals.