Danke!
Eigentlich ist genau das schon der Fall, da der Hostname aus der settings.h nur dann angezogen wird, wenn noch keine client-id gesetz wurde.
Zumindest bei mir löst das genau das Problem.
Oder verstehe ich da noch was falsch?
Ah, jetzt hab ich glaub verstanden was du meinst: es geht dir nur um den Initialen Hostname, bis eine client-id gesetzt wurde. Oder? Den Vorschlag finde ich sehr gut!
Bei dir kann aber folgendes passieren, ich baue 2 ESPs auf und aktiviere MQTT setze aber keine ClientId (warum sollte ich, brauche ich ja sonst auch nicht) → Fehler im Broker, ClientId doppelt
Ich würde ClientId nicht fürs Topic nutzen.
Das sind für mich 2 getrennte Paar Schuhe.
Wenn man schon dabei ist könnte man das komplett konfigurier bar machen.
ClientId → wenn keine gesetzt → nimm Espuino_(%MAC)
Topic → wenn keins gesetzt → nimm Hostname
TopicPrefix → packe vors Topic wenn gesetzt
Siehe dazu auch: MQTT - Tasmota
Client = device's unique identifier. In 99% of cases it's okay to leave it as is, however some Cloud-based MQTT brokers require a ClientID connected to your account. Can not be identical to Topic!
bzw. die Version die da gemacht wird mit dem FullTopic finde ich auch nett
Moin zusammen, hab dank der großartigen Arbeit von @biologist über Weihnachten tatsächlich zwei Boxen für meine Kids gemacht und wollte Sie jetzt mittels GitHub - DexXxter007/ESPuino_HA_Integration in mein HA integrieren. Das klappt auch gut für ein Gerät, aber bei zweien habe ich das Problem mit der Undifferenizierbarkeit der beiden Gadgets auf dem MQTT. Während es so aussah als gäbe es dank des Codes von @Joe91 hier einen Lösungsvorschlag scheint mir das Ganze hier doch wieder etwas versandet oder bestünde hier noch Interesse die Änderungen von @Joe91 hier mal auf den aktuellen DEV Stand zu heben? EIn bisschen Zeit hätte ich in den kommenden Tagen für Reviews und Tests, wenn das generell noch von Interesse ist.
Hi,
ja, der PR von mir würde genau das Lösen, ohne an dem bisherigen Konzept was zu ändern. Heißt es würde einfac nur die Device-Id (und somit Gerätespezifisch) am Anfang stehen, der Rest aber gleich bleiben.
Torsten wollte hier aber glaub einen viel allgemeineren Ansatz verfolgen.
Ich fände es durchaus stimmig auch erstmal damit zu starten (da es in Summe vor allem Veralgemeinerungen in diesem PR sind die dann auch später weiter verwendet werden können), verstehe aber auch den Ansatz das gleich „richtig“ machen zu wollen.
Ich persönlich verwende diese Änderungen (zusammen mit der HA-Integration) auf allen meinen Boxen und fahre damit sehr gut bis jetzt 
…
Der PR ist immernoch mergebar, kannst du also auch einfach selbst bei dir mit anwenden.
Ja, ich hatte eigentlich @Joe91 zugesagt, dass ich mich der Sache annehme. Aber ich habe durch die fortlaufenden Hardware-Bestellungen, über die ich mich ja freue, einfach wirklich NIE Pause von ESPuino und so fehlt mir oft die Lust, noch mehr Zeit in ESPuino zu stecken.
Es ist halt so, dass wir inzwischen die fertigen Binaries haben und sich viele Leute gar kein VSC mehr installieren. Insofern wäre meine Präferenz, wenn man eh schon Hand anlegt, die ganzen Topics direkt in’s Webinterface zu integrieren, so dass man auch für MQTT kein VSC mehr benötigt.
Man kann’s auch weiterhin über Compile-Direktiven machen. Es löst halt das Gesamtproblem nur teilweise.
Also versteht mich nicht falsch: Ich weiß das schon zu schätzen. Aber vollen Mehrwert bringt das aus meiner Sicht nur im Webinterface. Ich will hier allerdings auch nicht den Türsteher spielen
Aber dann lass doch zusammen einen Ziel-Zustand definieren.
Ich schau dann wie viel Aufwand es wäre und wie weit es von meinen Vorstellungen abweicht 
…
Auch wenn die Topics im Webinterface sind, will man ja vermutlich nicht jede Topic einzeln anpassen müssen, sondern (zumindest von mir ausgehend) halt z.B. die Topic-Struktur und dann eigentlich nichts weiter, so dass per default schon brauchbare Ergebnisse rauskommen.
Dafür könnte man als Basis den PR-Stand nehmen und dann halt ins Webinterface ziehen.
Im ersten Schritt könnte man auch einfach genau diesen Stand so wie er ist ins Webinterface bringen und dann im zweiten Schritt schauen, was man noch weiter anpassen will.
Da man vom VS-Code wegkommen will, müsste man auch das Compiler-Flag (MQTT_ENABLE) entfernen über mit einem Config-Flag ersetzten, dass z.B. nur zum Bootup ausgewertet wird.
Wäre das ein brauchbarer Weg? Also:
Müssen nicht, aber, würde ich sagen, bei Bedarf können. Ich bin jetzt kein GUI-Experte, aber vielleicht macht es Sinn, sowas wie ESPuino-<MAC-Adresse> als dynamische Basis zu haben und eben alle Topic-Felder dann damit passend mit einer Konkattenierung zu belegen. Oder auch ESPuino-<MAC-Adresse> in einem Feld mit einem Generate-Button und dann werden mit Klick auf den Button alle Topic-Felder gefüllt. Eben mit diesem dynamischen Teil und zusätzlich eben statischer Teil, den man hardcodet in Javascript hat. Gespeichert wird’s auf jeden Fall en bloc (alle Topics zusammen) im NVS.
Irgendwie z.B. so „ESPuino-36b1db1800ff/cmnd/Sleep“.
Genau, die man aber, sofern man dafür eine Notwendigkeit sieht, anpassen könnte.
Tatsächlich gibt’s sowas mehr oder weniger schon. Also man kann, wenn man MQTT reinkompiliert hat, es auch deaktivieren über das Webinterface. Aber ich denke man könnte das speichersparender integrieren. Weil es ist auf jeden Fall so, dass (in meiner Wahrnehmung) nur einzelne Leute MQTT verwenden. Insofern sollte es möglichst wenig Impact für alle verursachen, die es nicht benutzen. Aber, das wäre der Weg - ja.
Meinst du das jetzt als mehrstufigen Weg oder setzt man das dann in einem Zuge um? Also mehrere PRs sind schon ok, aber die sollten dann en bloc angewendet werden - sonst produziert man wieder Zwischenstände, die nur kurze Zeit Gültigkeit haben.
Hallo zusammen. Danke für das rasche Feedback. Also ich finde das Vorgehen wie von Dir @biologist favorisiert auch sinnvoll. Ich persönlich denke dass MQTT in den kommenden Jahren weiter in den Fokus Rücken und die Anzahl derer, die es nutzen damit auch steigen wird. Ich hatte jetzt persönlich keinen großen Stress (sondern eher Spass) damit mir Plattformio (sogar über das quelleoffene Codium) aufzusetzen und die Firmware zu kompilieren, aber für den Otto-Normal User ist das vermutlich zu knifflig. Daher fände ich es auch sinnvoll das ganze per Default mit in der Firmware zu haben. Das man die Topics per WebUI customizen kann, es aber wie von dir und @Joe91 vorgeschlagen auch einen sinnvollen Default gibt, der das einzelne Gerät hinreichend differenziert ist ebenso wünschenswert. Ob man jetzt im gleichen Zusammenhang auch gleich das Brett mit dem Austausch der MQTT Library bohrt, weiß ich nicht, dafür fehlt mir die Entwicklungserfahrung mit beiden Libs als “Wirtschaftsinformatiker” würde ich mich aber eher für die wartbare (d.h. u.a. aktuell weiterentwickelte und dynamischere) Implementierung entscheiden. Was das generelle Vorgehen in der Entwicklung angeht, wäre es vermutlich am sinnvollsten du @biologist und @Joe91 setzt das mit einem zusammenhängenden Bunch von Commits / PRs (ggf. in einem eigenen Dev Branch) um und ich teste es gerne mit meinen beiden ESPuinos (natürlich kann ich auch selber Hand an den Code lege, aber das dauert vermutlich erheblich länger als wenn ihr das macht UND wird vor allem auf keinen Fall gleich gut ;-)). Der erste Schritt wäre aber wohl das was schon vorhanden ist an einem geeigneten Ort (z.B. eigener Branch) zu konsolidieren.
Das ist schon abgeschlossen, das läuft dank @Joe91 schon nativ auf IDF.
ah ok, dass ist ja gut. Das war mir nicht bewusst!
Ich rede nur aus Erfahrung 
…
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.
Bin da ganz bei dir. So ist es aktuell aber nichts halbes und nichts ganzes. 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. Je weniger defines es am Schluss sind, desto weniger edge-cases können vorkommen.
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.
Und genau hier glaube ich, sollten wir bevor wir irgendwas tun zuerst den Zielzustand genau (oder zumindest genau genug) definieren .
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. Anzeigen könnte man das dann trotzdem noch dynamisch über js.
Vorschlag:
Wir haben ein fixes Konfigurationsschema:
base_topic/device_id/type/keyword
dann kann man die verschiedenen Werte Konfigurieren:
base_topic entweder leer, oder z.B. „home/kinderzimmer/bett1“
device_id entweder ein fixer string oder ein regex o.ä. für z.B. Teile der Mac-Adresse wie z.B.: Espuino-<MAC[:6]>
type-Command könnte dann entwerder „Cmmd“ oder z.B. „Set“ o.ä. sein.
type-State könnte dann „State“ oder „Get“ o.ä. sein.
Die tatsächlichen Keywords weiß ich ehrlich gesagt gar nicht, ob ich die konfigurierbar machen würde. Wäre aber natürlich auch möglich, dass man jeden einzelnen Command und State dann noch frei definiert.
In diesem Fall wäre es für jeden einzelnen Wert nochmal ein Konfigurationsfeld.
Alternativ können wir auf das Konfigurationsschema frei definieren lassen, das wird aber irgendwann auch sehr fehleranfällíg meiner Meinung nach.
Edit:
habe gerade mal noch nach oben gescrollt und da schon ganz schön viele Vorschläge gesehen, aber nie eine Entscheidung . Darf gerne auch einer von den Vorschlägen von oben sein, sofern wir uns möglichst bald drauf einigen und das als Gesamtkonzept inklusive Konfiguration festhalten …
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.
Das wäre dann 3 (oder mehr?) neue Werte für die Webseite/das NVS?
Mehr würde ich nicht einstellbar machen…
Ja, meiner Meinung nach würde das reichen, da der Rest als feste Werte zumutbar wäre.
Würde dann auch den Aufwand überschaubarer machen.
@biologist , was denkst du und wie kommen wir an besten zu einer Entscheidung, auch wegen der Struktur?
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).
Top! Dann lass uns so starten!
Ist auf die Art auch wirklich deutlich einfacher in der Umsetzung und wird dann hoffentlich auch nicht so krass in den Änderungen…
Soll ich mich drum kümmern? Ich müsstet in den nächsten Wochen etwas Zeit dafür finden. Wir können dann ja auch gleich einen PR für die HA-Erweiterung machen, dann haben zumindest alle HA-user einen einfachen umstieg
Vielleicht hat ja aber auch @DexXxter007 Lust das wenn es so weit ist selbst anzupassen…
Du kannst es sehr sehr gern machen🙈 Ich habe momentan viel um die Ohren und würde in der nächsten Zeit nicht dazu kommen.
Wenn etwas gebraucht wird meldet euch aber gerne. 
Hört sich jedenfalls alles sehr gut an!
@Joe91 Das Angebot deiner Umsetzung nehme ich gerne an und sage kurzfristigen Support hinsichtlich Testing zu.
HA könnte ich auch bisschen mittesten, aber da bin ich eher Noob.
Ging jetzt doch ziemlich schnell:
Fürs Testen mit HA, kann der Stand aus dem PR hier verwendet werden:
Im Webserver sieht es jetzt so aus:
Gerne einfach mal ausprobieren…
Habe das gestern mal getestet und es ist wirklich schick geworden. Danke @Joe91 für die schnelle Umsetzung.
Will jetzt nochmal heute Abend auf nem nackten ESPuino testen, bei dem das NVS gelöscht ist.
Hallo @biologist @Joe91 irgendwie habe ich offenbar die Mentions auf dem Forum für mich deaktiviert und gar nicht gesehen was hier abging in den letzten 3 Tagen. Vielen Dank @Joe91 @biologist ich werde es direkt heute Nachmittag mal mit meinen beiden ESPuinos und HA testen und dann Feedback geben.
