Thermostat über MQTT

[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