Hallo zusammen,
ich suche jetzt zwei Stunden nach einer Lösung und habe n Dokumente quer gelesen - ich verstehe es einfach nicht.
Ich habe ein paar Geräte (hauptsächlich Tasmota), die Steckdosen schalten und einen IR-Auslesekopf ("Stromverbrauch") basiert auch auf Tasmota.
Die Geräte legen ein MQTT2S_ip_nr in fhem an. Meldet sich ein Gerät mit einem publish wird auch ein MQTT2_Device angelegt.
Ich habe nun einen ESP32 genommen und stelle eine mqtt Verbindung zum Server her. Es wird das MQTT2S_ip_nr angelegt. Sende ich etwas, so wird auch ein MQTT2_Device angelegt.
Schalte ich den ESP32 aus und wieder an, so wird ein neuer MQTT2S_ip_nr angelegt, die MQTT2S_CONN im MQTT2_Device wird aktualisiert.
Ich möchte nun von den Tasmota-Devices einen Wert an "meinen ESP32" senden. Ich dachte, "nimm dafür doch auch einfach mqtt" - aber es gelingt mir nicht.
Das MQTT2_Device hat unter set kein publish.
Das MQTT2S Device hat ein publish - aber es passiert nichts, wenn ich mit
set publish irgendwas
sende. Genauer: der Callback im ESP32 wird nicht aufgerufen. Außerdem ändert sich der Name des Gerätes doch jedes mal wenn es vom Strom genommen wird? Dann kann ich doch auch nicht bei einer Änderung in einer der Tasmota-Geräte den neuen Wert an "mein Gerät" senden.
Wahrscheinlich verstehe ich das ganze Konzept nicht :-(
Es muss doch trivial sein, geänderte Werte eines MQTT Gerätes an ein anderes zu senden?
etwas ratlose und frustrierte Grüße
Hi,
der Name des MQTT2_Devices sollte sich nicht ändern. Was Du beobachtest ist die MQTT2 Server Instanz mit Portnummer.
Tasmota lässt sich über den topic cmnd/tasmota_123456/ steuern (der topic Mittelteil steht im Device z.B. tele/tasmota_123456)
Du kannst deinen Publish direkt im MQTT2_Device mit setList absetzen.
Schau im Wiki https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt
Gruß Otto
Das hier erwaehnte MQTT2S_ip_nr ist eigentlich versteckt, und repraesentiert die MQTT-Verbindung selbst.
Deswegen wird jeweils eine neue Instanz angelegt, wenn (durch Einschalten des MQTT-Clients) eine neue Verbindung entsteht.
MQTT2_DEVICE hat indirekt ein publish, indem man das setList Attribut definiert.
So kann man ein Geraet "zivilisiert" schalten, mit on statt z.Bsp. mit 'pfad/mit/hexzahl {"cmd":"on"}'
Direktes publish gibts beim MQTT2_SERVER selbst, als "Notloesung".
An die ESP32 (MQTT-Client) wird nur dann was gesendet, wenn sie das Gesendete auch per subscription bestellt hat. Die subscriptions sieht man in der Verbindungs-Instanz (siehe oben) oder in der MQTT2_DEVICE, wenn die Zuordnung zu der Verbindungsinstanz gelungen ist.
Geaenderte Werte von einem Geraet zu einem Anderen zu senden ist (je nach Erfahrung) nicht ganz trivial, da Topics/Message/Subscription beachtet werden muss, und man ja auch Endlosschleifen vermeiden will.
Im FHEM braucht man sowas mit notify bzw. DOIF, oder den speziell fuer diesen Zweck gebaute MQTT_GENERIC_BRIDGE.
Vielen Dank schon mal - es hakte bei mir an den Grundlagen. Falls nochmal jemand nachliest: mir hat https://www.paessler.com/de/it-explained/mqtt geholfen.
Ich habe auf "meinem ESP32" jetzt mqttClient.subscribe("tele/DVES_352360/SENSOR");
und erhalte in der CallBack-Funktion Nachrichten vom Broker:
10:59:14.205 -> Message arrived on topic: tele/DVES_352360/SENSOR. Message: {"Time":"2023-08-26T09:59:13","Power":{"Meter_Number":"0a014954520003504c4c","Total_in":3459.3369,"Power_curr":77,"Total_out":62.0395}}
Der Broker reicht also die Daten vom Tasmota-Device, welches die aktuelle Leistung am Stromzähler ausliest und an fhem sendet weiter. Das reicht zunächst mal.
Danke euch
Karsten
Hallo zusammen,
leider ist das nächste Problem aufgetaucht. Die Subscriptions, die im MQTT2_DEVICE angelegt sind, scheinen nicht aktualisiert zu werden. Ich habe auf dem ESP32 eine weitere versucht, es sieht also nun so aus:
mqttClient.subscribe("tele/DVES_352360/SENSOR") ; //power haus ist tasmota, das kann ich so abgreifen
mqttClient.subscribe("tele/DVES_17B73E/SENSOR") ; //alles andere an tasmota devices geht nicht, seltsam
Da ich keine Reaktion bekam, habe ich noch mal im MQTT2-Device ESP32Solar nachgeschaut und dort steht:
subscriptions tele/DVES_352360/SENSOR 2023-09-06 19:56:32
Das interpretiere ich so, dass die letzte Aktualisierung schon einige Tage her ist. Mir ist unklar, wann eine Aktualisierung statt findet. Muss ich das Verbindungs-Device löschen? Ich habe auch mal nur ein anderes topic subscribed und mal was vom ESP32Solar gesendet. Das kommt an, aber die subscriptions werden nicht aktualisiert.
Wie erreiche ich dies?
- ok, löschen des MQTT2_Client Devices und neu anlegen lassen ist eine Lösung, aber das scheint mir nicht sinnvoll. Wo werden den die subscriptions gespeichert? - Ich habe schon Jahre kein Perl mehr programmiert, daher nicht in den Quellcode geschaut.
VG
Karsten
Kurz:
Die subscription Readings sind nicht in immer verlaesslich.
Länger:
Die subscriptions werden in den MQTT2_SERVER Verbindungsinstanzen gespeichert, und werden von da aus in die MQTT2_DEVICE Readings nur nach dem FHEM-Start bzw. nach Anlegen einer neuen MQTT2_DEVICE Instanz uebertragen.
Das Auffinden der MQTT2_DEVICE Instanz erfolgt anhand der ClientID, was beim MQTT2_DEVICE optional ist.
Eine Aktualisierung kann man mit {MQTT2_DEVICE_checkSubscr()} erzwingen.
Auf die korrekte Bedienung der Subscription sollte das keine Auswirkung haben, das wird anhand der Daten in den MQTT2_SERVER Verbindungsinstanzen berechnet.
Ah ja, danke.
Ich "hänge" trotzdem noch. Ich habe nun mal in "meinem ESP32" die folgenden Subscriptions:
mqttClient.subscribe("tele/DVES_17B73E/SENSOR");
mqttClient.subscribe("tele/DVES_352360/SENSOR");//power haus ist tasmota, das kann ich so abgreifen
mqttClient.subscribe("tele/DVES_9C2197/SENSOR");//alles andere an tasmota devices geht nicht, seltsam
jedoch erhalte ich im Callback des mqttClient-Objektes nur die Daten von DVES_352360. Ich habe für MQTT2S den verbose level auf 5 erhöht, dann sehen die Daten im fhem.log wie folgt aus:
2023.09.17 10:23:13 4: MQTT2S_192.168.0.238_57164 DVES_352360 PUBLISH tele/DVES_352360/STATE:{"Time":"2023-09-17T10:23:12","Uptime":"59T17:43:13","UptimeSec":5161393,"Heap":103,"SleepMode":"Dynamic","Slee
2023.09.17 10:23:13 5: MQTT2S: dispatch autocreate=simple\000DVES_352360\000tele/DVES_352360/STATE\000{"Time":"2023-09-17T10:23:12","Uptime":"59T17:43:13","UptimeSec":5161393,"Heap":103,"SleepMode":"Dynamic
2023.09.17 10:23:13 4: MQTT2S_192.168.0.238_57164 DVES_352360 PUBLISH tele/DVES_352360/SENSOR:{"Time":"2023-09-17T10:23:12","Power":{"Meter_Number":"0a014954520003504c4c","Total_in":3561.9789,"Power_curr"
2023.09.17 10:23:13 5: MQTT2S_192.168.0.70_54502 ESP32Solar => tele/DVES_352360/SENSOR:{"Time":"2023-09-17T10:23:12","Power":{"Meter_Number":"0a014954520003504c4c","Total_in":3561.9789,"Power_curr":82,"To
2023.09.17 10:23:13 5: MQTT2S: dispatch autocreate=simple\000DVES_352360\000tele/DVES_352360/SENSOR\000{"Time":"2023-09-17T10:23:12","Power":{"Meter_Number":"0a014954520003504c4c","Total_in":3561.9789,"Powe
2023.09.17 10:23:13 4: MQTT2_DEVICE_Parse: ke.TasmoutaPowerHaus tele/DVES_352360/SENSOR => { json2nameValue($EVENT)}
2023.09.17 10:23:13 5: Starting notify loop for ke.TasmoutaPowerHaus, 5 event(s), first is Power_Meter_Number: 0a014954520003504c4c
2023.09.17 10:23:13 5: End notify loop for ke.TasmoutaPowerHaus
für die anderen devices sieht es ähnlich, jedoch nicht komplett analog aus (wobei mir nur der State zu fehlen scheint und das ist ja ein anderes Topic)
2023.09.17 10:24:25 4: MQTT2S_192.168.0.237_60652 DVES_17B73E PUBLISH tele/DVES_17B73E/SENSOR:{"Time":"2023-09-17T09:24:24","ENERGY":{"TotalStartTime":"2023-07-10T09:17:23","Total":35.970,"Yesterday":0.09
2023.09.17 10:24:25 5: MQTT2S_192.168.0.70_65280 ESP32Solar => tele/DVES_17B73E/SENSOR:{"Time":"2023-09-17T09:24:24","ENERGY":{"TotalStartTime":"2023-07-10T09:17:23","Total":35.970,"Yesterday":0.094,"Toda
2023.09.17 10:24:25 5: MQTT2S: dispatch autocreate=simple\000DVES_17B73E\000tele/DVES_17B73E/SENSOR\000{"Time":"2023-09-17T09:24:24","ENERGY":{"TotalStartTime":"2023-07-10T09:17:23","Total":35.970,"Yesterda
2023.09.17 10:24:25 4: MQTT2_DEVICE_Parse: ke.NousTasmotaBluettiInverter tele/DVES_17B73E/SENSOR => { json2nameValue($EVENT,'',$JSONMAP) }
2023.09.17 10:24:25 5: Starting notify loop for ke.NousTasmotaBluettiInverter, 12 event(s), first is ENERGY_Yesterday: 0.094
2023.09.17 10:24:25 5: End notify loop for ke.NousTasmotaBluettiInverter
und für das "letzte subscribe":
2023.09.17 10:24:34 4: MQTT2S_192.168.0.231_30004 DVES_9C2197 PUBLISH tele/DVES_9C2197/SENSOR:{"Time":"2023-09-17T10:24:34","ENERGY":{"TotalStartTime":"2019-10-13T19:41:58","Total":126.893,"Yesterday":0.1
2023.09.17 10:24:34 5: MQTT2S_192.168.0.70_65280 ESP32Solar => tele/DVES_9C2197/SENSOR:{"Time":"2023-09-17T10:24:34","ENERGY":{"TotalStartTime":"2019-10-13T19:41:58","Total":126.893,"Yesterday":0.119,"Tod
2023.09.17 10:24:34 5: MQTT2S: dispatch autocreate=simple\000DVES_9C2197\000tele/DVES_9C2197/SENSOR\000{"Time":"2023-09-17T10:24:34","ENERGY":{"TotalStartTime":"2019-10-13T19:41:58","Total":126.893,"Yesterd
2023.09.17 10:24:34 4: MQTT2_DEVICE_Parse: wz.KodiU tele/DVES_9C2197/SENSOR => { json2nameValue($EVENT) }
2023.09.17 10:24:34 4: MQTT2_DEVICE_Parse: wz.KodiUSB tele/DVES_9C2197/SENSOR => { json2nameValue($EVENT) }
2023.09.17 10:24:34 5: Starting notify loop for wz.KodiU, 12 event(s), first is ENERGY_Current: 0.046
2023.09.17 10:24:34 5: End notify loop for wz.KodiU
In meinem ESP32-Geräte erhalte ich nur alle 10 Sekunden die folgenden Daten über den seriellen Monitor:
11:22:03.001 -> Message arrived on topic: tele/DVES_352360/SENSOR
11:22:03.034 -> Message: {"Time":"2023-09-17T11:22:02","Power":{"Meter_Number":"0a014954520003504c4c","Total_in":3562.0730,"Power_curr":-22,"Total_out":75.1886}}
Die Ausgabe erfolgt dabei direkt im Callback.
Ich habe auch versucht mal nur ein anderes Device zu subscriben, dann bekomme ich überhaupt keine Ausgabe im ESP32, außer das MQTT connected ist.
Mir ist jetzt unklar, wo der Fehler liegt. Sendet FHEM nicht, oder kann mein ESP32 (mit pubsubclient) den Callback nicht auslösen. Aber warum geht es dann bei DVES_352360?
VG
Karsten
ZitatMir ist jetzt unklar, wo der Fehler liegt. Sendet FHEM nicht, oder kann mein ESP32 (mit pubsubclient) den Callback nicht auslösen.
#1: feststellen, welches Geraet welche subscriptions gesetzt hat.
Das schaut bei "mosquitto_sub -v -t hello -t world -t test" so aus:
fhem> list TYPE=MQTT2_SERVER subscriptions
m2s_127.0.0.1_53920 hello=1694948141.48746 test=1694948141.48746 world=1694948141.48746
#2 feststellen, was gesendet wird.
Dazu den MQTT2_SERVER vorher mit "attr <servername> verbose 5" versehen, und im Log nach in@ bzw. out@ suchen.
Nach einem "mosquitto_pub -t hello -m world", wenn der vorher gezeigte mosquitto_sub parallel mitlaeuft, schaut das Log so aus:
2023.09.17 12:55:45 5: in@127.0.0.1:34234 PUBLISH: 0(12)(0)(5)helloworld
2023.09.17 12:55:45 4: m2s_127.0.0.1_34234 PUBLISH hello:world
2023.09.17 12:55:45 5: m2s_127.0.0.1_53920 => hello:world
2023.09.17 12:55:45 5: out@127.0.0.1:53920 PUBLISH: 0(12)(0)(5)helloworld
Die in@ und out@ Zeilen wurden vor anderthalb Jahren eingebaut, um bei solchen Problemen die Richtung klarzustellen.
Ich empfehle, FHEM zu aktualisieren.
Hallo,
ich war der Meinung ein update vor meinen Experimenten mit dem eigenen mqtt2 gemacht zu haben und ich finde auch in@ sowie out@ Einträge von heute Morgen und von "jetzt" nach einem erneuten update. Allerdings wurde beim update das 10_MQTT2_DEVICE.pm aktualisiert.
Die out@-Einträge zeigen, dass fhem sendet, hier mal ein
grep -E "out@|in@" log/fhem-2023-09.log
von gerade eben:
2023.09.17 18:29:36 5: in@192.168.0.238:57173 PUBLISH: 0(229)(2)(0)(22)tele/DVES_352360/STATE{"Time":"2023-09-17T18:29:36","Uptime":"60T01:49:37","UptimeSec":5190577,"Heap":105,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":98,"Berry":{"HeapUsed":4,"Objects":46},"Wifi":{"AP":1,"SSId":"FamilyWlan","BSSId":"DC:15:C8:30:FF:9D","Channel":11,"Mode":"11n","RSSI":66,"Signal":-67,"LinkCount":21,"Downtime":"0T00:07:09"}}
2023.09.17 18:29:36 5: in@192.168.0.238:57173 PUBLISH: 0(160)(1)(0)(23)tele/DVES_352360/SENSOR{"Time":"2023-09-17T18:29:36","Power":{"Meter_Number":"0a014954520003504c4c","Total_in":3562.8355,"Power_curr":82,"Total_out":75.5848}}
2023.09.17 18:29:36 5: out@192.168.0.70:61297 PUBLISH: 0(160)(1)(0)(23)tele/DVES_352360/SENSOR{"Time":"2023-09-17T18:29:36","Power":{"Meter_Number":"0a014954520003504c4c","Total_in":3562.8355,"Power_curr":82,"Total_out":75.5848}}
2023.09.17 18:29:36 5: in@192.168.0.237:59225 PUBLISH: 0(206)(2)(0)(22)tele/DVES_17B73E/STATE{"Time":"2023-09-17T17:29:35","Uptime":"66T19:54:43","UptimeSec":5774083,"Heap":23,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":87,"POWER1":"on","Wifi":{"AP":1,"SSId":"FamilyWlan","BSSId":"DC:15:C8:30:FF:9D","Channel":11,"Mode":"11n","RSSI":58,"Signal":-71,"LinkCount":10,"Downtime":"0T00:04:51"}}
2023.09.17 18:29:36 5: in@192.168.0.237:59225 PUBLISH: 0(255)(1)(0)(23)tele/DVES_17B73E/SENSOR{"Time":"2023-09-17T17:29:35","ENERGY":{"TotalStartTime":"2023-07-10T09:17:23","Total":35.979,"Yesterday":0.094,"Today":0.020,"Period":0,"Power":1,"ApparentPower":19,"ReactivePower":19,"Factor":0.05,"Voltage":228,"Current":0.084}}
2023.09.17 18:29:36 5: out@192.168.0.70:61297 PUBLISH: 0(255)(1)(0)(23)tele/DVES_17B73E/SENSOR{"Time":"2023-09-17T17:29:35","ENERGY":{"TotalStartTime":"2023-07-10T09:17:23","Total":35.979,"Yesterday":0.094,"Today":0.020,"Period":0,"Power":1,"ApparentPower":19,"ReactivePower":19,"Factor":0.05,"Voltage":228,"Current":0.084}}
2023.09.17 18:29:37 5: in@192.168.0.70:61297 PUBLISH: 0(24)(0)(16)esp32solar/stateonline
Also sieht es ganz so aus, dass FHEM wie erwartet sendet. IP 192.168.0. 70 hat aktuell mein esp32. Aber ich bekomme im Callback nur die Nachrichten vom topic: tele/DVES_352360/SENSOR.
Also schaue ich mal auf den Client. Der Unterschied, den ich sehe, ist die Länge. Ich Poste hier, wenn ich etwas gefunden habe.
Ok - habe etwas gefunden - mqttClient.setBufferSize(1024); der Standard sind 256 Byte. Jetzt bekomme ich die Meldungen im Nachhinein denke ich natürlich - das hätte ich auch selber sehen können...
Vielen Dank an alle Antwortenden - ihr habt schon viel Geduld :-) der Hinweis mit in@ und out@ hat mich auf den richtigen Weg geschubst.
VG Karsten