Hallo,
Ich versuche 3 SMA Wechselrichter ueber SBFspot und Mqtt auszulesen.
SBFspot funktioniert und published.
Ich bekomme allerdings kein autocreate hin. Tasmoto Steckdose funktioniert sofort.
Das device hat folgende Einstellungen und ist auf einem Raspi4 installiert.
Zitat### MQTT Settings start ###
MQTT_Publisher=/usr/bin/mosquitto_pub
# MQTT Broker in Fhem
MQTT_Host=192.168.1.97
MQTT_Port=1883
MQTT_Topic=sbfspot_{serial}
# Format of message items to be sent
# JSON: MQTT_ItemFormat="{key}": {value}
# TEXT: MQTT_ItemFormat={key}:{value}
# XML: MQTT_ItemFormat=<item name="{key}" value="{value}" />
MQTT_ItemFormat="{key}": {value}
MQTT_ItemDelimiter=comma
# JSON: MQTT_PublisherArgs=-h {host} -t {topic} -m "{{message}}"
# TEXT: MQTT_PublisherArgs=-h {host} -t {topic} -m "{message}"
# XML : MQTT_PublisherArgs=-h {host} -t {topic} -m "<mqtt_message>{message}</mqtt_message>"
MQTT_PublisherArgs=-h {host} -t {topic} -m "{{message}}"
# Data to be published (comma delimited)
MQTT_Data=Timestamp,SunRise,SunSet,InvSerial,InvName,InvTime,InvStatus,InvTemperature,InvGridRelay,EToday,ETotal,PACTot,UDC1,UDC2,IDC1,IDC2,PDC1,PDC2
### MQTT Settings end ###
Der in Fhem installierte Mqtt2 Server(Broker) liest folgende publish von 3 verschiedenen Solar Wechselrichtern
### EladaBroker start ###
2020.12.14 12:25:12 5: in: PUBLISH: 0(139)(3)(0)(18)sbfspot_1100245644{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 1100245644,"InvName": ","InvTime": "14/12/2020 12:25:57","InvStatus": "Ok","InvTemperature": 0.000,"InvGridRelay": "?","EToday": 1.807,"ETotal": 38677.351,"PACTot": 725.000,"UDC1": 140.000,"UDC2": 0.000,"IDC1": 5.660,"IDC2": 0.000,"PDC1": 800.000,"PDC2": 0.000}
2020.12.14 12:25:12 4: EladaBroker_192.168.1.97_49576 mosqpub|30061-raspberry PUBLISH sbfspot_1100245644:{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 1100245644,"InvName": ","InvTime": "14/12/2020 12:25:57","InvStatus": "Ok","InvTemperature": 0.000,"InvGridRelay": "?","EToday": 1.807,"ETotal": 38677.351,"PACTot": 725.000,"UDC1": 140.000,"UDC2": 0.000,"IDC1": 5.660,"IDC2": 0.000,"PDC1": 800.000,"PDC2": 0.000}
2020.12.14 12:25:12 5: EladaBroker: dispatch autocreate=simple\000mosqpub_30061_raspberry\000sbfspot_1100245644\000{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 1100245644,"InvName": ","InvTime": "14/12/2020 12:25:57","InvStatus": "Ok","InvTemperature": 0.000,"InvGridRelay": "?","EToday": 1.807,"ETotal": 38677.351,"PACTot": 725.000,"UDC1": 140.000,"UDC2": 0.000,"IDC1": 5.660,"IDC2": 0.000,"PDC1": 800.000,"PDC2": 0.000}
2020.12.14 12:25:12 5: in: DISCONNECT: (224)(0)
2020.12.14 12:25:12 4: EladaBroker_192.168.1.97_49576 mosqpub|30061-raspberry DISCONNECT
2020.12.14 12:25:12 4: Connection accepted from EladaBroker_192.168.1.97_49578
2020.12.14 12:25:12 5: in: CONNECT: (16)#(0)(4)MQTT(4)(2)(0)<(0)(23)mosqpub|30063-raspberry
2020.12.14 12:25:12 4: EladaBroker_192.168.1.97_49578 cid:mosqpub|30063-raspberry CONNECT V:4 keepAlive:60
2020.12.14 12:25:12 5: out: CONNACK: (2)(0)(0)
2020.12.14 12:25:12 5: in: PUBLISH: 0(145)(3)(0)(18)sbfspot_2100196497{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 2100196497,"InvName": ","InvTime": "14/12/2020 12:25:55","InvStatus": "Ok","InvTemperature": 37.760,"InvGridRelay": "?","EToday": 3.184,"ETotal": 46796.670,"PACTot": 1103.000,"UDC1": 195.580,"UDC2": 235.460,"IDC1": 4.511,"IDC2": 0.950,"PDC1": 881.000,"PDC2": 223.000}
2020.12.14 12:25:12 4: EladaBroker_192.168.1.97_49578 mosqpub|30063-raspberry PUBLISH sbfspot_2100196497:{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 2100196497,"InvName": ","InvTime": "14/12/2020 12:25:55","InvStatus": "Ok","InvTemperature": 37.760,"InvGridRelay": "?","EToday": 3.184,"ETotal": 46796.670,"PACTot": 1103.000,"UDC1": 195.580,"UDC2": 235.460,"IDC1": 4.511,"IDC2": 0.950,"PDC1": 881.000,"PDC2": 223.000}
2020.12.14 12:25:12 5: EladaBroker: dispatch autocreate=simple\000mosqpub_30063_raspberry\000sbfspot_2100196497\000{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 2100196497,"InvName": ","InvTime": "14/12/2020 12:25:55","InvStatus": "Ok","InvTemperature": 37.760,"InvGridRelay": "?","EToday": 3.184,"ETotal": 46796.670,"PACTot": 1103.000,"UDC1": 195.580,"UDC2": 235.460,"IDC1": 4.511,"IDC2": 0.950,"PDC1": 881.000,"PDC2": 223.000}
2020.12.14 12:25:12 5: in: DISCONNECT: (224)(0)
2020.12.14 12:25:12 4: EladaBroker_192.168.1.97_49578 mosqpub|30063-raspberry DISCONNECT
2020.12.14 12:25:12 4: Connection accepted from EladaBroker_192.168.1.97_49580
2020.12.14 12:25:12 5: in: CONNECT: (16)#(0)(4)MQTT(4)(2)(0)<(0)(23)mosqpub|30069-raspberry
2020.12.14 12:25:12 4: EladaBroker_192.168.1.97_49580 cid:mosqpub|30069-raspberry CONNECT V:4 keepAlive:60
2020.12.14 12:25:12 5: out: CONNACK: (2)(0)(0)
2020.12.14 12:25:12 5: in: PUBLISH: 0(144)(3)(0)(18)sbfspot_2100188305{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 2100188305,"InvName": ","InvTime": "14/12/2020 12:25:50","InvStatus": "Ok","InvTemperature": 36.990,"InvGridRelay": "?","EToday": 1.106,"ETotal": 44000.432,"PACTot": 843.000,"UDC1": 236.300,"UDC2": 234.910,"IDC1": 1.033,"IDC2": 2.599,"PDC1": 243.000,"PDC2": 610.000}
2020.12.14 12:25:12 4: EladaBroker_192.168.1.97_49580 mosqpub|30069-raspberry PUBLISH sbfspot_2100188305:{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 2100188305,"InvName": ","InvTime": "14/12/2020 12:25:50","InvStatus": "Ok","InvTemperature": 36.990,"InvGridRelay": "?","EToday": 1.106,"ETotal": 44000.432,"PACTot": 843.000,"UDC1": 236.300,"UDC2": 234.910,"IDC1": 1.033,"IDC2": 2.599,"PDC1": 243.000,"PDC2": 610.000}
2020.12.14 12:25:12 5: EladaBroker: dispatch autocreate=simple\000mosqpub_30069_raspberry\000sbfspot_2100188305\000{"Timestamp": "14/12/2020 12:25:12","SunRise": "14/12/2020 07:51:00","SunSet": "14/12/2020 17:14:00","InvSerial": 2100188305,"InvName": ","InvTime": "14/12/2020 12:25:50","InvStatus": "Ok","InvTemperature": 36.990,"InvGridRelay": "?","EToday": 1.106,"ETotal": 44000.432,"PACTot": 843.000,"UDC1": 236.300,"UDC2": 234.910,"IDC1": 1.033,"IDC2": 2.599,"PDC1": 243.000,"PDC2": 610.000}
2020.12.14 12:25:12 5: in: DISCONNECT: (224)(0)
2020.12.14 12:25:12 4: EladaBroker_192.168.1.97_49580 mosqpub|30069-raspberry DISCONNECT
### EladaBroker end ###
Was muss ich machen um ein autocreate zu erzielen?
Wie werden die readings erzeugt? Bei Tasmota kann ich das ueber ein Template das in Fhem existiert erreichen.
MQTT2_SERVER will afaik zwingend eine ClientID von allen Clients. Das solltest du zunächst mal ergänzen, dann sehen wir weiter...
MQTT2_DEVICE fuehrt kein autocreate aus fuer die von mosquitto_pub per Voreinstellung generierten ClientID.
Mit "-i XXX" kann man das aendern.
Die readings werden aus der Software SBFspot erzeugt. Die Angaben zu Mqtt sind aus einer vorgegebenen config Datei. Kann ich die client ID eventuell selbst vergeben oder sollte ich den Provider von SBFspot bitten diese zu ergaenzen?
Na ja, hier könntest du das einfach in den publish-Command einbauen, oder?
MQTT_PublisherArgs=-h {host} -t {topic} -i "sbfspot_{serial}" -m "{{message}}"
@Rudi: in den "Praxisbeispielen@Wiki" habe ich jetzt noch was bei "autocreate will nicht" eingefügt. Evtl. noch was bei "autocreate" in der cref? (Ich kann mich aber auch nicht an den Grund für die Sonderbehandlung von mosquito_pub erinnern).
Das meint SBFspot kann fuer die drei Wechselrichter eine client ID mitgeben?
Grund fuer Sonderbehandlung: mosqutto generiert zufaellige ClientIDs (mosq-64xMUrGgX1nI6ZWCod, mosq-7hhJdneTV5RqSmu5iu, etc), ich (und vmtl. andere) testen gerne mit mosquitto_pub, und ich will nicht "Muell" angelegt haben.
Sorry Pause vorbei bin in ca. 2h wieder da.
Zitat von: rudolfkoenig am 14 Dezember 2020, 13:25:03
Grund fuer Sonderbehandlung: mosqutto generiert zufaellige ClientIDs (mosq-64xMUrGgX1nI6ZWCod, mosq-7hhJdneTV5RqSmu5iu, etc), ich (und vmtl. andere) testen gerne mit mosquitto_pub, und ich will nicht "Muell" angelegt haben.
...hatte ich früher auch gemacht, aber mit m2server und rePublish kann man auch zumindest einzelne "Spezialfälle" auch gut testen. (Aber auch da ist die CID "seltsam"). ignoreRegexp ist für "Power-User" keine gute Lösung?
Ansonsten _glaube_ ich, dass es gut wäre, entweder prominenter darauf hinzuweisen, wie man das Problem umgehen kann, oder den SERVER entsprechend konfigurieren zu können, dass er es "frisst". mosquitto_pub ist eben auch ein omnipräsentes Tool, mit dem man "eben mal schnell was zusammenscripten" kann (auf praktisch jeder Linux-Kiste)...
(sieht man ja hier...)
Zitat von: Willi Wurst am 14 Dezember 2020, 13:22:40
Das meint SBFspot kann fuer die drei Wechselrichter eine client ID mitgeben?
Wenn ich das richtig verstanden habe, löst das script diverse Parameter aus, und das war der Versuch, das so weiterzustricken, dass eine passable ClientID erzeugt wird (für jeden WR eine, vermute ich jedenfalls).
mosquitto_pub eignet sich wegen dem automatisch generierten ClientID nicht fuers autocreate.
Jedenfalls fehlt mir die Fantasie dafuer.
Hmm, ja, auch wieder wahr...
Wenn, dann müßte man die in diesen Fällen entfernen, aber das jeweils zu prüfen ist vermutlich auch eine Sch...idee,...
Vielleicht als Merkposten: Bin mir nicht sicher, ob wir bei dem paho-Framework ("mqttjs_.*" (?))nicht genauso verfahren sollten. Hatte heute wieder einen User, der darüber gestolpert ist: https://forum.fhem.de/index.php/topic,116622.msg1110465.html#msg1110465. Da ist es nicht ganz so dramatisch, weil die random-CID "nur" bei jedem Start von so einem Java-Dienst erzeugt wird.
Weiß aber auch nicht, was besser ist: kein autocreate oder ständig neue Devices bei Usern, die nicht verstehen, wo es herkommt.
Ich sehe die Probleme bei der Nutzung von ClientID in FHEM, aber ich meine immer noch, dass es den Anfaengern hilft.
Womoeglich brauchen wir Migrationshilfen wie das Loeschen vom ClientId von allen readingsList oder beim automatisches Anlegen der ersten MQTT2_DEVICE vom MQTT2_CLIENT aus das Setzen eines bridgeRegexps.
Das mit Berücksichtigung der ClientID ist auf alle Fälle die "sauberere" Lösung, und es ist immer ein Problem, auf Eindeutigkeit zu verzichten. Sehe ich im Prinzip genauso, auch wenn das "Paradebeispiel" Tasmota afaik zwischenzeitlich die ... Vorgabe "Tasmota" im Topic _nicht_ mehr verwendet.
Weiter _glaube_ ich, dass inzwischen so viele Leute auf ein relativ offensichtliches "selber (default-) Topic" in einem list auf Anhieb die richtige Antwort wüßten, von daher sind die Argumente im Gewicht zwischenzeitlich m.E. weiter in Richtung "für readingList ignorieren" verschoben.
Aber letztlich geht es eher darum, den User beizubringen, wie die Infos zu lesen sind, und auch diese Botschaft ist m.E. soweit angekommen, dass es nicht lohnt, an der Stelle irgendwas zu ändern :) . Na ja, genauer gesagt finde ich es nicht schlecht, wenn die ClientID in der readingsList bei autocreate-Einträgen steht, so sieht man ggf. recht gut, was attrTemplate-Konfiguration war und was ggf. nachträglich noch dazukam ;) .
"Migrationshilfe" würde ich ggf. als Anschubser in Richtung passende list-Befehle im Wiki auffassen, müßte mal drüber nachdenken; allerdings ist es nicht so einfach, weil der Doppelpunkt in vielen readingList-Zeilen (mehrfach) vorkommt und der Topic sehr flexibel aufgebaut werden kann; muss ja nicht mal ein "/" rein, an dem man sich per FILTER-Regex orientieren könnte...
Bei MQTT2_CLIENT könnte es in der Tat hilfreich sein, die User in Richtung bridgeRegexp-Anlage zu schubsen. Wie wäre es mit einem automatisch angelegten comment-Attribut, das gleich "klickbar" den Hinweis samt setter auf das attrTemplate enthält? Sollte relativ simpel umzusetzen sein, oder?
(Kann aber sein, dass sich das mit den neueren Anwendungsfällen "ich zapfe für mein spezielles Gadget einen externen Broker (auf dem Gadget) an" in die Quere kommt).
Soo bin wieder da. Da hab ich wohl ne Diskussion unter Profis ausgeloest. Und trotzdem mit meinem laienhaften Verstaendnis mitgenommen das
autocreate mit mosquitto_pub nicht funktioniert. Besteht die Moeglichkeit einen anderen client zum publishen zu nehmen. Der muesste halt die Parameter aus SBFspot verstehen und auf Raspian laufen.
Oder gibt es eine ander Idee?
Wahnsinn wie schnell hier alle reagieren und antworten!! Dafuer ein dickes Danke.
Es geht schon, siehe Rudis Hinweis auf -c und meinen Vorschlag....
Hallo Beta User,
ich hab nichts zu dem SBFspot config script hinzugefuegt.
MQTT_Topic=
sbfspot_{serial} (liest die SMA Bezeichnungen der verschiedenen Wechselrichter ein)
in: PUBLISH: 0(139)(3)(0)(18)
sbfspot_1100245644{"Timestamp": "14/12/2020 12:25:12","SunRise".....
in: PUBLISH: 0(145)(3)(0)(18)
sbfspot_2100196497{"Timestamp": "14/12/2020 12:25:12","SunRise"......
in: PUBLISH: 0(144)(3)(0)(18)
sbfspot_2100188305{"Timestamp": "14/12/2020 12:25:12","SunRise".....
fuer mich liest sich eure Diskussion eher wie geht nicht moskito_pub
Zitat....Sonderbehandlung: mosqutto generiert zufaellige ClientIDs (mosq-64xMUrGgX1nI6ZWCod, mosq-7hhJdneTV5RqSmu5iu, etc),....
Zitat von: Beta-User am 14 Dezember 2020, 13:20:16
Na ja, hier könntest du das einfach in den publish-Command einbauen, oder?
MQTT_PublisherArgs=-h {host} -t {topic} -i "sbfspot_{serial}" -m "{{message}}"
Hallo Beta-User
ich scheine schlaefriger zu sein wie meine Wechselrichter und hab Dein
-i "sbfspot_{serial}" nicht gesehen.
ZitatMQTT_PublisherArgs=-h {host} -t {topic} -i "sbfspot_{serial}" -m "{{message}}"
Fhem macht nun sein autocreate.
Meine Wechselrichter wollen teilweise nicht mehr wach werden.
Wenn die Sonne morgen wieder scheint schaue ich mir die readings mal an und berichte wie es aussieht.
Super so langsam machts SPASS.
Danke an alle fuer die schnelle und kompetente Hilfe!
Autocreate funktioniert mit allen Wechselrichtern!
Readings werden erstellt!
ZitatreadingList
_serial_:1100245644:.* { json2nameValue($EVENT) }
_serial_:2100196497:.* { json2nameValue($EVENT) }
_serial_:2100188305:.* { json2nameValue($EVENT) }
Jetzt kommt noch die Arbeit um eine eine nette Auswertung nach Anwendungsfaellen zu erstellen!
Gehört zwar nicht zu Mqtt aber gibt es dazu eine Lösung?
X-Achse im SVG-Plot skalieren z.B.: 8 Uhr bis 16 Uhr
https://forum.fhem.de/index.php/topic,59658.msg1111274.html#msg1111274 (https://forum.fhem.de/index.php/topic,59658.msg1111274.html#msg1111274)
Da Rudi hier mitliest, kann er dir sicher was dazu sagen.
Vorab mal danke für's wieder aufmachen ;) .
Ich hätte da noch ein paar Punkte gehabt; vielleicht hast du Lust, die MQTT-Themen ggf. noch zu vertiefen?
Zitat von: Beta-User am 16 Dezember 2020, 10:19:14
Interessant sind hier v.a. die Angaben MQTT_Publisher und MQTT_PublisherArgs.
Der "Trick" besteht nun darin, MQTT_PublisherArgs passend zu ergänzen. Der TE hat mit meinem dort zu findenden Vorschlag einen Teilerfolg erzielt und war damit glücklich, ich halte ihn für verbesserungsfähig; leider hat der TE den Thread geschlossen, so dass wir bis auf weiteres auf die Antwort warten müssen, ob das hier besser oder schlechter ist und noch weiter optimiert werden kann...:
MQTT_PublisherArgs=-h {host} -t {topic} -i sbfspot_{serial} -m "{{message}}"
Vermutlich sollte man sich auch den Topic ("MQTT_Topic=SMA_Converters/sbfspot_{serial}"?) und die Auswertungsanweisung "{ json2nameValue($EVENT) }" nochmal ansehen, ich vermute, dass es im Interesse "guter Reading-Namen" hilfreich wäre, hier die "vereinfachte complex"-Variante von json2nameValue() zu verwenden. Dann könnte evtl. sowas rauskommen:
attr DEVICE readingList SMA_Converters/1100245644:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE jsonMap bad_reading1:good_reading1 not_needed1:0 [tbc]
Wer speziell für Solaranlagen Anregungen sucht, wie jsonMap "gut" zu setzen ist, findet evtl. bald dazu was hier: Frevel: Die Idee einheitlicher Devicenamen und Readings (https://forum.fhem.de/index.php/topic,116747.0.html). Jedenfalls, was Reading-Namen angeht, bin ich starker Befürworter einer einheitlichen (und internationalisierten!) Namensgebung. Das macht es z.B. auch einfacher, wenn es z.B. um die Anbindung von Sprachsteuerungssystemen geht.
ZitatX-Achse im SVG-Plot skalieren z.B.: 8 Uhr bis 16 Uhr
Vmtl. noch dazu Jahreszeit-abhaengig
Gibts meines Wissens nicht.
Was gibts ist fixedRange, fixedOffset und endPlotNow.
Und Grafana :)
Nachtrag: Bitte Themen nicht schliessen, sonst haben andere Teilnehmer keine Moeglichkteit mehr, was dazu beizutragen oder verwandte Fragen zu stellen.
Ich habe jetzt auf dblog/SQLite umgestellt.
Jetzt hab ich zwei neue Fragen.
1 Frage)
Kann ich von einer anderen SQLite Db direkte "inserts" in die FHEM Db machen.
Bisher habe ich über einen Umweg
Erzeugen --> *.csv --> File anpassen auf reading Format --> FHEM Db ausschalten --> *.csv in FHEM history Db Tabelle einlesen --> Index löschen/neuerstellen --> FHEM Db einschalten
Daten in die FHEM Db bekommen. Sehr, sehr zeitaufwendig die Prozedur sie ist.
2 Frage)
Um "Historische readings", selbst erzeugte oder durch in FHEM vorhandene Abfragen, zu manipulieren (Rechnen mit den readings / Einheiten o.ä. hinzufügen) bin ich auch den obigen Weg gegangen.
Gibt es eine Funktion in FHEM um "Historische readings" zu manipuliern?
Vermutlich kann https://fhem.de/commandref_modular_DE.html#DbRep dir einen Teil der Arbeit abnehmen, Details dazu wären aber m.E. eher separat im passenden Forumsbereich zu erfragen.
Was "Rechnen" angeht, kann man für SVG-Auswertungen dann auch nachträglich mit logProxy (https://fhem.de/commandref_modular.html#logProxy) vorverarbeitende Anweisungen generieren. Aber auch das wäre m.E. woanders zu vertiefen.
Gut das mir momentan keiner in mein Zeitmanagment reinredet.
Nach überfliegen des Wikis
DbRep - Reporting und Management von DbLog-Datenbankinhalten
denke ich das Dein Tip nicht mit Gold aufzuwiegen ist.
Also kein Gold für Dich, trotzdem Danke!
Danke für die Rückmeldung.
Hast du das hier wahrgenommen?
Zitat von: Beta-User am 16 Dezember 2020, 16:33:46
Ich hätte da noch ein paar Punkte gehabt; vielleicht hast du Lust, die MQTT-Themen ggf. noch zu vertiefen?
Die readings die vom Wechselrichter kommen brauche ich alle. Die Namen der readings möchte ich nicht ändern da sie in der vorgelagerten Anwendung genau so heißen.
Standards sind OK.
ABER Standardisierung erfordert viel Arbeit. Innerhalb von Gerätefamilien eines Herstellers und Herstellerübergreifend kaum machbar. Innerhalb von FHEM vielleicht. Aber bei dem Getümmel im Bereich "SMARTHOME" wohl eher nicht.
MQTT werden ich mir noch genau anschauen wenn ich die ersten Sensoren einsetzte.
Ok, kein Ding, war als Angebot gedacht :) .
Eventuell würde ich aber trotzdem noch anregen, den "-i"-Parameter nochmal anzusehen (da kam nur der string "_serial_", oder habe ich das missverstanden?), was an dem "schnellen2 Vorschlag mit den "" liegen könnte, und einen längeren Topic zu wählen. Alles auf der untersten Ebene "abzufackeln", ist vermutlich irgendwann ziemlich unübersichtlich, wenn noch mehr MQTT-Geräte dazu kommen. Und man scheint es ja beieinflussen zu können...
Beides sollte jeweils kein "breaking change" sein ;) .