# Neues Namensschema für MQTT **URL:** \ **Category:** Software\ **Created:** [17. Dezember 2023 um 15:13 UTC](https://forum.espuino.de/t/neues-namensschema-fuer-mqtt/2553 "2023-12-17T15:13:28Z")\ **Posts on this page:** 1\ **Showing post:** 34
**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\ **Post date:** [5. Januar 2026 um 16:36 UTC](https://forum.espuino.de/t/neues-namensschema-fuer-mqtt/2553/34 "2026-01-05T16:36:58Z")
> [@Joe91](#): > > Je größer die PRs in der Vergangenheit wurden, desto „unmergbarer“ wurden sie häufig aus deiner Sicht 😉 . Daher hätte ich einzelne Schritte, mit jeweils in sich abgeschlossenen Zuständen vorgeschlagen, bevor es am Schluss heißt: „das sind jetzt zu viele Änderungen um es zu überblicken“… > Wenn es aber genügend comittment gibt das als Ganzes auch rein zu nehmen, kann man auch gleich in die Vollen gehen. Für mich macht das keinen Sinn, das Ganze halbfertig in’s Webinterface zu bringen. Wenn wir das machen, dann gleich in einem. > [@Joe91](#): > > Bin da ganz bei dir. So ist es aktuell aber nichts halbes und nichts ganzes. Die aktuelle Implementierung kommt daher, dass wir (vor Ewigkeiten) Probleme hatten, wenn es Konnektivitätsprobleme zum Broker gab. Insofern hatte man hier die Möglichkeit, dass man MQTT quasi als Hotfix deaktivieren konnte. > [@Joe91](#): > > Wenn wir es per Default anbieten wollen, dann sollte das define raus und nochmal geschaut werden, wie es nicht pauschal den Speicher frisst, auch wenn es nicht verwendet wird. Korrekt. > [@Joe91](#): > > Zur Verwendung von MQTT glaube ich, dass es tendentiell mehr werden könnten, wenn es per Default aktiv ist und z.B. die HA-Integration weiterhin direkt kompatibel ist. Weniger werden’s nicht - klar. Aber unterm Strich sind’s vermutlich gar nicht so arg viele. Das ist für mich so ein bisschen wie die Löterei, wo ich in den ersten Jahren auch immer dachte, dass es halt ein Makeprojekt ist und da jeder löten will. Das ist aber mitnichten so. Viele wollen am liebsten wenig bis gar nix löten und haben ihren ESPuino auch in einem ziemlich „unnerdigen“ Kontext laufen. Insofern: Ich persönlich finde MQTT wichtig, aber ich glaube ich spreche da nur für einen kleien Teil der ESPuino-User. > [@Joe91](#): > > Ich halte es nicht für sinnvoll jede Topic einzeln zu speichern, sondern würde das hier splitten wollen und daraus das dann dynamisch zusammensetzen. Mir persönlich ist das wurscht. Aber ich bin mal gespannt, wie lange es dauert, bis der Erste fragt, warum das nicht komplett frei definierbar ist. Aber egal, für mich ist das ok. > [@Joe91](#): > > Alternativ können wir auf das Konfigurationsschema frei definieren lassen, das wird aber irgendwann auch sehr fehleranfällíg meiner Meinung nach. Klar wird sicher sein, dass diejenigen, die MQTT bereits verwenden, „not amused“ sein werden, wenn alle bisherigen Topics falsch sind. Aber mei, so ist das halt manchmal. Mich selbst betrifft’s ja auch. > [@Joe91](#): > > Mir persönlich gefällt auch der Vorschlag von @laszloh mit dem optionalen „set“ sehr gut. > Wäre dann also `base_topic/device_id/keyword[/set]`, wobei das "/set dann optional ist. Inwiefern ist das optional? Für ein GET ohne und für ein SET dann mit? Wäre für mich ok. Dann lass uns das so nehmen mit folgenden Rahmenbedingungen: `base_topic`: Leer per Default, aber kann man über’s Webinterface anpassen. `device_id`: Per Default ESPuino-MAC…, aber kann man über’s Webinterface anpassen. `keyword`: statisch, kann nicht geändert werden. Spart Arbeit/Komplexität im Webinterface. `set` (optional): statisch, kann nicht geändert werden. Charakterisiert das jeweilige Cmnd-Topic > [@JHB](#): > > mqtt-base-topic → default leer, wird allen MQTT Topics vorangestellt Genau. > [@JHB](#): > > device\_id → Default Espuino-MAC, kommt nach dem base-topic Passt. > [@JHB](#): > > ClientId → default leer, wird als Mqtt ClientId verwendet (ich meine alle Libs würfeln da was rein wenn man nix nimmt) Da würde ich per Default das Gleiche setzen wie bei device\_id, aber man kann’s ändern. Muss man testen, was das IDF-MQTT draus macht, wenn man es leer lässt. Wenn das zu Kacke führt, dann kann man es nicht leer lassen und muss es abfangen. > [@Joe91](#): > > @biologist , was denkst du und wie kommen wir an besten zu einer Entscheidung, auch wegen der Struktur? Ja passt für mich. Das ist doch insgesamt ne vergleichsweise schlanke Lösung. Ich hätte für das Webinterface aber noch einen Vorschlag: Wir haben dann ja nur ein paar wenige Felder, aus denen alles konkatteniert wird. Das ist ggf. nicht so eingängig für die User, wie die einzelnen Topics dann in Gänze aussehen. Vielleicht kann man ne Info-Box anzeigen, in der die ganzen Topics dann aufgelistet werden - basierend auf dem, was in den jeweiligen Textbausteinen definiert ist. Ich schätze mit Js lässt sich das relativ einfach bewerkstelligen: Man macht ein concat und iteriert halt über die Keywords (wobei es mitunter Topics nur als States und nicht als Cmnd gibt). --- _[View the full topic](https://forum.espuino.de/t/neues-namensschema-fuer-mqtt/2553)._