grüß euch,
eigentlich kein problem, da alles funktioniert, aber schön ist anders. und meine ideen sind ... nicht vorhanden *g*
o) eine readingsgroup, die meine batteriestände ausliest - funktioniert
o) ich habe z.b. eine shelly steckdose per wlan über mqtt in fhem eingebunden
o) zu dieser dose ist ein derzeit ein bt-taster von shelly angehängt ... die daten des tasters stehen als readings in der steckdose zur verfügung.
o) ich habe eine readingsgroup, die die batteriestände anzeiget ... ab nun wirds unschön
nachdem die bt-devices in den wlandevices einfach als z.b. "params_bthomedevice_200_battery" stehen, ist das schönste, was mir bei obiger readingsgroup angezeigt wird der alias der wlan-steckdose (mapping %ALIAS)
frage:
gibt es wege, den verschiedenen bt-devices in der readingsgroup namen zuzuordnen.
weil wirklich unschön wird das ganze, sobald mehrere bt-devices an einem wlan-device hängen.
d.h.: mehrere bt-devices werden in meiner readingsgroup zwar ihre batteriestände zeigen, aber immer unter dem namen des wlan-devices.
schöner wäre natürlich, wenn ich zu jeder batterieanzeige einen namen des entsprechenden bt-devices haben würde.
hier mal die aktuelle rg:defmod rg_battery readingsGroup .*:[Bb]attery\
.*:params_.*_battery
attr rg_battery mapping %ALIAS
Zitat von: the ratman am 05 April 2026, 09:58:38frage:
gibt es wege, den verschiedenen bt-devices in der readingsgroup namen zuzuordnen.
weil wirklich unschön wird das ganze, sobald mehrere bt-devices an einem wlan-device hängen.
Wer oder was ist denn dafür zuständig, das die Daten von Deinem BT-Taster am MQTT-Broker ankommen ?
Da muss es doch irgendein Script auf dem Shelly geben. Dort kannst Du auch konfigurieren, was an den Broker gesendet wird.
nö, die shellys sind bei mir per mqtt eingebunden, weil meines wissens nach, das shellymodul das bt-device gar nicht darstellen könnte. oder hat sich da was getan?
das stellt auf jeden fall für fhem dann als ein einzelnes device dar. also die wlan-steckdose + zusätzliche readings für die darüber "gerouteten" bt-devices.
sprich: für fhem ist das ein gerät.
ein screenshot mal von teilen der steckdose (als rawdef reinstellen zeigt ja in dem fall keine readings):
die gefärbten readings gehören dem bt-device. darunter gehts dann mit den readings der eigentlichen steckdose weiter
Screenshot 2026-04-05 163143.jpg
Zitat von: the ratman am 05 April 2026, 16:26:05nö
Was nö ? Habe schon verstanden, das die Shellydaten via MQTT reinkommen.
Ich habe bei mir für jedes BT-Gerät ein eigenes MQTT-Device angelegt.
Wie die Readings aufgebaut sind, wenn man alles in ein MQTT-Device schaufelt, weiß ich daher nicht.
Ich würde Dir ja empfehlen, es sauber zu trennen. Dazu musst Du eben auf dem BT-Shelly Host ein Script laufen lassen.
Es gibt schon was fertiges zum anpassen auf GitHub (https://github.com/Refhi/Shelly-BLU-to-MQTT/blob/main/blu%20to%20mqtt.js) falls Du Dich für diesen Weg entscheiden solltest
eigentlich will ich nicht auch noch anfangen, scripte auf dem shelly zu basteln, von denen ich dann auch wieder keine ahnung hab.
es rennt ja alles - ich hab nur das problem, nicht zu wissen, wie ich anstelle des namens des wlangeräts einen für das bt device in der readingsgroup basteln kann.
ok, ist natürlich Deine Entscheidung.
Ich weiß auch nicht in welchem Reading der Name des BT-Devices stehen soll.
Wie man das dann in einer Readingsgroup auseinanderfrickelt, kann ich Dir auch nicht beantworten.
Da müssten eher Readingsgroup-Experten einen Blick drauf werfen.
ich denke, der name is bthomedevice_200.
ich würde dem ja notfalls auch händisch einen namen in der rg vergeben. aber auch da ist die frage des wie ...
scheint wohl nicht vorgesehen zu sein, den klarnamen, den man im shelly vergeben kann, per mqtt weiter zu geben.
Zitat von: the ratman am 05 April 2026, 17:38:50scheint wohl nicht vorgesehen zu sein, den klarnamen, den man im shelly vergeben kann, per mqtt weiter zu geben.
Nur auf dem von mir genannten Weg. Läuft bei mir tadellos.
Zitat von: the ratman am 05 April 2026, 17:38:50ich denke, der name is bthomedevice_200.
Dann ist der Devicename gleich bzw. ein Teil des Readingsnamens. Was es nochmal schwieriger macht.
Als ReadingsValue hast Du ja nur den <name>:200
Also wenn es nur mit einer Readingsgroup aufgedröselt werden kann, dann aber von einem Anderen Helfer.
Wenn Du Dich für meinen Weg entscheiden solltest und nicht klappt, dann sag an welcher Stelle Du nicht weiterkommst.
Der Readingsgroup-Teil ist dann wesentlich einfacher und bekommst Du vermutlich selbst hin.
ich schau mir deinen weg gerne an. kriegt man auch sicher hin.
nur entziehen sich solche scriptorgien immer meinem verständnis. bin da ne totale nulpe. ist dann was zu drehen dran, komm ich ohne hilfe nicht weiter. das macht dann wenig spaß.
drum mein versuch, möglichst simpel zu bleiben.
ich will Dich hier von nix überzeugen. Ich sag nur wie ich es mache.
Außerdem ist mein Weg von Deinem autark und kann auch parallel betrieben werden.
Evtl. kommt aber auch noch der Readingsgroupgott und hat eine einfache Lösung.
Bin völlig bei JudgeDredd, hatte dazu neulich bereits das hier geschrieben, soweit ich das sehen kann, ist v.a. der jetzt fett hervorgehobene Teil nicht beantwortet:
Zitat von: Beta-User am 26 Februar 2026, 11:58:30Zitat von: the ratman am 07 Februar 2026, 17:21:52shelly blu ht
Die Shelly kennen teilweise diverse Einstellungen, die ich sämtlich nicht kenne. Bitte erst mal versuchen, ob man die firmware dazu überreden kann, für jedes BT-Device einen eigenen (sub-)Topic zu verwenden, analog wie OpenMQTTGateway das z.B. tut. Sonst ist es wie (fast) immer bei Shelly: undurchsichtiger Mist.
In jedem Fall wäre es für mich hilfreich zu sehen, welche (zu dem BT-Ding gehörenden) Topic/Payload-Kombinationen es in etwa gibt.
Als Anregung - bitte mal in den zigbee2tasmota-Thread (bzw. diese Templates) schauen; soweit ich mich entsinne, musste man da auch was aus der Payload rausoperieren, um einen (kleineren) JSON-Blob zu bekommen, mit dem man (halbwegs) was anfangen kann...
Das würde dazu führen, dass man ggf. wenigstens direkt mit FHEM-MQTT-Mitteln separate Devices erhalten könnte.
Weitere Alternativen, um sinnvolle Device-Strukturen für sowas zu basteln:
- readingsProxy, wobei hier die modifizierte Fassung von Boris (bitte selber suchen) ein gutes Testfeld hätte.
- Im Developer-Bereich hatte ich auch mal einen Modul-stub namens subDeviceProxy gepostet, das könnte hier ggf. auch weiterhelfen... (wenn sowas benutzt wird, habe ich ggf. auch mehr Motivation, das zu finalisieren.)
ich dank euch mal, und schau mich um ...