openWB Forum

Meine openWB 2 Standard+ hat am Samstag äußerst mysteriöses Verhalten an den Tag gelegt und mich würde ineteressieren, ob jemand Licht ins Dunkel bringen kann.

Ich hatte seinerzeit mit dem ersten 2.1.2-Release ein zweites Fahrzeug angelegt. Ich habe zwar nur ein Auto, aber ich fand und finde es übrigens immer noch unschön und vor allem völlig unverständlich, dass man das erste Fahrzeug nicht benennen kann. Da gab es seinerzeit Probleme mit dem Aktualisieren des Fahrzeug SoCs, deshalb bin ich doch wieder auf das Standard-Fahrzeug umgestiegen. Dieser Fehler wurde dann mit dem letzten Patch behoben. Allerdings gab es seitdem ein neues Problem: ich konnte das zweite noch vorhandene Fahrzeug nicht mehr löschen und letzten Samstag konnte ich dann in der Hauptansicht keins mehr auswählen. Es waren zwar beide Fahrzeuge in der Combo-Box auswählbar, aber nach dem Auswählen verschwand es sofort wieder.

Dann hatte ich genug und wollte die Daten zurücksetzen (System -> Datenverwaltung -> Zurücksetzen). Ergebnis: alles unter "Einstellungen" war gelöscht, alles unter "Konfiguration" (u. a. also die Fahrzeuge inkl. dem nicht-löschbaren) waren aber noch vorhanden. Ich hätte erwartet, dass auch die Konfiguration zurückgesetzt wurde.

Dann habe auf die SD-Karte das Image neu aufgespielt. Und jetzt wird es mysteriös: Die Konfiguration war immer noch vollständig vorhanden. Gleiches Ergebnis mit einem erneuten Versuch mit einer anderen, vorher leeren SD-Karte. Auf der Hauptseite war übrigens ein 6 Tage alter Graph zu sehen, der sich auch nicht mehr aktualisieren wollte.

Aus lauter Verzeifelung habe ich dann die 1.9er Software geflasht. Dann waren tatsächlich keine alten Daten mehr vorhanden, ist ja auch ein völlig anderes Datenmodell und alles funktionierte einwandfrei.

Nachdem ich danach noch einmal die 2.1.2 aufgespielt habe, war dann auch die Konfiguration zurückgesetzt und ich konnte endlich alles neu einstellen und das Zweitauto war verschwunden.

Ich frage mich aber, wie es sein kann, dass die Konfiguration ein komplettes Neu-Aufspielen des Systems überleben kann. Ich hatte zwischenzeitlich den Browser-Cache in Verdacht, aber Daten löschen, anderer Browser, etc. haben auch nicht geholfen. Ich hätte gedacht, dass alle Einstellungen inkl. Konfiguration auf der SD-Karte gespeichert werden. Oder gibt es dafür noch irgendwo einen Speicher außerhalb der SD-Karte?

Kann sich bzw. mir das jemand irgendwie erklären?

Kann sich bzw. mir das jemand irgendwie erklären?

Gibt es ein Smart Home System wie ioBroker oder so das per MQTT angebunden ist?

Guter Punkt, das gibt es und das hatte ich auch zwischenzeitlich in Verdacht.

Es läuft ein Mosquitto-Docker-Container, der als MQTT-Bridge fungiert und dazu ein HomeAssistant-Plugin. Da ich das auch zwischenzeitlich in Verdacht hatte, hatte ich den Container einfach gestoppt, die Konfigurationen kamen aber nach dem Flashen der SD-Karte wieder.

Könnte eine MQTT-Verbindung denn ein derartiges Verhalten erklären? Es gibt in HomeAssistant übrigens keine einzige Automation, die irgendetwas mit den Daten macht, geschweige denn, die Konfiguration zurück schreibt. Mich hatte einfach nur interessiert, ob bzw. wie man die openWB anbinden kann, aber mehr, als mir die Daten anzuschauen, habe ich noch nicht damit gemacht.

Ich hatte zwischenzwitlich eher das Backup-Script, welches auf dem NAS läuft in Verdacht, welches einmal am Tag die Konfiguration sichert. Aber da es die Konfiguration nur liest und nicht schreibt und es nur 1x morgens läuft, halte ich auch das für fast ausgeschlossen.

Könnte eine MQTT-Verbindung denn ein derartiges Verhalten erklären?

Ja, das ist dann die Ursache und spielt die Config - je nach Bridge Konfiguration - wieder zurück auf die frische openWB.

Die These halte ich ehrlich gesagt für sehr gewagt:

• Wie schon erwähnt, hatte ich (ab dem zweiten Versuch) den gesamten Mosquitto-Container abgeschaltet, um das als Fehlerquelle auszuschließen.
• Ich wüsste gar nicht, wie ich die Bridge konfigurieren könnte, um ein derartiges Verhalten (Config wird sofort zurückgespielt, Einstellungen allerdings nicht) zu erzeugen. Dafür habe ich mich noch viel zu wenig mit dem Thema bzw. den Möglichkeiten beschäftigt. Und ein derartiges Feature konfiguriert man ja nicht "aus Versehen".

Es handelt sich um einen Standard mosquitto Container (eclipse-mosquitto) und das ist meine gesamte config (plus credentials), die ich selbst vorgenommen habe:
Gut, ist vlt. auch müßig, das Problem besteht ja nicht mehr. Aber wenn das zu einer sofortigen Konfigurations-Rückspielung führt, fände ich das hochinteressant.

topic openWB/# both 2

ich bleib bei meiner These. Das sorgt dafür das bestehende Retained topics wieder zurück gepublished werden.
Falsch konfigurierte Bridges führen dazu. Das ist hier auch wöchentlich Thema.
Die Empfehlung ist ausschließlich die gewünschten Topics zu abonnieren und nicht mit einer Bridge zu arbeiten wenn man nicht genau weiß was man tut.

OK, das ist wirklich ein krasses und leicht zu konfigurierendes Feature

Da alles andere im Grunde auch auszuschließen ist, muss es das wohl sein. Vielen Dank für den Hinweis.

Ich hoffe, ich werde mal dazu kommen, mich näher mit dem Thema zu beschäftigen. Falls ich nochmal derartige Probleme habe, weiß ich ja, wo ich ansetzen kann.

openWB hat geschrieben: ↑Di Feb 27, 2024 7:17 am

topic openWB/# both 2

ich bleib bei meiner These. Das sorgt dafür das bestehende Retained topics wieder zurück gepublished werden.
Falsch konfigurierte Bridges führen dazu. Das ist hier auch wöchentlich Thema.
Die Empfehlung ist ausschließlich die gewünschten Topics zu abonnieren und nicht mit einer Bridge zu arbeiten wenn man nicht genau weiß was man tut.

Muss ich nur zustimmen. Hatte auch das HA Plugin und die Bridge hat mir immer wieder die Konfiguration durcheinander gebracht.

caran17 hat geschrieben: ↑Mo Feb 26, 2024 6:33 pm ...
Ich hatte seinerzeit mit dem ersten 2.1.2-Release ein zweites Fahrzeug angelegt. Ich habe zwar nur ein Auto, aber ich fand und finde es übrigens immer noch unschön und vor allem völlig unverständlich, dass man das erste Fahrzeug nicht benennen kann.
...

Das finde ich auch. Gibt es eigentlich Pläne, den Namen des Standard Fahrzeugs mal änderbar zu machen?

Hallo zusammen!

Nachdem ich mir selbst anscheinend so ein Bein gestellt habe, habe ich gestern versucht, das Ganze nachzuvollziehen. Das scheint ja ein breiteres Problem zu sein und ich muss an der einen oder anderen Stelle auch etwas Kritik äußern. Aber bitte nicht falsch verstehen: es geht dann nicht darum, zu meckern, sondern dazu beizutragen, dass das Produkt in Zukunft noch besser gemacht werden kann. Und Widerspruch ist absolut erlaubt und ggf. auch gewünscht.

Was möchte ich als Anwender?
Als Anwender möchte ich meine Wallbox, die offensichtlich großen Wert auf Offenheit legt, in mein SmartHome einbinden. Als "Zentrale" nutze ich HomeAssistant, weil sich das als herstellerunabhängiger Quasi-Standard durchgesetzt hat.

Was möchte ich als Anwender nicht?
Als Anwender möchte ich mich nicht mit technischen Entitäten wie Topics, Broker, Bridges, etc. beschäftigen, ich möchte auch nicht "auf Topics lauschen" und ich möchte sicher nicht den Unterschied zwischen einer Zeile wie oder verstehen müssen.

Was wäre mein Wunsch
Mein Wunsch wäre ein HA-Plugin. Darin trage ich einmal die IP/Hostnamen der openWB ein, evtl. Credentials und ab dem Zeitpunkt werden die Werte der openWB in HA angezeigt und ich kann auf bestimmte Funktionen der openWB aus HA zugreifen.

Wie kann man das als Hersteller erreichen?

• Möglichkeit 1: man stellt selbst ein entsprechendes Plugin bereit. Vorteil: man hat selbst in der Hand, was der Anwender darf und was nicht. Außerdem muss sich kein Anwender damit beschäftigen, wie die Kommunikation mit der openWB implementiert ist. Nachteil: jemand muss das erstellen, maintainen und supporten und man muss ggf. auf Änderungen der Host-Software (HA) reagieren.
• Möglichkeit 2: man baut eine einfache und vor allem gut dokumentierte Schnittstelle, die es versierten Entwicklern ermöglicht, so ein Plugin zu bauen. Ein prominentes Beispiel wäre Philips Hue. Sicher nicht die Speerspitze an Offenheit, aber es gibt eine klar dokumentierte Rest-API, gegen die jeder problemlos entwickeln kann. Resultat: es existiert ein HA-Plugin, welches so funktioniert, wie man sich das als Anwender wünscht.

Wie wurde es bei der openWB umgesetzt?
Hier wurde auf ein offenes Protokoll (MQTT) gesetzt, um das zu ermöglichen. Das ist an sich gut. Ich hätte mich allerdings eher für eine Rest-API entschieden, weil sie bekannter ist und von jeder Programmiersprache unterstützt wird. Wahrscheinlich kann MQTT etwas mehr (Echtzeit-Daten, Push, etc.) aber genau das scheinen mir auch die Features zu sein, die Komplexität reinbringen und damit eben zu solchen Problemen führen. Aber da kann man sicher auch eine andere Meinung vertreten.

Wie sieht das für den Anwender in der Praxis aus?
Ich suche in HA nach einem Plugin und finde "openWB2 over MQTT". Mich stört schon das "over MQTT". Es ist mir egal, wie die Geräte kommunizieren. Ich installiere das Plugin:

https://ibb.co/xs7WBhv
und werde mit technischen Details wie "MQTT-Wurzeltopic" und internen IDs "genervt". Immerhin: meine openWB scheint gefunden zu werden:

https://ibb.co/gwPy0Qx
Alleine es scheint nicht zu funktionieren:

https://ibb.co/2vPgyVs
Obwohl die openWB anscheinend ohne weiteres Zutun munter Messages versendet:

https://ibb.co/tPgTjNh

Vermutlich stimmt etwas mit dieser MQTT-Anbindung nicht. Also suche ich im Internet nach Anleitungen. Zunächst beim Hersteller. Dort ist allerdings nichts zu finden. Ich erwarte nicht, dass man MQTT erklärt, wohl aber eine eine Dokumentation über die MQTT-Topics. Wenn man als Anwender genau wissen sollte, was man tut, muss man auch die Möglichkeit haben, an diese Informationen zu gelangen. So aber weicht man notgedrungen auf andere Anleitungen aus, wie z. B. diese hier: https://tech-engineering.de/home-assistant-und-openwb/. Dort allerdings steht dann, dass man so eine Bridge benötigt. Die offizielle Anleitung des HA-Plugins, aus der übrigens die verhängnisvolle Zeile stammte, erscheint mir dort etwas widersprüchlich: dort steht zwar, dass man keine Bridge benötigt, um dann im nächsten Absatzt aber die Konfiguratione eben genaau für diese Bridge nachzuschieben.

Und da es so ja nicht funktioniert, beschäftigt man sich mit dem Thema, was man eigentlich gar nicht möchte und "probiert" mal so eine Bridge, in meinem Fall ein mosquitto-Docker-Container und haut dort die vorgeschlagene Config rein. Und siehe da, auf einmal funktioniert es:

https://ibb.co/GkpPsmj

Nur dass man "aus Versehen" eine Zeile eingebaut hat, die dazu führt, dass man im Enstfall die Konfiguration der Wallbox nicht mehr los wird und an der eigenen Zurechnungsfähigkeit zweifelt. Das Ergebnis sind frustrierte Anwender (warum geht das nicht einfach?), ein genervrter Support (schon wieder ein Anwender, der in die gleiche Falle getappt ist) und hohe Kosten für den Hersteller (warum ist der Support so teuer?).

Schlussfolgerung
Jetzt werdet ihr aus dem openWB-Team wahrscheinlich sagen, das mag ja sein, aber das ist ja nicht unsere Schuld, wenn irgend jemand komische Plugins entwickelt oder irreführende Anleitungen schreibt. Aber meine gewagte These ist: daran habt ihr eine gewisse Mitschuld. Ich darf heutzutage von einer 1700 Euro-Box, die explizit die Offenheit bewirbt, erwarten, dass ich sie in mein SmartHome einbinden kann. Darauf zu verzichten, weil ich nicht 100% sicher in Sachen MQTT bin, ist keine Option. Ihr müsst kein Plugin für HA oder sonst welche Software bereitstellen, aber dokumentiert eure Schnitstellen, zeigt, was man tun muss, um eure Box mit der "Außen-Smart-Home-Welt" zu verbinden. Ihr macht so vieles möglich, jetzt macht es auch einfach.

Sorry, dass es so lang geworden ist. Mein großer Wunsch wäre, dass es die Entwicklung weiter pusht! Davon hätten wir am Ende alle etwas.

PS: da das mit den Bildern nicht klappen zu scheint, habe ich sie nochmal als URLs darunter gepackt.