Den openWB-mosquitto fremd nutzen?

[Gero]

Hallo zusammen,

bislang hat der mosquitto der openWB auch meine Shellies publishen lassen. Das habe ich natürlich unter einem eigenen Ast namens "shellies" neben der openWB und dem $SYS gemacht. Mittlerweile funktioniert das nicht mehr - ich vermute mal die Absicherung gegen den Konfigurationsüberschreibereien dahinter.

Ist das nun beabsichtigt oder spricht irgendwas dagegen, dass man nicht doch in eigenen Teilbaum seine nicht-openWB-Topics publisht? Man könnte ja auch einen eigenen Teilbaum dafür vorsehen, der von allen einfach so beschreibbar ist? "public" oder so vielleicht?

[shesse]

Ich würde mir wünschen, dass einfach nur der openwb-Teilbereich nicht beschreibbar ist und der Rest einfach offen bleibt.
Es geht doch im Endeffekt darum, dass die Konfig der openWB nicht mehr fälschlicherweise überschrieben werden kann. Der Rest kann doch egal sein...

[zut]

Ich wäre auch sehr dafür, zumindest per Einstellung den Broker nutzen zu können, sonst funktioniert mein soc_helper nur mit einigem Aufwand (er nutzt das manuelle SOC-Modul und tauscht sich mit dem WiCAN über den Broker der Wallbox aus)

viewtopic.php?p=91886#p91886

[Pendragon]

Kann man also in der Master nun nicht mehr

Code: Alles auswählen

openWB/set/vehicle/1/soc_module/calculated_soc_state/manual_soc

schreiben?
Ich dachte es wäre nur alles außerhalb von openBW/set/# betroffen?

[zut]

Wie ich es verstehe: Die Set -Topics sind beschreibbar, alles ist lesbar: https://github.com/openWB/core/blob/mas ... quitto.acl

Mein soc_helper könnte den manuellen SOC weiter setzen, aber für die Kommunikation mit dem Auto (unter /wican/Seriennummer) müsste jeder Anwender einen neuen Broker auf seinem Rechner aufsetzen, wenn nicht die Topics außerhalb von openwb/# geschrieben werden können. Und soc_helper muss beide broker bedienen, was die Sache komplizierter macht.

[pvaxel]

Hallo,
ich nutze den openWB MQTT Broker auch 'fremd' für shellies und heishamon. Ich würde mir ebenfalls wünschen, dass das weiterhin möglich ist!

[zut]

Ich habe gestern ein paar versucht mit mosquitto gemacht und es nicht hinbekommen, alles außer einen bestimmten Zweig readwrite zu definieren.
Vielleicht geht noch was. Ansonsten müsste man explizit Pfade definieren, wo Fremdnutzung möglich ist. Das ist nur blöd bei Geräten, wo man den Pfad nicht vorgeben kann, wie den wican. Aber auch da kann ich mal fragen, ob man das konfigurierbar machen kann

[zut]

Ich habe ein entsprechendes issue angelegt:
https://github.com/openWB/core/issues/1586

[Gero]

Vielen Dank dafür - das mit dem others-Zweig habe ich verstanden, wäre für mich auch vollkommen ok. Nur die Ergänzung mit dem user habe ich noch nicht ganz begriffen. Wo werden denn diese User angelegt? Im mosquitto oder im linux untendrunter?

[zut]

Wo werden denn diese User angelegt? Im mosquitto oder im linux untendrunter?

Im Moment ist am mqtt-Broker der Wallbox das anonyme Anmelden erlaubt. Man kann aber trotzdem einen user und ggf. ein Passwort angeben für die Anmeldung. Den Benutzer kann man in der acl-Datei nutzen, um Freigaben zu steuern - dazu dient das pattern-Schlüsselwort: Wenn in der acl-Datei zu Beispiel

Code: Alles auswählen

pattern readwrite nutzerbereich/%u%/#

steht, darf ein mqtt-client, der sich mit dem Nutzernamen "heinrich" angemeldet hat, im Bereich
nutzerbereich/heinrich/# lesen und schreiben.

Wenn der wican sich also mit Nutzer "wican" anmeldet und ein

Code: Alles auswählen

pattern readwrite %u/#

vorhanden ist, dürfte er den Zweig wican/# zum Lesen und Schreiben nutzen. Zumindest bis Firmware 2.90 kann der wican nur unter wican/<Seriennummer>/ schreiben und lesen, das würde dann funktionieren. (In 2.98 ist angeblich der mqtt-Pfad konfigurierbar, ich muss noch prüfen, was damit gemeint ist)

Für shellies könnte man mit genau dem pattern

Code: Alles auswählen

pattern readwrite %u/#

mit dem user "shellies" den Bereich shellies/# lesen und schreiben.

Das wäre eine recht flexible Lösung, finde ich. Haken ist, daß mit dem Nutzer "openwb" wieder der Bereich beschreibbar wäre, der nicht mehr überschrieben werden soll. Diesen Nutzer müsste man also aussperren.

All das Geschriebene bezieht sich nicht auf die Linux-Nutzerverwaltung, sondern nur auf die Nutzung von mqtt.