Für mich macht das keinen Sinn, das Ganze halbfertig in’s Webinterface zu bringen. Wenn wir das machen, dann gleich in einem.
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.
Korrekt.
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.
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.
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.
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
Genau.
Passt.
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.
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).