Thermostat über MQTT

[dominik]

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]

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]

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]

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]

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]

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 Erweitern

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]

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]

- 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.

- 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).

- 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.

- 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.

(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]

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.

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).

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 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).

[dominik]

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?

- 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.

- 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.

- 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.

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]

Ok, 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.

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 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 Erweitern

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

[dominik]

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]

Ich 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]

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:

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 Erweitern

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 Erweitern

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]

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.

[dominik]

Ich habe mir den OpenMQTTGateway mal genauer angesehen. Was ich dort leider nicht finde, ist eine transparente BLE Bridge Funktionalitaet, oder habe ich das uebersehen?

Wie gesagt, BLE2MQTT uebertragt die BLE Characteristics 1:1, daher weiss ich auch an welches Topic ich was senden muss, da das genau den BLE Characteristics entspricht.

Beispiel

Code Auswählen Erweitern

3fa4585a-ce4a-3bad-db4b-b8df8179ea09
Das ist das Characteristic wo ich die Befehle hinschicke. Es wird automatisch als Reading dargestellt und ich kann per 3fa4585a-ce4a-3bad-db4b-b8df8179ea09/Set dort einen Befehl hinschicken.

Das gatttool hat da nichts mehr damit zu tun. Das gatttool verwende ich nur im 10_EQ3BT.pm Modul um direkt ueber BLE zu kommunizieren.

[Beta-User]

Also, wenn

und ich kann per 3fa4585a-ce4a-3bad-db4b-b8df8179ea09/Set dort einen Befehl hinschicken.

stimmt, könntedas hier evtl. gehen (Format für RAW-Import):

Code Auswählen Erweitern

attr MQTT2_ESP32_17BE44 setList \
  ble_single_set:textField 3fa4585a-ce4a-3bad-db4b-b8df8179ea09/Set $EVTPART1\
  ble_arbitrary_set:textField $EVTPART1/Set $EVTPART1

Der erste würde ein einzelnes einzugebendes Wort (keine Leerzeichen) übertragen, der zweite sollte zusätzlich erlauben, als erstes Wort die BLE-Characteristics zu übertragen.

Irritierend finde ich aber nach wie vor, dass dazu nichts in den Subscriptions auftaucht.


Deine firmware nutzt intern eine C-library namens gattool, wenn ich muß, suche ich das betreffende include für den header im Quelltext. Diese C-Bibliothek war gemeint. Ich gehe davon aus, dass das im Kern dieselbe ist, die du bisher auf dem Pi etc. genutzt hast, nur wird die dabei  halt nicht für Linux/ARM übersetzt, sondern für den ESP, was eben zur Folge hat, dass die von Userseite her anders angesprochen wird/werden muß.

Leider habe ich "gewisse Schwierigkeiten", die firmware zu bauen, sonst würde ich evtl. noch besser helfen können, und wie gesagt, ich habe hier auch ein Device, das erst dann "gesprächig" wird, wenn man ihm was zusendet, von daher wäre es spannend, das selbst "im Betrieb" nachvollziehen zu können...
Falls du also eine Idee hast, an was es hängt (der Compiler bricht bei den WLAN-Bibliotheken ab, Fehler kann ich gerne liefern, scheint an irgendwas in der config.json zu liegen, das ich nicht verstehe/das fehlt) oder mir eine binary zum Download bereitstellen (die firmware hat leider den WLAN-Manager nicht integriert, oder?), dann wäre das super.




Hier auch noch ein List von einem via OMG erzeugten Einzeldevice. Das Format von servicedatauuid scheint dem zu entsprechen, was bei dir BLE-Characteristics genannt wird. Aber es gibt in der Tat afaik bisher keinen Weg, das GW zum Senden zu benutzen (bzw. ich kenne bisher keinen, suche aber auch noch nicht lange).

Code Auswählen Erweitern

defmod MQTT2_BT_Temp_Hum MQTT2_DEVICE oMQTTgw_BT
attr MQTT2_BT_Temp_Hum IODev MQTT2_FHEM_Server
attr MQTT2_BT_Temp_Hum alias Raumfühler
attr MQTT2_BT_Temp_Hum event-min-interval 300
attr MQTT2_BT_Temp_Hum event-on-change-reading batteryPercent,temperature:0.2,humidity:0.2,rssi:5,distance:5
attr MQTT2_BT_Temp_Hum group Heizung
attr MQTT2_BT_Temp_Hum icon temperature_humidity
attr MQTT2_BT_Temp_Hum jsonMap batt:batteryPercent tem:temperature hum:humidity servicedatauuid:0 servicedata:0
attr MQTT2_BT_Temp_Hum model OpenMQTTGateway_BT_temp_hum
attr MQTT2_BT_Temp_Hum readingList home/OpenMQTTGateway_(ESP32_1|Buero)/BTtoMQTT/582D34386429:.* { json2nameValue($EVENT,"",$JSONMAP) }
attr MQTT2_BT_Temp_Hum stateFormat T: temperature°C, H: humidity%rH

setstate MQTT2_BT_Temp_Hum T: 22.7°C, H: 44.9%rH
setstate MQTT2_BT_Temp_Hum 2020-01-05 15:35:13 associatedWith MQTT2_OpenMQTTGateway_Buero
setstate MQTT2_BT_Temp_Hum 2020-03-08 20:45:35 batteryPercent 91
setstate MQTT2_BT_Temp_Hum 2020-03-08 20:49:53 distance 23.44428
setstate MQTT2_BT_Temp_Hum 2020-03-08 20:49:53 humidity 44.9
setstate MQTT2_BT_Temp_Hum 2020-03-08 20:49:53 id 58:2d:34:38:64:29
setstate MQTT2_BT_Temp_Hum 2020-03-08 20:49:53 name MJ_HT_V1
setstate MQTT2_BT_Temp_Hum 2020-03-08 20:49:53 rssi -90
setstate MQTT2_BT_Temp_Hum 2020-01-06 08:11:48 servicedata c38e44accdd9
setstate MQTT2_BT_Temp_Hum 2020-01-06 08:11:48 servicedatauuid 0000ffff-0000-1000-8000-00805f9b34fb
setstate MQTT2_BT_Temp_Hum 2020-03-08 20:49:53 temperature 22.7


@Rudi: (ich könnte das testen oder den Quelltext noch genauer lesen, ist schon klar, aber vermutlich kannst du das ohne weiteres mit ja oder nein beantworten...):
MQTT2_DEVICE ruft beim Auswerten von Perl Code intern ja indirekt AnalyzeCommandChain() auf, wenn ich das richtig interpretiere. Damit sollte u.A. auch verhindert werden, dass FHEM abschmiert, wenn man eine nicht existente Funktion aufruft, oder?

[dominik]

@Beta-User, das setList definieren ist nicht mein Problem. Wie gesagt, mir ging es nur um den Timer. Danke dennoch!

gatttool ist ein command line tool aus dem Bluez Projekt, das nutze ich bislang. Die BLE Characteristics heissen nicht nur bei mir so, das ist im BLE Standard definiert (https://www.bluetooth.com/specifications/gatt/characteristics/). Schade dass OMG keine Funktionalitaet hat um BLE wirklich 1:1 durchzureichen, dann wuerde ich OMG nutzen. Weil mit ble2mqtt kann ich die Logik in FHEM reinpacken und muss nichts am ble2mqtt Gateway adaptieren wenn ich andere Devices integrieren moechte.

@Rudi, du hattest geschrieben, dass ich das gleich wie im Tasmota Modul machen kann, gbit es seitens MQTT2_DEVICE eine OnMessageFn bzw. publishMsg wie aus MQTT? Diese Funktionalitaet ist sehr praktisch, ungern moechte ich die gesamte MQTT Kommunikation in so einem erweiterten Modul integrieren. Ansonsten wuerde ich X_Notify nutzen um auf die Readings im MQTT2_DEVICE zu reagieren.

[rudolfkoenig]

gbit es seitens MQTT2_DEVICE eine OnMessageFn bzw. publishMsg wie aus MQTT?

OnMessageFn entspricht NotifyFn, und publishMsg ist equivalent mit IOWrite($hash, "publish", "topic message").
Lieber waere mir CommandSet(undef, "set IODev publish topic message"), dann bliebt die MQTT2_SERVER<=>MQTT2_DEVICE Schnittstelle "privat".

[dominik]

Super, danke, damit kann ich loslegen Dann werde ich mich mal ans weitere Testen machen.

[dominik]

Zur Info, leider laeuft BLE2MQTT nicht so stabil wie ich mir das erwartet haette. Generell ist das eine super Software, nur kann es schon mal vorkommen, dass die Verbindung zum BLE Device verloren geht. Schade...

Somit habe ich mich entschieden einen 2. RPi hinzustellen und dort mit FHEM meine BLE FHEM Module zu verwenden. Einzig FHEM2FHEM finde ich noch etwas "umstaendlich" in der Handhabung, da ich gerne das gesamte Device (cmd und Readings) am Master FHEM haette. Vielleicht bau ich da noch was...

[dominik]

Zur Info, ich habe nun ein eigenes Modul geschrieben um Devices einfach von einem "Remote FHEM" in einen "Master FHEM" zu übertragen und von dort auch steuerbar zu machen. Damit laufen nun alle meine Bluetoothgeräte über den 2. RPi.

Link: https://forum.fhem.de/index.php?topic=109308.msg1032785#msg1032785