Shelly BLU devices

[gvzdus]

Ich wundere mich, ob ich wirklich nur schlecht gesucht habe: Aber wie bindet man Shelly BLU devices ein?

Zum Hintergrund: Zu dem Zoo gehören die Shelly BLU Button, BLU Motion, BLU Door&Window u.s.w. Shelly hat wohl den Versuch aufgegeben, batteriegetriebene Geräte mit Wifi anzubinden und ist auf Bluetooth gewechselt. Nun muss ein Gen2 oder Gen3-Gerät das Bluetooth-Gateway bereitstellen.
Zum Ärger u.a. auch von Matthias Kleine gibt es keinen Standard, wie die Events von den Devices per MQTT propagiert werden (Shelly hat das wohl mal angekündigt, aber bis heute nicht implementiert). Stattdessen muss man ein eigenes Script aktivieren, und damit stellt sich die Frage der Vereinheitlichung.

Ich habe jetzt auf meinen Gateway-Shellys das "Library-Script" ble-shelly-dw.js geladen und modifiziert. In der Library wird es als "BLE in Scripting - Shelly BLU DoorWindow script actions" angepriesen.

Hier habe ich nun folgende Änderung eingetragen (1. Zeile als Suchpunkt):

Code Auswählen Erweitern

console.log("Shelly BTH packet: ", JSON.stringify(BTHparsed));
  if (MQTT.isConnected()) {
    MQTT.publish("bthome/bth_" + res.addr, JSON.stringify(BTHparsed));
  }
Das führt nun dazu, dass BThome-Events unterhalb des Gateway-MQTT-Devices angelegt werden: Es entsteht ein erweitertes readingList:

Code Auswählen Erweitern

  readingList shelly2pmg3_34cdb077312c:badoben2pm/online:.* online
shelly2pmg3_34cdb077312c:badoben2pm/events/rpc:.* { json2nameValue($EVENT, 'rpc_', $JSONMAP) }
shelly2pmg3_34cdb077312c:bthome/bth_3c_2e_f5_bc_2e_c7:.* { json2nameValue($EVENT, 'bth_3c_2e_f5_bc_2e_c7_', $JSONMAP) }

Das habe ich jetzt in meinem Fall dann so angepasst:

Code Auswählen Erweitern

  readingList shelly2pmg3_34cdb077312c:badoben2pm/online:.* online
shelly2pmg3_34cdb077312c:badoben2pm/events/rpc:.* { json2nameValue($EVENT, 'rpc_', $JSONMAP) }
shelly2pmg3_34cdb077312c:bthome/bth_3c_2e_f5_73_2b_37:.* { json2nameValue($EVENT, 'bthome_badtuer_', $JSONMAP) }
shelly2pmg3_34cdb077312c:bthome/bth_3c_2e_f5_fb_3a_c6:.* { json2nameValue($EVENT, 'bthome_badfenster_', $JSONMAP) }
shelly2pmg3_34cdb077312c:bthome/bth_7c_c6_b6_91_c0_8d:.* { json2nameValue($EVENT, 'bthome_badswitch_', $JSONMAP) }

Nun kann ich also Events von den verschiedenen BLU-Devices sauber und mit sprechenden Namen weiterverarbeiten und bin damit am Ziel.

ABER:
Die Lösung hat den Nachteil, dass bei mehreren Gateway-Shellys unter jedem Gateway-Shelly die Readings angelegt werden.
Am schönsten wäre natürlich, wenn die BLU-Geräte als eigene FHEM-Devices angelegt würden. Das würde aber zum einen eine Konvention erfordern, mit welchem Script und Topic die BTHome-Events propagiert werden, und zum anderen wohl Änderungen am Autocreate von MQTT.

Bin ich wirklich der Erste, der sich die Gedanken macht?

[rudolfkoenig]

Ich wuerde das mit dem bridgeRegexp loesen, das ist fuer Gateway Geraete vorgesehen:
https://fhem.de/commandref_modular.html#MQTT2_DEVICE-attr-bridgeRegexp

Used to automatically redirect some types of topics to different MQTT2_DEVICE instances. The regexp is checked against the clientid:topic:message and topic:message. The newClientId is a perl expression!. Example:
attr zigbee2mqtt bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"
will create different MQTT2_DEVICE instances for different hex numbers in the topic. Note: the newClientId is enclosed in "", as it is a perl expression, should be unique, and the automatically created device will be created also with this name.
Notes:
multiple tuples of <regexp> newClientId are separated by newline
setting bridgeRegexp will remove the readingList attribute and all readings.
For a zigbee2mqtt device connected via MQTT2_SERVER the following is probably a better solution:
attr zigbee2mqtt bridgeRegexp zigbee2mqtt/0x........([^/]+):.* "zigbee_$1"

[gvzdus]

Das funktioniert schon sehr genial gut. Und schreit nach einer Wiki-Seite, damit "das Internet" es findet.
Magst Du bitte noch einmal über die Lösung schauen, ob es Verbesserungspotential gibt?

Ich habe folgende bridgeRegexp gesetzt (auf allen Shellys, die als Gateway mit dem Script arbeiten):

Code Auswählen Erweitern

.*:bthome/bth_([0-9a-f_]*)/d:.* "bthome_$1"
Das Script auf den Shellys habe ich so geändert ("/d" hinten dran):

Code Auswählen Erweitern

    MQTT.publish("bthome/bth_" + res.addr+"/d", JSON.stringify(BTHparsed));

Dann funktioniert es so: Neues BLU-Gerät auspacken, Taste drücken / schütteln, in FHEM wird ein neues Gerät angelegt:

Code Auswählen Erweitern

Internals:
   CID        bthome_3c_2e_f5_69_bb_07
   DEF        bthome_3c_2e_f5_69_bb_07
   FUUID      6715f9dc-f33f-8d06-2353-b11f4ccc28470f22
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_CONN MQTT2_FHEM_Server_192.168.0.127_50411
   MQTT2_FHEM_Server_MSGCNT 3
   MQTT2_FHEM_Server_TIME 2024-10-21 09:08:55
   MSGCNT     3
   NAME       MQTT2_bthome_3c_2e_f5_69_bb_07
   NR         545
   STATE      ???
   TYPE       MQTT2_DEVICE
   eventCount 3
   READINGS:
     2024-10-21 09:04:05   IODev           MQTT2_FHEM_Server
     2024-10-21 08:51:08   associatedWith  solarshelly
     2024-10-21 09:08:55   d_BTHome_version 2
     2024-10-21 09:08:55   d_addr          3c:2e:f5:69:bb:07
     2024-10-21 09:08:55   d_battery       100
     2024-10-21 09:08:55   d_button        1
     2024-10-21 09:08:55   d_encryption    false
     2024-10-21 09:08:55   d_pid           30
     2024-10-21 09:08:55   d_rssi          -92
Attributes:
   readingList bthome/bth_3c_2e_f5_69_bb_07/d:.* { json2nameValue($EVENT, 'd_', $JSONMAP) }
   room       MQTT2_DEVICE
Frage: Kriegt man das "d_" als Prefix der Readings noch weg? Wenn ich das Topic wie ursprünglich mit "bthome/bth_<addr>" enden lasse, wandert die Adresse mit in die Readings beim Autocreate.

[rudolfkoenig]

Und schreit nach einer Wiki-Seite, damit "das Internet" es findet.

Sowas gibts hier https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#bridgeRegexp
Vermutlich braucht es noch SEO
Ich habe bridgeRegexp zwar eingebaut, aber die Jungs von der attrTemplate Front (siehe /opt/fhem/FHEM/lib/AttrTemplate/mqtt2.template) haben mehr Erfahrung in der Anwendung.

Kriegt man das "d_" als Prefix der Readings noch weg?

Ich glaube es liegt daran, dass du zu "complex" denkst
https://fhem.de/commandref_modular.html#MQTT2_SERVER-attr-autocreate

[Beta-User]

Ich glaube es liegt daran, dass du zu "complex" denkst

Vermutlich ist "complex" schon (vorsorglich!) ok, aber als mittleres Argument würde ich hier halt einfach "nichts" verwenden:

Code Auswählen Erweitern

   readingList bthome/bth_3c_2e_f5_69_bb_07/d:.* { json2nameValue($EVENT, '', $JSONMAP) }

[...] gibt es keinen Standard, wie die Events von den Devices per MQTT propagiert werden (Shelly hat das wohl mal angekündigt, aber bis heute nicht implementiert). Stattdessen muss man ein eigenes Script aktivieren, und damit stellt sich die Frage der Vereinheitlichung.

Deswegen würde ich hier bei der langen Form von json2nameValue() bleiben, dann kann man das via attrTemplate vereinheitlichen.

Bin ich wirklich der Erste, der sich die Gedanken macht?

Jein. Für Shelly gibt es sowas noch nicht, aber im Prinzip ist es kaum ein Unterschied, ob man ein OpenMQTTGateway (oder ein Tasmota-BLE-GW) verwendet. Jedenfalls zu ersterem gibt es einen (rudimentären) attrTemplate-Satz und einen oder mehrere Threads, die sich mit dem Vereinzeln usw. befassen.

Falls du einen attrTemplate-Satz bereitstellen willst: feel free, wir können uns den "Maintainer" gerne teilen (Otto123 mischt da auch mit).

[gvzdus]

Hmmh, ja, mit nachträglichem Anpassen der Reading-List im angelegten BThome-Device geht es natürlich.
Aber ich suche ja nach einer Möglichkeit, dass eine Nachricht:

Code Auswählen Erweitern

bthome/bth_" + res.addr+"/d" {"encryption":false,"BTHome_version":2,"pid":31,"battery":100,"button":1,"addr":"3c:2e:f5:69:bb:07","rssi":-
12:45:20
88}
direkt dazu führt, dass ein Device mit dem Namen der Adresse angelegt wird, dessen Readings aber "battery" u.s.w. ohne "d_" heißen.
Sende ich als Topic nur

Code Auswählen Erweitern

"bthome/bth_" + res.addr+"",
und ändere die "bridgeRegex" auf:

Code Auswählen Erweitern


.*:bthome/bth_([0-9a-f_]*):.* "bthome_$1"
so wird das BThome-Gerät richtig hässlich angelegt, nämlich so:

Code Auswählen Erweitern

bthome/bth_e8_e0_7e_be_e3_ca:.* { json2nameValue($EVENT, 'bth_e8_e0_7e_be_e3_ca_', $JSONMAP) }
Sprich: Fällt Dir etwas ein, was ich an bridgeRegex und Topic "drehen" könnte, sodass das Reading nur "battery" heisst, also das automatisch angelegte readingList im Prefix leer ist?

Ein AttrTemplate könnte man bauen, aber im Kern wäre das nur ein schönes DevState-Icon . Es sind ja alles Sensoren.

[Beta-User]

Fällt Dir etwas ein, was ich an bridgeRegex und Topic "drehen" könnte, sodass das Reading nur "battery" heisst, also das automatisch angelegte readingList im Prefix leer ist?

Ein AttrTemplate könnte man bauen, aber im Kern wäre das nur ein schönes DevState-Icon . Es sind ja alles Sensoren.

Na ja, "a)" könnte man lösen, indem man Rudi's Vorschlag umsetzt und den default für autocreate in MQTT2_SERVER verwendet...

Aber: Korrekterweise heißt dieses Reading eben nicht "battery", sondern "batteryPercent" (siehe Namenskonventionen zu Readings), und das könnte man via jsonMap gradeziehen. Daher der Vorschlag, das via attrTemplate zu lösen.

[gvzdus]

Jetzt ist der Groschen auch bei mir gefallen - die URL hatte ich unter Rudis Reply nicht wahrgenommen.
Gibt es außer "batteryPercent" gar inzwischen noch andere Standards?
Ich habe nur folgende Wiki-Seite ergoogled: https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings
Und: Welches AttrTemplate gefällt Dir denn herausragend gut für Sensoren? Ich habe aktuell zum Testen im Zoo:

• Shelly BLU Wallswitch 4 (4 Buttons)
• Shelly BLU Button
• Shelly BLU Door/Window
• Shelly BLU Motion

Was ich nicht habe, ist der "H&T"-Sensor.
Wenn ich AttrTemplate richtig verstehe, könnte man über etwas wie filter:TYPE=MQTT2_DEVICE:FILTER=CID~bthome_.* automatisch selektieren.
Da ich ja das Skript auf dem Shelly "unter Kontrolle" habe, könnte ich "bthome_" auch per Erkennung der Merkmale des BThome-Pakets ausdifferenzieren, also z.B. "bth_(motion|switch|sens|ht)_".

[gvzdus]

P.S. Ich hänge mal die Beispiele dran, wie sie kommen:
Das "batteryPercent" kann ich natürlich direkt im Shelly-Script umsetzen.

Shelly BLU Button:

Code Auswählen Erweitern

{"encryption":false,"BTHome_version":2,"pid":36,"battery":100,"button":1,"addr":"3c:2e:f5:69:bb:07","rssi":-85}
Shelly Door&Window:

Code Auswählen Erweitern

{"encryption":false,"BTHome_version":2,"pid":136,"battery":100,"illuminance":36,"window":0,"rotation":0,"addr":"3c:2e:f5:bc:2e:c7","rssi":-46}
Shelly Motion:

Code Auswählen Erweitern

{"encryption":false,"BTHome_version":2,"pid":156,"battery":100,"illuminance":250,"motion":1,"addr":"38:39:8f:9a:2b:c1","rssi":-82}
Shelly Wallswitch 4:

Code Auswählen Erweitern

{"encryption":false,"BTHome_version":2,"pid":108,"battery":100,"button_0":0,"button_1":1,"button_2":0,"button_3":0,"addr":"7c:c6:b6:91:c0:8d","rssi":-59}

[Beta-User]

Gibt es außer "batteryPercent" gar inzwischen noch andere Standards?

Afaik nicht wirklich; hatte hier mal was angeschubst: https://forum.fhem.de/index.php?msg=1123606

Das "batteryPercent" kann ich natürlich direkt im Shelly-Script umsetzen.

Stellt sich halt die Frage, was der (aus User-Sicht) einfachere Weg ist. Nach meinen bisherigen Erfahrungen ist es schwierig, wenn man als User an mehreren Enden anfassen muss und ggf. dann immer wieder ein script/eine config/... auf irgendeinem entfernten Gerät anfassen müßte, sobald man wieder ein neues Gadget in der Hand hat - und gerade die Shelly-Macher sind immer wieder für (unangenehme!) Überraschungen gut...

Wenn ich AttrTemplate richtig verstehe, könnte man über etwas wie filter:TYPE=MQTT2_DEVICE:FILTER=CID~bthome_.* automatisch selektieren.

Jup. Die Idee hinter diesem Filter (bzw. auch hinter dem kompletten Deaktivieren einzelner Gruppen von templates) ist, dass der User zwar eine Idee bekommt, wie groß die Vielfalt ist, aber dann eben auch bestimmte Gruppen nur angezeigt bekommt, wenn er "passende" Devices hat.

nd: Welches AttrTemplate gefällt Dir denn herausragend gut für Sensoren?

Die Frage kann man mAn. so nicht stellen. Bin grade wieder bei der Umstellung auf zigbee2mqtt, und da ist es oft so, dass man sich jedes Device (bzw. teils jeden schaltbaren Kanal) einzelner Devices genauer ansehen muss, damit man am Ende sowas wie "standardisierte und FHEM-konforme" Devices erhält. Beispiele:

Code Auswählen Erweitern

{"encryption":false,"BTHome_version":2,"pid":136,"battery":100,"illuminance":36,"window":0,"rotation":0,"addr":"3c:2e:f5:bc:2e:c7","rssi":-46}Soll wäre für "window" (Vorschlag): "contact" (oder "state"?) mit "open" bzw. "closed"

Code Auswählen Erweitern

{"encryption":false,"BTHome_version":2,"pid":156,"battery":100,"illuminance":250,"motion":1,"addr":"38:39:8f:9a:2b:c1","rssi":-82}"motion" ist auch so ein Kandidat. Auch da wäre ggf. motion/nomotion statt 1/0 wünschenswert, ob im Reading "motion" wäre die weitere Frage...

Beispiel, wie das ginge: zigbee2mqtt_ContactSensor

[Beta-User]

...war hier auch schon mal ein Thema: https://forum.fhem.de/index.php?topic=137277.0