Thermostat über MQTT

dominik · 04 März 2020, 21:41:51

Hallo,
ich habe einige EQ3 Bluetooth Thermostat Module für welche ich bereits das Modul 10_EQ3BT.pm geschrieben habe. Nun habe ich für die weiter entfernten Thermostate einen ESP32 mit BLE2MQTT ausgestattet. Als nächstes würde ich gerne ein Modul EQ3BTMQTT_DEVICE bauen, damit darüber auch andere das Thermostat über MQTT nutzen können.

Nun könnte ich das in Teilen über attrTemplate lösen um Befehle zu senden, das sollte klappen. Um die Werte des Thermostats auszulesen, muss ich jedoch einen Befehl mit aktueller Uhrzeit an das Device schicken und nur dann erhalte ich eine Rückmeldung mit den richtigen Werten. Im EQ3BT Modul sende ich ca. alle 3-5 Minuten daher eine Anfrage an das Thermostat um die Readings zu aktualisieren.

Könnte ich das ebenfalls über attrTemplate lösen, oder muss ich dazu ein eigenes Modul bauen? Ich würde dann das MQTT2_DEVICE Modul als Basis verwenden und dieses erweitern.

rudolfkoenig · 04 März 2020, 22:11:10

In MQTT2_DEVICE kann man perl Expressions angeben: beim Senden pro Befehl im setList Attribut, beim Empfang pro Topic im readingList Attribut.
Einschraenkung: ein Expression an diesen Stellen ist jeweils ein Einzeiler.
Ob das in deinem Fall akzeptabel ist, musst Du beurteilen.
Ein Umweg waere das Verpacken der Expressions in Funktionen, und das Anbieten dieser Funktionen in einer Datei.

Beta-User · 05 März 2020, 09:22:19

Kann da gerne unterstützen, was ein attrTemplate für MQTT2_DEVICE angeht.

Hätte aber noch ein paar Überlegungen zum ganzen setup:

1. Vielleicht wäre es denkbar, einfach das EQ3BT-Modul zu erweitern und als "<sshHost-IP>" ein MQTT2_DEVICE angeben zu können?
Dann könnte der User "einfach so" zwischen verschiedenen Welten wechseln, wenn er wollte? In diesem Device könnten dann "alle" EQ3-BT-Thermostate "ihre" Readings haben, es würde ggf. nur eine notifyFn benötigt, die auf Aktualisierungen dieser Readings lauscht (bzw. nur denen, die zu dem jeweiligen Thermostat gehören)?

Das ist vielleicht im Moment etwas abstrakt, aber woran in konkreter denke, wird evtl. klarer, wenn du dir die vorhandenen attrTemplates rund um das OpenMQTTGateway ansiehst, insbesondere den OpenMQTTGateway_BT_scanner. Dazu wäre es vermutlich hilfreich, mal testweise zwei ESP32 mit der betreffenden firmware zu flashen (unterschiedliche Namen), und dann zu sehen, was da z.B. mit einem Tag passiert bzw. ggf. schon von den Thermostaten ankommt. Das Datenhandling in diesen Templates ist sonst einigermaßen abstrakt...

Vermutlich bräuchte man noch ein Attribut, falls jemand mehrere MQTT2-IOs nutzt, aber sonst sehe ich jetzt - jedenfalls auf die Schnelle - keine unüberwindlichen Hindernisse.

2. Insgesamt wäre es toll, wenn wir den ESP32-BLE-Teil irgendwie so hinbekämen, dass wir eine Art Universalgateway nutzen/vorschlagen können. Ich bin da leidenschaftslos, was es am Ende sein soll und unterstütze ggf. auch mehrere Zweige/firmwares, habe aber ganz gute Erfahrungen mit dem OpenMQTTGateway gemacht. Vielleicht schaust du dir diese Firmware auch mal an? Ich kann leider nicht sagen ob das kompatibel zu der von dir verlinkten ist oder sogar intern dieselbe Funktionalität bereits nutzt - oft stecken ja dieselben libs dahinter...

dominik · 05 März 2020, 18:12:37

Danke euch fuer die Rueckmeldungen!

So wie ich das lese, sollte ich definitiv ueber MQTT2_DEVICE gehen und wenn moeglich ueber das attrTemplate. Ich hatte BLE2MQTT verwendet, da es ein "dummes" Gateway ist und noch kein Handling von Devices dort stattfindet. OpenMQTTGateway macht schon ziemlich viel Device Erkennung, da dachte ich, dass ich dann EQ3BT in OpenMQTTGateway implementieren muesste, was ich eigentlich vermeiden moechte.

Das BLE2MQTT wird auch schon schoen als MQTT2_DEVICE automatisch erkannt. Die Set Befehle bekomme ich vermutlich wirklich ueber perl Code in setList abgedeckt. Das laufende Lesen des Device State muss ich jedoch alle paar Minuten triggern, da dazu zuerst Daten an das Device gesendet werden muessen um die korrekten Werte zurueck zu bekommen. Dieses regelmaessige Senden/Lesen ist mir noch nicht klar wie ich das am besten loese. Habt ihr da eine Idee?

Beta-User · 05 März 2020, 19:30:48

Keine Ahnung, wie OpenMQTTGateway intern wirklich tickt, ich kann bisher nur beobachten, dass das, was irgendwie erkannt wird, dann unter einem Teil-Topic-Tree sauber gemeldet wird, auch für Geräte, die es (noch) nicht kennt (ich habe ein paar eckige Xiaomi-Temperatur-Hum-Teile hier liegen, die sieht es, kann aber die Temp etc. nicht auslesen).
Die Geräte, die es besser kennt, sind aber auch immer nur ein paar Zeilen im Code.

Ist aber für's erste auch nicht so wichtig...

Zeigst du mal ein RAW von dem MQTT2_DEVICE, bitte?
So wie ich das verstanden habe, haben wir ein 1:n Gerät, also ein ESP32 kann mehrere Thermostate "bedienen"?
Dann wäre ich immer noch dafür, den Perl-Code im Wesentlichen in deinem Modul unterzubringen, einschließlich des Timers. Es gibt aber mit ebus auch eine MQTT2-Device-Teilimplementierung, bei der ein "at" regelmäßige Abfragen via MQTT an den ebus übergibt - geht also auch, und man könnte das auch automatisiert via attrTemplate erstellen...

Vorschlag: Eins nach dem anderen, wenn wir alle Bausteine haben für eine grundsätzlich funktionierende Lösung, dann schauen wir, wie es am Ende am besten für uns und eventuelle User geht?
Vielleicht habe ich Muße und schaue mir auch diese firmware hier an, einen ESP32 habe ich noch ungenutzt im Keller liegen, und die "eckigen" wollte ich eh' irgendwann mal an die Wand hängen, wenn FHEM sie "kann"

. Vielleicht ist das mit BLE2MQTT einfacher, oder ich kann was zur Device-Integration für den eQ-3 bei OMG beitragen.

dominik · 05 März 2020, 20:55:21

Hier das MQTT2_DEVICE BLE2MQTT Device von einem Thermostat. Es wird als Topic immer die BL-Adresse geliefert, dort ist es also separiert pro Thermostat.

Code Auswählen

defmod MQTT2_ESP32_17BE44 MQTT2_DEVICE ESP32_17BE44
attr MQTT2_ESP32_17BE44 IODev mqttBroker
attr MQTT2_ESP32_17BE44 readingList ESP32_17BE44:BLE2MQTT-BE44/Uptime:.* Uptime\
ESP32_17BE44:BLE2MQTT-BE44/FreeMemory:.* FreeMemory\
ESP32_17BE44:BLE2MQTT-BE44/Version:.* Version\
ESP32_17BE44:BLE2MQTT-BE44/ConfigVersion:.* ConfigVersion\
ESP32_17BE44:00_1a_22_07_40_fb/Connected:.* Connected\
ESP32_17BE44:00_1a_22_07_40_fb/Owner:.* Owner\
ESP32_17BE44:00_1a_22_07_40_fb/GenericAccess/DeviceName:.* DeviceName\
ESP32_17BE44:00_1a_22_07_40_fb/GenericAccess/Appearance:.* Appearance\
ESP32_17BE44:00_1a_22_07_40_fb/GenericAccess/PeripheralPrivacyFlag:.* PeripheralPrivacyFlag\
ESP32_17BE44:00_1a_22_07_40_fb/GenericAccess/PeripheralPreferredConnectionParameters:.* PeripheralPreferredConnectionParameters\
ESP32_17BE44:00_1a_22_07_40_fb/GenericAttribute/ServiceChanged:.* ServiceChanged\
ESP32_17BE44:00_1a_22_07_40_fb/DeviceInformation/ManufacturerNameString:.* ManufacturerNameString\
ESP32_17BE44:00_1a_22_07_40_fb/DeviceInformation/ModelNumberString:.* ModelNumberString\
ESP32_17BE44:00_1a_22_07_40_fb/3e135142-654f-9090-134a-a6ff5bb77046/3fa4585a-ce4a-3bad-db4b-b8df8179ea09:.* 3fa4585a-ce4a-3bad-db4b-b8df8179ea09\
ESP32_17BE44:00_1a_22_07_40_fb/3e135142-654f-9090-134a-a6ff5bb77046/d0e8434d-cd29-0996-af41-6c90f4e0eb2a:.* d0e8434d-cd29-0996-af41-6c90f4e0eb2a\
ESP32_17BE44:00_1a_22_07_40_fb/9e5d1e47-5c13-43a0-8635-82ad38a1386f/347f7608-2e2d-47eb-913b-75d4edc4de3b:.* 347f7608-2e2d-47eb-913b-75d4edc4de3b
attr MQTT2_ESP32_17BE44 room MQTT2_DEVICE

setstate MQTT2_ESP32_17BE44 2020-03-03 21:14:11 347f7608-2e2d-47eb-913b-75d4edc4de3b 0,16,3,2
setstate MQTT2_ESP32_17BE44 2020-03-03 21:14:11 3fa4585a-ce4a-3bad-db4b-b8df8179ea09 3,20,2,9,17,31,6,203,140,123,110,252,84,60,147,228
setstate MQTT2_ESP32_17BE44 2020-03-03 21:14:11 Appearance 0
setstate MQTT2_ESP32_17BE44 2020-03-03 21:19:37 ConfigVersion ab007eee66a53c6023b83d0209a17b13737266da9eea6685d69c307af17f9bff
setstate MQTT2_ESP32_17BE44 2020-03-03 21:19:36 Connected false
setstate MQTT2_ESP32_17BE44 2020-03-03 21:14:11 DeviceName CC-RT-BLE
setstate MQTT2_ESP32_17BE44 2020-03-05 20:52:07 FreeMemory 77440
setstate MQTT2_ESP32_17BE44 2020-03-03 21:14:11 ManufacturerNameString eq-3
setstate MQTT2_ESP32_17BE44 2020-03-03 21:14:11 ModelNumberString CC-RT-BLE
setstate MQTT2_ESP32_17BE44 2020-03-03 21:17:48 Owner BLE2MQTT-BE44
setstate MQTT2_ESP32_17BE44 2020-03-03 21:14:11 PeripheralPreferredConnectionParameters 0,0,0,0
setstate MQTT2_ESP32_17BE44 2020-03-03 21:14:11 PeripheralPrivacyFlag false
setstate MQTT2_ESP32_17BE44 2020-03-03 21:14:11 ServiceChanged 0,0
setstate MQTT2_ESP32_17BE44 2020-03-05 20:52:07 Uptime 183360
setstate MQTT2_ESP32_17BE44 2020-03-03 21:19:36 Version v0.12.0-2-gf503814
setstate MQTT2_ESP32_17BE44 2020-03-03 21:14:11 d0e8434d-cd29-0996-af41-6c90f4e0eb2a 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
setstate MQTT2_ESP32_17BE44 2020-02-28 16:52:59 subscriptions BLE2MQTT-BE44/OTA/Config BLE2MQTT-BE44/OTA/Firmware BLE2MQTT/OTA/Config BLE2MQTT/OTA/Firmware

Beta-User · 06 März 2020, 10:28:24

Hmm, mal meine ersten Gedanken/Fragen:

- deute ich das richtig, dass auch alle weiteren Thermostate (und alles, was sonst noch so BLE-Signale sendet) ebenfalls in diesem Device landen?
Dann haben wir das (lösbare, s.u.) Problem, dass die Readings (z.B. Connected, DeviceName...) nicht mehr einem bestimmten Gerät zuordnen können.

- Bekommst du das alles ungefragt, oder nur Werte von BLE-Devices, die du irgendwie aktiv "anpingst"?

- Gibt es die Möglichkeit, den ESP so zu konfigurieren, dass wir außer über die CID (ESP32_17BE44:) hinaus noch eine Möglichkeit haben festzustellen, welcher ESP das Signal empfangen hat? Ich denke v.a. an eine Art ESP-spezifischem Teil im Topic-Tree, der den Namen enthält.
Zum Hintergrund der Frage: Sonst haben wir bei mehreren ESP's und MQTT2_CLIENT-Nutzern das Problem, dass wir nicht mehr feststellen können, worüber wir ggf. zu senden haben.

- Der ESP sendet "Klartext". Für unsere Zwecke wäre dem Bauchgefühl nach JSON geschickter, weil wir dann den JSON als ein Event weitergeben könnten und nicht viele Events generieren/auswerten müssen, die evtl. zeitlich geordnet werden müßten. Gibt es da eine Option, das umzustellen?

(ich werde am WE mal den Reserve-ESP rauskramen und mir das ansehen, allerdings dann eben mit den BT-Devices, die ich habe).
Es wäre m.E. trotzdem mal sinnvoll, wenn du parallel einen ESP32 mit dem aktuellen OpenMQTTGateway-BLE-Sketch mitlesen lassen könntest. Es würde mich interessieren, was der - im direkten Vergleich - von deinem BLE-Umfeld "sieht" bzw. wie das ein "scanner-MQTT2-Device" darstellt.

So oder so wäre meine Bitte, wenn du dir die beiden templates "OpenMQTTGateway_MCU" und "OpenMQTTGateway_BT_scanner" ansehen würdest. Wir werden voraussichtlich ähnliche Mechanismen brauchen, wenn wir den MLE2MQTT-Weg weiter gehen, siehe z.B. dieser Beitrag, da ist ein Beispiel-list drin, wie messages und Topic-Struktur da ausgewertet werden. Vielleicht wird dann klarer, wie die Lösung ausehen könnte, um Reading-Benennungen hinzubekommen, die sich eindeutig auf eine bestimmte Quelle beziehen.

Vielleicht noch ein Hinweis: Was wir hier vorhaben, ist nicht grade "einfaches MQTT". Es wäre ziemlich überraschend für mich, dass du direkt alles auf Anhieb verstehst, was ich hier schreibe, das sind teilweise auch einfach Merkposten für mich selbst....

dominik · 06 März 2020, 15:36:14

Zitat von: Beta-User am 06 März 2020, 10:28:24
- deute ich das richtig, dass auch alle weiteren Thermostate (und alles, was sonst noch so BLE-Signale sendet) ebenfalls in diesem Device landen?
Dann haben wir das (lösbare, s.u.) Problem, dass die Readings (z.B. Connected, DeviceName...) nicht mehr einem bestimmten Gerät zuordnen können.

Ja, alles kommt in dem Device an. Die Zuordnung zum richtige Device ist kein Problem. Im Topic ist ja vorne dran die BLE-Adresse des richtigen Devices. Das aufzuteilen sollte ja genauso wie beim Shelly 2.5 gehen. Dort wird ja auch ueber die ReadingList definiert was in welchem Device landet.
BLE2MQTT kann auf BLE-Adressen filtern. Ich habe aktuell auf ein Theromstat gefiltert und einen BLE Bewaesserungscomputer, der noch eingewintert ist und daher kein Signal sendet.

Zitat
- Bekommst du das alles ungefragt, oder nur Werte von BLE-Devices, die du irgendwie aktiv "anpingst"?

Die Werte kommen alle ungefragt, da in den BLE Characteristics diese Werte drin stehen und von BLE2MQTT automatisch ausgelesen werden. Alle Characteristics was vorhanden sind, liest BLE2MQTT automatisch aus. Die Werte sind jedoch nicht korrekt. Zuerst muss ich die aktuelle Uhrzeit an das Device per BLE schicken und dann bekomme ich als Notification die richtige Antwort zurueck. (Mach ich aktuell ueber gatttool --char-write-req .... --listen).

Zitat
- Gibt es die Möglichkeit, den ESP so zu konfigurieren, dass wir außer über die CID (ESP32_17BE44:) hinaus noch eine Möglichkeit haben festzustellen, welcher ESP das Signal empfangen hat? Ich denke v.a. an eine Art ESP-spezifischem Teil im Topic-Tree, der den Namen enthält.
Zum Hintergrund der Frage: Sonst haben wir bei mehreren ESP's und MQTT2_CLIENT-Nutzern das Problem, dass wir nicht mehr feststellen können, worüber wir ggf. zu senden haben.

Der ESP32_17BE44 ist schon ESP spezifisch. Es gibt nur einen ESP32 mit dieser ID. Wuerde ich einen weiteren ESP32 mit BLE2MQTT flashen, haette der eine andere ID. Damit sollte auch alles zuordenbar sein und dahinter steht jeweils die BLE-Adresse des richtigen Geraets.

Zitat
- Der ESP sendet "Klartext". Für unsere Zwecke wäre dem Bauchgefühl nach JSON geschickter, weil wir dann den JSON als ein Event weitergeben könnten und nicht viele Events generieren/auswerten müssen, die evtl. zeitlich geordnet werden müßten. Gibt es da eine Option, das umzustellen?

Der ESP sendet alles per JSON und es kommt beim MQTT2_SERVER als JSON an, welcher dann ein MQTT2_DEVICE daraus macht und dort die Werte automatisch anhand des Topics erstellt.

Zitat
(ich werde am WE mal den Reserve-ESP rauskramen und mir das ansehen, allerdings dann eben mit den BT-Devices, die ich habe).
Es wäre m.E. trotzdem mal sinnvoll, wenn du parallel einen ESP32 mit dem aktuellen OpenMQTTGateway-BLE-Sketch mitlesen lassen könntest. Es würde mich interessieren, was der - im direkten Vergleich - von deinem BLE-Umfeld "sieht" bzw. wie das ein "scanner-MQTT2-Device" darstellt.

So oder so wäre meine Bitte, wenn du dir die beiden templates "OpenMQTTGateway_MCU" und "OpenMQTTGateway_BT_scanner" ansehen würdest. Wir werden voraussichtlich ähnliche Mechanismen brauchen, wenn wir den MLE2MQTT-Weg weiter gehen, siehe z.B. dieser Beitrag, da ist ein Beispiel-list drin, wie messages und Topic-Struktur da ausgewertet werden. Vielleicht wird dann klarer, wie die Lösung ausehen könnte, um Reading-Benennungen hinzubekommen, die sich eindeutig auf eine bestimmte Quelle beziehen.

Vielleicht noch ein Hinweis: Was wir hier vorhaben, ist nicht grade "einfaches MQTT". Es wäre ziemlich überraschend für mich, dass du direkt alles auf Anhieb verstehst, was ich hier schreibe, das sind teilweise auch einfach Merkposten für mich selbst....

Fuer mich macht es eigentlich keinen Unterschied ob OpenMQTTGateway oder BLE2MQTT, aus meiner Sicht liefern beide in FHEM ein simples MQTT2_DEVICE, oder? Mir geht es nur darum, wie kann ich um das MQTT2_DEVICE noch Logik drum herum bauen? Da fehlt mir der Ansatz.

Danke fuer deine Hilfe!

Beta-User · 06 März 2020, 16:14:59

Hmm, jein:

- Die CID (das vor dem Doppelpunkt) ist leider nicht in allen denkbaren Installationen eine verlässliche Angabe, sorry, wenn das nicht hinreichend deutlich war. Wir brauchen m.E. zwingend eine Erweiterung des Topic-Tree, der den Namen des GW beinhaltet - die Angabe vor dem Doppelpunkt gehört nicht zum Topic-Tree und wird z.B. verändert, wenn jemand mosquitto (statt MQTT2_SERVER) im Einsatz hat.
Lt. Doku (ich nehme an, das ist diese hier: https://github.com/shmuelzon/esp32-ble2mqtt#configuration) sollte also ein "prefix" gesetzt werden - dies bitte pro GW unterschiedlich.
(Das ist für die Empfangsseite nicht ganz so wichtig wie für's spätere Senden der Zeit. Wir sollten m.E. von vornherein Probleme vermeiden, die z.B. durch gleichzeitiges Senden von BLE-Requests von mehreren GW's entstehen könnten...)

- das mit der Whitelist bzw. Blacklist ist klar, danke. (Aber das muß man bei dieser firmware zu compile-time machen? Gefällt mir nicht...)

- hast du die Syntax, wie das "gatttool --char-write-req ...." per MQTT an den ESP32 zu senden ist? (Ich habe die Hoffnung, dass dann die Antwort wieder automatisch vom ESP verarbeitet wird, finde aber in der Doku auf die Schnelle keinen Anhaltspunkt, wie das ggf. geht). Und auch die "subscriptions" in dem RAW sehen nicht so aus, also wäre in der firmware sowas vorgesehen, hmmm.

- Und nein, BLE2MQTT sendet mAn. nicht in JSON, sonst müßte im RAW-code json2nameValue() zu finden sein.

Zitat von: dominik am 06 März 2020, 15:36:14
Fuer mich macht es eigentlich keinen Unterschied ob OpenMQTTGateway oder BLE2MQTT, aus meiner Sicht liefern beide in FHEM ein simples MQTT2_DEVICE, oder?

(Fast) Korrekt. Empfangsseitig ist es fast egal.

Faktisch gibt es ein paar Unterschiede:
- OMG kann nicht nur BT, bei mir hängt an einem noch ein IR-receiver dran, 433MHz wäre z.B. als "addon" auch möglich.
- white- und blacklist lassen sich "on the fly" konfigurieren.
- Doku zu OMG ist sehr viel mehr, wenn auch nicht unbedingt zu den BT-Themen, das ist noch recht jung da...
- Es gibt eine grundsätzliche Vorbereitung des Codes in Richtung Receive bei OMG auch wenn es da scheinbar bislang bzgl. BT keinen Anwendungsfall gab. Aber es dürfte eine bessere Ausgangsbasis sein (die allerdings ggf. dadurch negativ kompensiert wird, dass eine andere BT-Implementierung drin ist als gattool).

Zitat von: dominik am 06 März 2020, 15:36:14
Mir geht es nur darum, wie kann ich um das MQTT2_DEVICE noch Logik drum herum bauen? Da fehlt mir der Ansatz.

Du kannst Code direkt "anflanschen":

Code Auswählen

ESP32_17BE44:00_1a_22_07_40_fb/3e135142-654f-9090-134a-a6ff5bb77046/d0e8434d-cd29-0996-af41-6c90f4e0eb2a:.* {mySub_xyz($EVENT)}

würde den empfangenen Wert (hier: "0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0") an die betreffende sub übergeben.

Das könnte auch eine sub aus dem Modul EQ3BT sein... (oder eben aus einer nachgeladenen myUtils).

dominik · 06 März 2020, 20:14:05

Zitat von: Beta-User am 06 März 2020, 16:14:59
Hmm, jein:

- Die CID (das vor dem Doppelpunkt) ist leider nicht in allen denkbaren Installationen eine verlässliche Angabe, sorry, wenn das nicht hinreichend deutlich war. Wir brauchen m.E. zwingend eine Erweiterung des Topic-Tree, der den Namen des GW beinhaltet - die Angabe vor dem Doppelpunkt gehört nicht zum Topic-Tree und wird z.B. verändert, wenn jemand mosquitto (statt MQTT2_SERVER) im Einsatz hat.
Lt. Doku (ich nehme an, das ist diese hier: https://github.com/shmuelzon/esp32-ble2mqtt#configuration) sollte also ein "prefix" gesetzt werden - dies bitte pro GW unterschiedlich.
(Das ist für die Empfangsseite nicht ganz so wichtig wie für's spätere Senden der Zeit. Wir sollten m.E. von vornherein Probleme vermeiden, die z.B. durch gleichzeitiges Senden von BLE-Requests von mehreren GW's entstehen könnten...)

Ok, wusste nicht, dass das CID nicht zur Unterscheidung beitraegt und es vom MQTT Server abhaengig ist. Gehoert dann der Rest nach dem :: zum Topic? Weil dort steht ja die BLE-Adresse, die ist ja auf alle Faelle eindeutig.
ESP32_17BE44:00_1a_22_07_40_fb/Connected
Ich stehe da noch auf den Schlauch wo du das Senden umsetzen willst? In einer Funktion in attrTemplate?

Zitat
- das mit der Whitelist bzw. Blacklist ist klar, danke. (Aber das muß man bei dieser firmware zu compile-time machen? Gefällt mir nicht...)

Ja, ist nicht schoen geloest bei BLE2MQTT.

Zitat
- hast du die Syntax, wie das "gatttool --char-write-req ...." per MQTT an den ESP32 zu senden ist? (Ich habe die Hoffnung, dass dann die Antwort wieder automatisch vom ESP verarbeitet wird, finde aber in der Doku auf die Schnelle keinen Anhaltspunkt, wie das ggf. geht). Und auch die "subscriptions" in dem RAW sehen nicht so aus, also wäre in der firmware sowas vorgesehen, hmmm.

gatttool sendet nicht an den ESP32, sonst waere es ja BLE. Mit dem gatttool spreche ich das Device direkt ueber BLE an.
gatttool -b BLEMAC --char-write-req -a 0x0411 -n 031403061400 --listen

Die Antwort wird ziemlich sicher vom ESP verarbeitet, weil genau dafuer die Subscriptions da sind. Die Subscriptions werden automatisch von BLE2MQTT angelegt um die BLE Notification zu erhalten. BLE2MQTT prueft ob eine BLE Characteristic Notifications unterstuetzt und wenn ja, registriert es diese als Subscription.

Zitat
- Und nein, BLE2MQTT sendet mAn. nicht in JSON, sonst müßte im RAW-code json2nameValue() zu finden sein.
(Fast) Korrekt. Empfangsseitig ist es fast egal.

Sorry, da hast du Recht. Die Value die zurueck gelieft wird, ist ein Komma separierter String der Hex Werte aus den BLE Characteristics.

Zitat
Faktisch gibt es ein paar Unterschiede:
- OMG kann nicht nur BT, bei mir hängt an einem noch ein IR-receiver dran, 433MHz wäre z.B. als "addon" auch möglich.
- white- und blacklist lassen sich "on the fly" konfigurieren.
- Doku zu OMG ist sehr viel mehr, wenn auch nicht unbedingt zu den BT-Themen, das ist noch recht jung da...
- Es gibt eine grundsätzliche Vorbereitung des Codes in Richtung Receive bei OMG auch wenn es da scheinbar bislang bzgl. BT keinen Anwendungsfall gab. Aber es dürfte eine bessere Ausgangsbasis sein (die allerdings ggf. dadurch negativ kompensiert wird, dass eine andere BT-Implementierung drin ist als gattool).
Du kannst Code direkt "anflanschen":
Code Auswählen Erweitern
ESP32_17BE44:00_1a_22_07_40_fb/3e135142-654f-9090-134a-a6ff5bb77046/d0e8434d-cd29-0996-af41-6c90f4e0eb2a:.* {mySub_xyz($EVENT)}würde den empfangenen Wert (hier: "0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0") an die betreffende sub übergeben.

Das könnte auch eine sub aus dem Modul EQ3BT sein... (oder eben aus einer nachgeladenen myUtils).

Genau das gleiche (das Code Beispiel) geht doch auch mit BLE2MQTT, das liegt am MQTT2_DEVICE und nicht am BLE to MQTT Gateway.

Wie schon gesagt, mir geht es nur darum, dass ich irgendwo einen Timer brauche, der regelmaessig die aktuelle Uhrzeit beim MQTT2_DEVICE sendet, damit ich dort die Notifications mit den Werten erhalte. Ich koennte das einfach mit einem DOIF bauen, klar das geht, aber ich moechte eigentlich, dass jeder User mit einem einfachen 'define' den Thermostat nutzen kann, ohne dass die Logik nun in einem DOIF verstrickt ist.

rudolfkoenig · 06 März 2020, 21:25:45

ZitatOk, wusste nicht, dass das CID nicht zur Unterscheidung beitraegt und es vom MQTT Server abhaengig ist.

Um es anders zu formulieren: die ClientID des Publishers kennt zwar der Server (wie MQTT2_SERVER), aber die Subscribers nicht, sie wissen nicht, wer die Nachricht geschickt hat.
D.h. wenn man Szenarien mit mosquitto unterstuetzen will (wo FHEM nur ein MQTT Client ist), muss man auf die ClientID im readingList Regexp verzichten.

Die ClientID zu kennen (d.h. wenn man MQTT2_SERVER verwendet) ist praktisch bei "normalen" MQTT Geraeten (nicht bridge, wie BLE2MQTT), weil FHEM dann die Nachrichten eindeutig einem Geraet zuordnen kann, und so autocreate ohne weitere Konfiguration moeglich ist.

Zitatmir geht es nur darum, dass ich irgendwo einen Timer brauche, der regelmaessig die aktuelle Uhrzeit beim MQTT2_DEVICE sendet, damit ich dort die Notifications mit den Werten erhalte.

Ich favorisiere z.Zt. folgende Loesung: beim Anwenden des Templates wird per defmod ein at definiert, der per devspec Filter fuer alle EQ3-Geraete die Uhrzeit sendet. In der Art:

Code Auswählen

defmod eq3bleTimer at +*00:01 set ManufacturerNameString=eq-3 time {(TimeNow())}

dominik · 06 März 2020, 21:54:54

Jetzt habe ich es verstanden, danke fuer die Erklaerung!

Dein Loesungsansatz mit defmod finde ich generell moeglich, aber mir gefaellt es nicht, wenn Geraete ein separates at/notify/... in FHEM benoetigen um in der Grundfunktionalitaet zu funktionieren. Jemand koennte dann unbeabsichtigt das at loeschen und dann funktioniert das Geraet nicht mehr richtig.
Aus meiner Sicht sollte ein Geraet immer unabhaengig von anderen "Devices" in FHEM sein (ausser IODev), daher haette ich den Timer gerne in einem Modul versteckt.

Ich habe mir das TASMOTA_DEVICE, welches noch auf MQTT basiert - nicht MQTT2, angesehen und finde die Loesung ganz schoen (https://github.com/klein0r/fhem-tasmota/blob/master/FHEM/10_TASMOTA_DEVICE.pm). Dort wird quasi das MQTT Modul "erweitert". Wenn sowas bei MQTT2_DEVICE moeglich waere, waere das genial. Weil dann kann man komplexe Devices ueber eigene Module bauen und einfache Devices ueber attrTemplate abwickeln.

rudolfkoenig · 06 März 2020, 23:22:58

ZitatIch habe mir das TASMOTA_DEVICE, welches noch auf MQTT basiert - nicht MQTT2, angesehen und finde die Loesung ganz schoen

Sowas kann man immer machen, d.h. auch mit MQTT2_DEVICE.

Beta-User · 07 März 2020, 06:55:13

Finde die Lösung mit einem externen Gerät auch nicht so schön, will aber erst mal noch das Augenmerk auf etwas anderes lenken.

Du hattest hier folgendes gepostet:

Zitat von: dominik am 05 März 2020, 20:55:21
Code Auswählen Erweitern
setstate MQTT2_ESP32_17BE44 2020-02-28 16:52:59 subscriptions BLE2MQTT-BE44/OTA/Config BLE2MQTT-BE44/OTA/Firmware BLE2MQTT/OTA/Config BLE2MQTT/OTA/Firmware

Danach "hört" der ESP erst mal auf ein paar Topics, soweit, so gut. Das Problem, das ich sehe, ist dass die alle was mit "OTA" zu tun haben, das klingt verdächtig danach, als ginge es ausschließlich um updates, und das wäre zu wenig, denn was wir suchen, ist eine Schnittstelle (aka: Topic), über die wir dem ESP mitteilen können, dass bzw. was er via seiner BT-Schnittstelle versenden soll; erst dort soll ja der "Text" (die "Payload", ggf. bedingt durch den konkreten Topic, an den die gesendet wird) ausgewertet werden und in ein BT-Signal "übersetzt".

Wir benötigen daher als nächsten Schritt die Info, an welches Topic man was an den ESP senden muß, um diesen dazu zu bewegen, die Uhrzeit (via BT) zu versenden. Wo finden wir diese?

Vielleicht zum Vergleich noch der entsprechende Wert von einem Tasmota (das scheinst du ja auch zu nutzen):

Code Auswählen

setstate USB_Plug 2020-03-07 04:03:24 subscriptions cmnd/DVES_EFFB7F/# cmnd/DVES_EFFB7F_fb/# cmnd/tasmotas/#

Zum Verständnis: Der hört also auf zwei Topics ("seinen" und den, der als "fallback" (_fb) angegeben ist, und nimmt dort "alles" mit, was in beliebigen Zweigen darunter gesendet wird (damit ist noch nicht gesagt, dass überall was sinnvolles rauskommt; es geht erst mal nur darum, wie groß das "Ohr" ist, mit dem das Ding lauscht.)

Der Vollständigkeit halber noch, wie das beim OMG aussieht:

Code Auswählen

setstate MQTT2_OpenMQTTGateway_Buero 2020-03-07 04:03:24 subscriptions home/OpenMQTTGateway_Buero/commands/#

(Ergo: Alles, was irgendwie über ../commands kommt, wird ausgewertet. Darunter gibt es dann wieder mehrere Zweige (wie bei mehrkanaligen Tasmotas auch).

Wenn wir dann wissen, wie der MQTT-command an BT2MQTT aussehen muß, bekommen wir den nächsten Schritt auch hin (setList).

Hast du einen ESP übrig, um den mal als Tasmota-Gerät an MQTT2_SERVER zu hängen? (ein Shelly ginge auch, geht nur darum, diese Werte zu verstehen und mal eine setList gesehen zu haben). Dann wird das vorgesagte evtl. noch klarer.

Beta-User · 07 März 2020, 22:23:54

Hmmm, also: eigentlich sollte das Abfragen via gattool unter den "get"-suffixen möglich sein. Das kann man in der config.json angeben, aber leider bekomme ich das Projekt nicht übersetzt und eine binary gibt es wohl nicht...
Kann daher nicht verifizieren, was unter subscriptions steht, wenn man da Vorgaben macht, sieht so aus, also würde die Reise @BTE2MQTT für mich hier enden.