MQTT

[aiole]

Ja, natürlich...das Web-UI ist ja auch offen.
Ein "fremder" Client müsste ja erstmal in Dein Heimnetz, wie jemand mit einem Browser (zB Smartphone) auch.
ich sehe hier kein anderes Scheunentor, wie es bisher bei der openWb auch schon gewollt war.

Ach klar - wieder den Wald vor lauter Bäumen nicht gesehen .
OK - theoretisch ist der openWB-MQTT-broker dann auch ein schönes Angriffsziel für Viren usw.. Sowie der broker gekapert ist, publisht er munter nach draußen (sofern keine Authent. implementiert ist). Gut - das ist jetzt auch nix anderes als wenn der PC infiltriert ist.
VG

[hominidae]

.....eben.
Man könnte aber, analog wie die PIN auf dem Display, eine User/PW-Kombo einstellen, für den Broker....muss halt umgesetzt und auch genutzt werden.
Viel mehr Sicherheit als Dein Gäste-WLAN-PW, das Du ja auch nie änderst bringt es aber nicht...aber besser als keines oder ein default-PW

[aiole]

Zustimmung - 100% bekommt man sowieso nicht.

[truckl]

Entschuldigung, aber ich verstehe nicht wieso ihr so vehement gegen eine OpenWB seid, in welcher man den OpenWB Mosquitto als Bridge im Client-mode für einen anderen ZMQ-Broker konfigurieren kann. Diese hätte meines erachtens eine ganze Reihe von Vorteilen gegenüber der Lösung mit dem openWB-Mosquitto als Server:

1. Der OpenWB Mosquitto müßte in keiner Weise der Außenwelt ausgesetzt werden. Keine Portforwardings oder ähnliches da er nur in der Bridge nur als Client fungiert (selbst also die Verbindung von innen nach außen aufbaut, was ohne spezielle Firewall-Löcher funktioniert).
2. Mit einem WebUI fürs Bridging hätte man 100% unter Kontrolle was in die Mosquitto-Konfiguration eingetragen wird denn das WebUI würde die "topic ..."-Einträge verwalten und nicht der User.
   • Auch ganz ohne in der OpenWB Authentifizierung zu konfigurieren behält die OpenWB die volle Kontrolle darüber was und wie mit der Außenwelt Daten ausgetauscht werden. Im Notfall eine "topic ..."-Zeile ohne Wildcard für jedes einzelne Topic. Diese Konfiguration müßte ja nur einmal geschrieben und als Vorlage gepflegt werden.
   • Die meisten Topics würden nur als "Out" in die Bridge eingetragen werden. Dann besteht nicht das geringste Risiko daß irgendwelche Daten vom bösen Internet-MQTT-Server zum OpenWB-Server fließen.
   • Die Steuerfunktionenen (openWB/.../set) könnten ebenfalls einzeln freigegeben werden oder auch nicht. Die Kontrolle darüber was freigegeben wird bleibt einzig und alleim beim OpenWB Mosquitto. Und wie schon geschrieben wurde: Wer auf das Webfrontend Zugriff hat kann sowieso alles machen was er will. So lange OpenWB kein HTTPS mit Basic Authentifizierung im WebUI hat, hat prinzipiell jeder der sie netzwerk-technisch erreichen kann Vollzugriff.
3. Die Verwaltung wäre ein Kinderspiel und nahezu komplett getrennt von der OpenWB-internen Mosquitto-Konfiguration. Denn Moquitto unterstützt verteilte Konfigurationen über "/etc/mosquitto/conf.d/*.conf". Man kann dort ein Konfig-File für jede Bridge ablegen.
4. Es müßte keine Authentifkation im OpenWB MQTT-Broker implementiert werden. Der OpenWB-Mosquitto authentifiziert sich ja nur gegenüber dem "fremden" MQTT-Server. Dieser "fremde" Server müßte Authentifizierung umsetzen (natürlich sowohl gegenüber dem OpenWB als auch gegenüber anderen User-Clients). Tut der fremde Server das nicht, ist das sehr schlecht. Aber nichts was OpenWB, selbst mit noch so viel Mühe, irgendwie verhindern könnte.

Ich sehe ja ein, daß man es nicht zu einfach machen sollte Fehlkonfigurationen und offene OpenWBs zu produzieren.
Aber ein großteil der Nutzer werden diese oder irgend eine andere Kopplung unweigerlich haben wollen.
Und ich weis nicht ob zu restriktives "wir sind hier und bleiben lokal weil das sicherer ist" dann nicht nach hinten losgehen kann. Denn was kann dadurch passieren? Ich denke das hier:

• DAU Googelt.
• DAU findet irgend eine Internet-Seite (z.B. die hier) auf der erklärt ist wie man die Daten zu einem externen Broker bekommt.
• DAU tippt von der Seite irgendwelche Konfigurationen ab ohne zu wissen was dahinter steckt und was das daher für Konsqeuenzen hat.

Wäre da nicht eine gut durchdachte OpenWB-UI-Page auf der die Konfiguration und auch deren Risiken möglichst gut erklärt werden (sehr gerne mit dicker, fetter Warnung was man da tut, vor allem falls keine Authentifizierung und/oder kein TLS zum Remote-MQTT verwendet wird) die bessere Alternative?

[hominidae]

Hmmm, naja von Vehemenz kann da jetzt nicht die Rede sein, finde ich.

Ich habe da auch drüber nachgedacht, bin aber aus zwei Gründen zu dem Schluss gekommenen, das es ausreicht wenn die openWB clients zulässt, anstatt aktiv zu bridgen.

1. Was wenn der remote Server nicht erreichbar ist?
Kann das zu einer zusätzlichen Last der openWB führen, welches die eigentliche Funktion/Aufgabe beeinträchtigt? Ist halt nur ein popeliger RPi drin.

2. Ist der Grund, warum mqtt nun eingeführt wurde, der eine Vernetzung über mqtt zu ermöglichen? Bisher nutzen das doch eher die Nerds
Eine komplexere Implementierung auf der openWB, über die Möglichkeit mqtt clients zur openWB zu verbinden hinaus, erscheint mir nicht in die Philosophie "des Herstellers" zu passen.


Auch müsste man, wenn man Deinen Vorschlag umsetzt, konsequent den Client Zugriff ausschließen, oder?
Ich bin daher mit der Möglichkeit nen mqtt client, bzw in Eigenregie über "meinen lokalen Broker" zu bridgen voll zufrieden.
Ports muss ich auch keine öffnen um die openWB ins I-Net zu bringen.

[openWB]

@Kevin
Das ist mir klar, dass non-local und save gerade mit dem MQTT funktioniert.

Wir müssen nur darauf achten, dass der Normaluser, der nichts von MQTT versteht (stelle mir gerade vor, was meine Frau denkt, wenn Sie etwas subscriben soll ), nicht durch "Alexa und Co."-Verknüpfungsoptionen bezüglich der Sicherheit seiner/ihrer Daten verunsichert wird.
VG

Der Normaluser sieht davon nichts in der Bedienung.
Wer aktuell die Beta nutzt, nutzt auch MQTT ohne es zu wissen.

Ich verstehe auch die Argumente daß IoT-Geräte sparsam sein sollten. Aber die OpenWB ist ja nun sowieso alle 10 Sekunden ganz ordentlich beschäftigt um Skripte zu starten und externe Datenquelle abzufragen. Da finde ich eine Diskussion über das Sparpotential durch etwas weniger Aufbereitung der Daten nicht so ganz zielführend
Aber klar, ich will natürlich auch nicht daß sinnlos Energie verbraten wird nur weil sie im Überfluß in Form von 32A Drehstrom vorhanden ist.

Das macht sie aber lokal und ist dem Modulartigen Aufbau geschuldet.
Gäbe es nur openWB würde ich das ganz anders machen, Kompatibilität hat lokal aber Vorrang vor Performance.

Zudem - aus meiner Sicht - sollte man die "globalen" Daten (Energie I/O (PV, Heimakku, Grid), Zustand, ...) in eine eigene Untergruppe packen, so dass ich als Client (Ladesteuerung für einen Ladepunkt) zB. nur die "globalen" Daten zur allgemeinen Info, und den einen Ladepunkt, den die App überwachen möchte, abonniere, und nicht alle Ladepunkte haben muss, weil ich statt 50 Topics lieber wenige Untertopics abonniere, im Idealfall z.B. "OpenWB/global/#" und "OpenWB/lp1/#". Derzeit müsste ich "OpenWB/#" abonnieren, um an alle, auch "WHouseConsumption", ranzukommen. Die Hierarchie ist noch nicht ideal. Keine Daten in der obersten Ebene...

Sehr guter Punkt, das wird noch geändert.

.....eben.
Man könnte aber, analog wie die PIN auf dem Display, eine User/PW-Kombo einstellen, für den Broker....muss halt umgesetzt und auch genutzt werden.
Viel mehr Sicherheit als Dein Gäste-WLAN-PW, das Du ja auch nie änderst bringt es aber nicht...aber besser als keines oder ein default-PW

Würde aber bedeuten das das Webinterface dann automatisch auch nur mit User/Passwort nutzbar wäre. Semi optimal

Entschuldigung, aber ich verstehe nicht wieso ihr so vehement gegen eine OpenWB seid, in welcher man den OpenWB Mosquitto als Bridge im Client-mode für einen anderen ZMQ-Broker konfigurieren kann. Diese hätte meines erachtens eine ganze Reihe von Vorteilen gegenüber der Lösung mit dem openWB-Mosquitto als Server:

Ich bin da nicht gegen und sehe genau da einen Anwendungsfall in der Zukunft, sprich bridging zu einem anderen Broker, gern auch nicht lokal mit Verschlüsselung und Authentifizierung.

@hominidae
Zu1.
Das gilt es dann noch zu testen wenn MQTT lokal stabil läuft (was aktuell aber der Fall zu sein scheint).
Zu2.
Performance, Vereinfachung für die Zukunft und auch eine Anbindung nach außen schaffen die sicher nutzbar ist.
Es gibt eben Leute die diese Anforderung haben und dafür auch zahlen, wer lokal bleiben möchte muss es nicht aktivieren.

[truckl]

Zu1.
Das gilt es dann noch zu testen wenn MQTT lokal stabil läuft (was aktuell aber der Fall zu sein scheint).

Ich habe mal die Performance bei nicht verfügbarem remote-MQTT-Server getestet. Habe schon länger auf dem OpenWB RASPI Influx Telegraf installiert und monitore diesen, so wie auch alle anderen RASPIs und Geräte im Haushalt. Die Visualisierung mit Grafana für "CPU usage" und "Load averages" findet ihr im Anhang. Zusammen mit einem Log-Auszug (private Daten maskiert) von meinem Internet-MQTT-Server (self-hosted auf Miet-Server) der beweist in welchem Zeitraum er nicht gelaufen ist (ca. von 19:06 bis 19:26).
Zustand der OpenWB (series2 mit Display) während des Tests: Fahrzeug an LP1 angeschlossen und ladend mit 1P16A. EVU-Kit. Kein PV. OpenWB Display Off. Verbindung zum Remote-MQTT über TLS-verschlüsselt (keine Sorge die unverschlüsselten Ports im Log sind nur über VPN erreichbar).

Ich bin mir absolut sicher, daß sich das in der Performance nicht bemerkbar macht.
Mosquitto ist kein Nischenprodukt!
Wenn die Entwickler von Mosquitto beim Briding derart gepfuscht hätten daß Mosquitto ein System in den Abgrund zieht nur weil ein Bridge-Remote-Server nicht verfügbar ist, dann würden die vermutlich einen Shitstorm von ordentlichem Kaliber ernten.

Und außerdem ist ein RASPI kein ESP32. Es ist ein Prozessor aus einer Gattung, mit der millionen Junge (und Alte ) Leute stundenlang ganz ansehnliche Spiele zocken können.

Zu2.
Performance, Vereinfachung für die Zukunft und auch eine Anbindung nach außen schaffen die sicher nutzbar ist.
Es gibt eben Leute die diese Anforderung haben und dafür auch zahlen, wer lokal bleiben möchte muss es nicht aktivieren.

Danke Kevin.
Ich könnte mir gut vorstellen die Backend-Seite (Mosquitto-Konfig-Template und Skript zum installieren/entfernen welches durch das Web-UI aufgerufen werden könnte) für eine "programmatische Bridge-Konfiguration" zu übernehmen. Sofern es nicht gleich morgen fertig sein muß .
Für Unterstützung beim Web-UI zum Eingeben der Settings (Settings -> MQTT Bridging ?) wäre ich aber sehr dankbar. Freiwillige?

[lacky]

openWB/global/ChargeMode
# Lademodus, 0 = Sofort Laden (Direct), 1 = Min und PV, 2 = Nur PV, 3 = Stop, 4 = Standby

...dieser wird leider nicht gesendet?!

[truckl]

openWB/global/ChargeMode
# Lademodus, 0 = Sofort Laden (Direct), 1 = Min und PV, 2 = Nur PV, 3 = Stop, 4 = Standby

...dieser wird leider nicht gesendet?!

Gute Beobachtung! Der Wert fehlt.

Wird derzeit nur gesendet wenn er sich ändert denn irgendwie ist für dieses eine Topic

1. mein PR zum Bulk-Publish verloren gegangen oder dabei vergessen worden
2. im durch 1. wieder vorhandenen mosquitto_pub Aufruf das "-r" für "retain" vergessen worden

Der Wert wird also vom MQTT-Broker nicht gespeichert und daher wirklich nur an Clients gesendet die zum Zeitpunkt der Änderung auf das Topic subscribed sind.

Ich habe für einen Fix den Pull Request #265 gestellt.

[truckl]

Ich hätte noch einen Vorschlag: Könnte bei den Werten für die Ladepunkte nicht die Nummer des Ladepunkts eine separate Hierarchie-Ebene im Topic sein?
Beispiel:

Code: Alles auswählen

openWB/lp/1/kWhDailyCharged

anstatt dem momentanen

Code: Alles auswählen

openWB/lp1/kWhDailyCharged

Begründung:
MQTT-Wildcards funktionieren nur für jeweils einen gesamten Hierarchie-Level (siehe z.B. die Erklärung für Paho MQTT).

Will man nun einen bestimmten Wert aber für alle Ladepunkte subscriben geht das mit dem bisherigen Ansatz nur durch explizite subscribes auf

Code: Alles auswählen

openWB/lp1/kWhDailyCharged
openWB/lp2/kWhDailyCharged
...
openWB/lp<N>/kWhDailyCharged

denn

Code: Alles auswählen

openWB/lp+/kWhDailyCharged

ist kein(!) gültiger MQTT-Subscription-Ausdruck.

Wäre die Ladepunkt-Nummer ein eigener Hierarchie-Level würde aber dieser Subscribe hier funktionieren:

Code: Alles auswählen

openWB/lp/+/kWhDailyCharged