openWB Forum

.n3 hat geschrieben: ↑So Jul 14, 2024 2:04 pm Unter Version 1.9 hat auch alles sauber funktioniert.

Naja, ich würde sagen, es hat nur keiner gemerkt. Unter der 1.9 gab es auch massive Probleme mit MQTT und dem smarthome, als die Konfiguration der smarthome-Geräte nach MQTT gewandert ist. Da haben sich auch reihenweise die Leute mit falsch konfiguriertem MQTT-Clients (ich nenne sie absichtlich nicht subscriber) die smarthome Konfiguration zerschossen. In der 2er Software ist nun auch die Konfiguration der openWB-Komponenten in MQTT-Topics gewandert. Mittlerweile sind sie schreibgeschützt.

Eine Bridge braucht man eigentlich nur dann, wenn man die Topics der openWB auf einem anderen mosquitto replizieren möchte. Also in einem, der im Internet steht, z.B. Oder wenn man einen subscriber hat, bei dem man nur einen Broker für alle topics angeben kann, die Topics sich aber über mehrere Broker verteilen. Das sind eher die exotischen Fälle. Bei nodeRed gibt man in jeder MQTT-in Node den Broker an. Da existiert das Problem nicht. Ich weiß nicht, wie das in ioB oder HA ist. Auf jeden Fall fühlen diejenigen, die hier von Problemen mit MQTT berichten, immer eine Notwendigkeit, eine Bridge konfigurieren zu müssen. Ich weiß nicht, woher das kommt. Vielleicht weil man‘s kann?

aiole hat geschrieben: ↑So Jul 14, 2024 2:30 pm Das RFID-Thema für sw2 wird gerade überarbeitet.
https://github.com/openWB/core/wiki/Lad ... ischaltung

Ja, das habe ich gemerkt. Ich meine früher gab es in den Einstellungen ein Feld wo man die RFIDs eintragen konnte. Es stand aber dabei, dass wenn das Feld hier leer bleibt, die Zuordnung über die Autos erfolgt. Nun muss man am Ladepunkt und am Fahrzeug Profil die RFID Tags angeben und jetzt geht es auch. Ich hab den RFID Tag im Lade- und Fahrzeugprofil. Jetzt will ich mal testen, ob es auch mit MAC Adresse funktioniert. Diese habe ich aktuell nur im Fahrzeugprofil.

aiole hat geschrieben: ↑So Jul 14, 2024 2:30 pm Grundlegend - man kann sw1.9 hinterhertrauern, ok. Die Zukunft kann man damit leider nicht bestreiten.
sw2 kann so viele Dinge, die beim Trauern unberücksichtigt bleiben, dass der Platz hier nicht ausreicht. Ich kann nur empfehlen, den Fokus auf sw2-Optimierung zu legen, weil sw1.9 irgendwann sicher auch das Zeitliche segnet.

Hinterhertrauern meinte ich jetzt nicht. Bei mir hat es lange einfach funktioniert und seit einigen Wochen bin ich täglich damit beschäftigt. Zähler defekt, SD-Karte defekt, Logs wurden nicht geschrieben, dann Wechsel auf v2, hier neue Logstruktur, RFIDs wurden nicht erfasst, MQTT etc. und zeitgleich brauche ich die Logs für meinen Arbeitgeber. Hat jetzt alles funktioniert, aber v2 war jetzt auch nicht komplett selbsterklärend.
Ich finde v2 auch sehr gut und finde auch den Schritt es komplett neu zu Entwickeln lobenswert. Früher konnte ich meine Pro an der series Freigeben und nun musste ich ein neues RFID Model nachbestellen. Ärgerlich ja, am Anfang. Aber jetzt macht es mehr Sinn. Aber bis man das rausfindet muss man hier im Forum etc. lesen. Ich würde mich wünschen, dass man mehr Hilfestellung in der Software findet auch mit Beispiel. Auch mal externe Benutzer für Test einbeziehen, den in der Entwicklung macht vieles Sinn, was ein normaler Benutzer aber anders sieht. Stichwort User Acceptance Test. Sollte auch den Support entlasten.
Du schreibst es aber schon, dass der Fokus auf der Optimierung von v2 liegen sollte.

Gero hat geschrieben: ↑So Jul 14, 2024 3:03 pm

.n3 hat geschrieben: ↑So Jul 14, 2024 2:04 pm Unter Version 1.9 hat auch alles sauber funktioniert.

Naja, ich würde sagen, es hat nur keiner gemerkt. Unter der 1.9 gab es auch massive Probleme mit MQTT und dem smarthome, als die Konfiguration der smarthome-Geräte nach MQTT gewandert ist. Da haben sich auch reihenweise die Leute mit falsch konfiguriertem MQTT-Clients (ich nenne sie absichtlich nicht subscriber) die smarthome Konfiguration zerschossen. In der 2er Software ist nun auch die Konfiguration der openWB-Komponenten in MQTT-Topics gewandert. Mittlerweile sind sie schreibgeschützt.

Das kann natürlich sein. Aus Interesse. Eine Idee wie es dann dazu kommen konnte, dass als ich über MQTT den Lademodus von PV auch Sofort gewechselt habe, die Ladepunkte in der OpenWB nicht mehr angezeigt wurden und anschließend Benachrichtigungen kamen, dass Gerät x falsch konfiguriert wäre und entfernt wird. In der config war es aber vorhanden. Hab von dem Zustand noch ein Backup.

Gero hat geschrieben: ↑So Jul 14, 2024 3:03 pm

.n3 hat geschrieben: ↑So Jul 14, 2024 2:04 pm Unter Version 1.9 hat auch alles sauber funktioniert.

Eine Bridge braucht man eigentlich nur dann, wenn man die Topics der openWB auf einem anderen mosquitto replizieren möchte. Also in einem, der im Internet steht, z.B. Oder wenn man einen subscriber hat, bei dem man nur einen Broker für alle topics angeben kann, die Topics sich aber über mehrere Broker verteilen. Das sind eher die exotischen Fälle. Bei nodeRed gibt man in jeder MQTT-in Node den Broker an. Da existiert das Problem nicht. Ich weiß nicht, wie das in ioB oder HA ist. Auf jeden Fall fühlen diejenigen, die hier von Problemen mit MQTT berichten, immer eine Notwendigkeit, eine Bridge konfigurieren zu müssen. Ich weiß nicht, woher das kommt. Vielleicht weil man‘s kann?

Ich bin bei MQTT noch nicht so tief drinne und werde mich dem Thema mehr widmen müssen. Ich habe einen eigenen mosquitto Server der mit HA verbunden bist. Ziel soll es sein, dass HA mit mosquitto verbunden ist und die OpenWB, Tasmota devices etc. an den mosquitto server senden und HA sich die Daten vom mosquitto holen. Funktioniert auch aktuell, solange ich nur lesend darauf zugreife.

Hier mal ein tut wie man HA und OpenWB verbindet: https://github.com/a529987659852/openwb2mqtt

Genau da steht ja beschrieben, dass man einen eigenen Broker braucht (da wird er leider „MQTT-Server“ genannt), wenn man außer der openWB noch andere MQTTs in seinem LAN hat. —> der HA ist so einer, bei dem man nur einen einzigen Broker in der Konfiguration einstellen kann. Der muss dann alle Topics gemeinsam bereitstellen.

Man könnte auch die Tasmotas in den openWB-Broker unter dem Ast „others/„ publishen lassen, der ist frei besshreibbar. (Die shellies der ersten Generation kommen da nicht dran, sie haben leider „shellies/„ als hart codierten Prefix, weshalb ich mal angeregt hatte, auch „shellies/„ frei besxhreibbar zu machen)

Gero hat geschrieben: ↑Mo Jul 15, 2024 5:28 am Genau da steht ja beschrieben, dass man einen eigenen Broker braucht (da wird er leider „MQTT-Server“ genannt), wenn man außer der openWB noch andere MQTTs in seinem LAN hat. —> der HA ist so einer, bei dem man nur einen einzigen Broker in der Konfiguration einstellen kann. Der muss dann alle Topics gemeinsam bereitstellen.

Man könnte auch die Tasmotas in den openWB-Broker unter dem Ast „others/„ publishen lassen, der ist frei besshreibbar. (Die shellies der ersten Generation kommen da nicht dran, sie haben leider „shellies/„ als hart codierten Prefix, weshalb ich mal angeregt hatte, auch „shellies/„ frei besxhreibbar zu machen)

Ich hab mich jetzt nochmal in das Thema eingelesen und ich habe einen mosquitto Server als Broker. In HA läuft ein MQTT Client, welcher mit dem Broker verbunden ist und eine zufällige Client-ID generiert. Der HA-Client hat auch eine Auto-Konfiguration, welche ich jedoch noch nicht so ganz verstehe: Ich habe nun einen Tasmato Client und dieser wurde automatisch in HA erkannt und ich kann sowohl lesen als auch schreiben. Ich hatte jetzt vermutet, dass HA sich die Topics automatisch subscribe, aber das prefix "homeassistant" wurde ja nicht angegeben. Mit openWB gibt es jetzt das Problem, dass openWB kein Client ist der Daten published, sondern ein eigner Broker. Ich muss jetzt entweder meinen mosquitto server (broker) als bridge konfigurieren, oder die openWB. Meine aktuelle Konfiguration ist wie folgt und ich kann die Daten in HA lesen. Vermutlich ist die Bridge aber noch falsch konfiguriert (hab seit v1.9 nicht geändert), denn beim schreiben (Lademodus ändern) zerschieße ich die openWB.
Die Einstellungen in HA greifen nicht, da es sich hier ausschließlich um die Bridge handelt. Ich dachte, dass OpenWB ein Client ist und ich ähnlich wie Tasmota die Verbindungsdaten eingeben muss. Aber die Daten sind nicht zum Verbinden, da openWB ein Broker ist. Verstehe ich es richtig und sind meine Konfigurationen bisher korrekt? Am besten die Konfiguration in openWB löschen. Falls ja, dann würde ich mir die mosquitto config genauer anschauen.

Wäre natürlich deutlich einfacher, wenn openWB ein Client wäre bzw. man zwischen Client und Broker wechseln könnte. Hat man einen eigenen Broker wegen HA oder warum auch immer, dann lässt man die OpenWB als Client laufen und wenn man die OpenWB für SmartHome nutzt, kann man die openWB als Broker nutzen. Wobei mir sich der Sinn nicht erschließt, wieso man die openWB als Broker nutzt. Die openWB ist ja eine smarte Wallbox und sollte alles können, was man hierzu braucht. Jemand der ein Smart Home einrichtet, greift dann direkt zu den dafür spezialisierten Tools.

Auf der openWB läuft ein mosquitto. In diesen werden dicerse topics der openWB gepublished und auch subscribed. Der mosquitto sorgt nun dafür, dass jeder, der sein Interesse an dem einen oder anderem
topic bekundet (ein Topic subscribed) Änderungen per push mitgeteilt bekommt, wenn sich eins der abonnierten Topics ändert. Der mosquitto hat also die Aufgabe, änderungen an Topics entgegenzunehmen und diese an die Abonnenten weiterzureichen. Die openWB als Software ist dabei sowohl Abonnent (die Topics zur Konfigurateion, die Topics für den Graphen) als auch Publisher (Messwerte der Zàhler, SoC des Speichers und auch datenpubkte für den Graphen). Der mosquitto kümmet sich um die Verteilung der Daten.

Nun kommt der HA ins Spiel. Der kann natürlich alles das, was ihn an der openWB interssiert von dem dortigen mosquitto abonnieren. Offensichtlich kann man im HA nur von einem einzigen mosquitto abonnieren. Das bringt uns nun zu dem Zwang entweder alle Topics im
Smarthome entweder auf dem openWB-mosquitto zu publishen (im Zweig others/) oder aber einen neuen mosquitto aufzusetzen, der
sowohl die openWB-Topics als auch die vom restlichen smarthome/tasmota entgegen nimmt. Damit man nun nicht einen extra client basteln muss, der alle openWB-Topics abonniert und sie auf dem anderen mosquitto published, gibt es die bridge: die macht nämlich genau das. Sie repliziert den openWB-mosquitto in einen Teilbaum des anderen Mosquitto, auf dem ja schon die anderen smarthome-Topics gepublished wurden. Damit hat man nun alle Topics (openWB ubd Tasmota) auf einem einzigen mosquitto, den der HA nun subscriben kann.

Ich bin gerade überrascht, dass der Unterschied zwischen IOBroker und HA offenbar größer ist, als ich dachte. Bei IOBroker lassen sich beliebig viele Instanzen von MQTT Brokern oder Subscribern erstellen. Eine Bridge, nur um mit unterschiedlichen Geräten über MQTT zu kommunizieren, braucht man für IOBroker also nicht - unabhängig davon ob sie einen Broker bereitstellen oder nicht.

Wenn das, was Ihr hier gerade diskutiert, über HA wirklich zutrifft (der Screenshot lässt das ja vermuten), dann ist die Bridge wohl tatsächlich für viele HA Nutzer erforderlich. Ich hätte das eher für ein exotisches Szenario gehalten (nutze selbst IOBroker).

Nicht vergessen die Tatsache das die openWB Befehle nur über die */set/* topics annimmt.
Direktes schreiben in die anderen Topics werden meist bei der nächsten regelschleife wieder überschrieben mit den Zustandswerten aus dem Ram/Ramdisk.
Wenn also HA o.a. beim schreiben nicht die Topic "umschreiben" kann, klappts auch nicht.
Egal ob Bridge oder nicht.