MQTT
-
- Beiträge: 1407
- Registriert: Di Sep 03, 2019 4:13 pm
- Has thanked: 7 times
- Been thanked: 8 times
Re: MQTT
...die Frage ist, wer in der MQTT Bridge der Initiator ist.
Du kannst..
a) die openWB die Daten zum Mosquitto des FHEM bridgen lassen....dabei natürlich die Methode (mit/ohne TLS usw) verwenden, die FHEM/MQTT vorschreibt.
b) oder Du lässt FHEM/MQTT die Bridge aufbauen und die Daten der openWB subscriben..dazu wird dann die Authentifizierung verwendet, die openWB "vorschreibt"....diese ist "ohne/offen".
Siehe auch hier: viewtopic.php?f=6&t=591 ... daraus ist der Feature für (a) hervorgegangen...ich nutze selbst immer noch (b) aus meinem SmartHome zur Integration der openWB.
Das lässt die openWB selbst unverändert.
Eine besondere Absicherung der openWB im LAN ist, allgemein so festgelegt, nicht üblich und nötig und daher nicht vorgesehen.
Du kannst..
a) die openWB die Daten zum Mosquitto des FHEM bridgen lassen....dabei natürlich die Methode (mit/ohne TLS usw) verwenden, die FHEM/MQTT vorschreibt.
b) oder Du lässt FHEM/MQTT die Bridge aufbauen und die Daten der openWB subscriben..dazu wird dann die Authentifizierung verwendet, die openWB "vorschreibt"....diese ist "ohne/offen".
Siehe auch hier: viewtopic.php?f=6&t=591 ... daraus ist der Feature für (a) hervorgegangen...ich nutze selbst immer noch (b) aus meinem SmartHome zur Integration der openWB.
Das lässt die openWB selbst unverändert.
Eine besondere Absicherung der openWB im LAN ist, allgemein so festgelegt, nicht üblich und nötig und daher nicht vorgesehen.
-
- Beiträge: 3779
- Registriert: Di Feb 25, 2020 9:23 am
- Has thanked: 4 times
- Been thanked: 24 times
Re: MQTT
Das würde ich so nicht unterschreiben.
Es ist aktuell nicht vorgesehen, das stimmt. Das heißt aber nicht, dass eine Absicherung nicht sinnvoll ist. Nahezu alle neueren Geräte mit Netzwerkanbindung bieten zumindest Https mit selbstsignierten Zertifikaten an, um Daten auf dem Transportweg zu verschlüsseln. Für Mqtt kann das analog via TLS umgesetzt werden. Ebenfalls finde ich eine optionale Anmeldung mit Benutzer/Kennwort beim Mqtt-Broker und/oder Web-GUI sinnvoll, um den Zugang bei Bedarf einschränken zu können.
Frei nach dem Motto: alles kann, Nichts muss.
-
- Beiträge: 1407
- Registriert: Di Sep 03, 2019 4:13 pm
- Has thanked: 7 times
- Been thanked: 8 times
Re: MQTT
Diese DIskussionen gab es ja hier schon öfter....auch von mir......gut, sagen wir also "bisher" nicht vorgesehen.
Ich finde ja auch, das ein kommerzielles, vernetztes Produkt etwas mehr Eigensicherheit vertragen könnte....ein Satellit, im Vorgarten mit Ethernet angebunden ist mMn auch schon ein Scheunentor und die Rückzugsposition war, so hiess es ja immer, "für LAN nicht nötig".
Aber warten wir mal ab....
Ich finde ja auch, das ein kommerzielles, vernetztes Produkt etwas mehr Eigensicherheit vertragen könnte....ein Satellit, im Vorgarten mit Ethernet angebunden ist mMn auch schon ein Scheunentor und die Rückzugsposition war, so hiess es ja immer, "für LAN nicht nötig".
Aber warten wir mal ab....
Re: MQTT
In fhem doch einfach nach Anleitung MQTT2_CLIENT und dann MQTT2_DEVICE einrichten. Im Device dann alle Topics berücksichtigen, die interessieren. Dann muss in openwb nichts angepasst werden.
Thema Sicherheit: Bei WLAN alles inklusive! Bei mir läuft dies über WLAN bestens (openWB, go-eCharger, fhem und SmartPi). Man muss sich nur einmalig um die WLAN-Adeckung kümmern und innerhalb „normaler“ Spez. bleiben.
Thema Sicherheit: Bei WLAN alles inklusive! Bei mir läuft dies über WLAN bestens (openWB, go-eCharger, fhem und SmartPi). Man muss sich nur einmalig um die WLAN-Adeckung kümmern und innerhalb „normaler“ Spez. bleiben.
openWB Charge Controller Ver. 1.9.227 auf Pi 4 (buster) - go-eCharger Ver. 040.0 an ca. 35m-Leitung und 3x25A FI-LS Typ-A - WR: Fronius Symo Ver. 3.16.7-1 Modbus TCP - EVU: smartPi MQTT/Node-RED - BEV: Renault Zoe R110 Zen 2020
Re: MQTT
In diesem Listing sind falsche topics aufgeführt und andere fehlen komplett.
ich habe z.B.
Code: Alles auswählen
openWB/config/set/sofort/lp/1/current
Gibt es irgendwo eine Stelle an der zentral verlässlich gültige, aktuelle Informationen gesammelt sind, z.B. ein Wiki?
Re: MQTT
Da wäre ich allerdings auch dran interessiert.
Alternativ wäre der bereits mehrfach hier erwähnte MQTT Explorer (https://mqtt-explorer.com/) zu empfehlen.
openWB series2 custom - SolarEdge | 9.92 kWp | 2 x SE5000H | LG Resu10H 9.3 kWh - MB EQA 250
Re: MQTT
Vielen Dank hominidae für die Erläuterung!
Ich habe das jetzt so umgesetzt, dass openWB die Daten an fhem mqtt (TLS) bridged, dort läuft ein mosquitto.
In fhem ist ein MQTT2CLIENT definiert, der als Schnittstelle zu den MQTT2DEVICEs dient.
Ich kam leider erst jetzt dazu, das Projekt weiterzuverfolgen, dazu kommt, dass für mich die Syntax von mqtt2... in fhem nicht so intuitiv war.
Zumindest läuft das ganze nun dahingehend, dass subsriben / publishen prinzipiell möglich ist.
An der Stelle möchte ich an die Beiträge zuvor anknüpfen:
Die Topics in Artikel 1 funktionieren (zum Teil) nicht und scheinen überholt.
Ich wollte die Topics mal auf den aktuellen Stand bringen, scheitere aber teilweise schon daran, dass ich gar keine Werte erhalte.
Mein Verständnis ("soll" Zustand) zu den Topics ist bei einer Wallbox mit Ladepunkt1:
Einstellungen aus der GUI interpretiert mqtt mit:
Einstellungen per publish ändern:
Einstellungen subscriben:
Während das ändern das Ändern des Lademodus über folgenden publish funktioniert:
kann ich den Topic Pfad zum Ändern der Stromstärke und zu ladenenden kWh nicht anwenden, hier funktioniert nur:
Soweit kann ich damit alles steuern, ich habe nur das Problem, dass ich bei den beiden letzteren nichts subscriben kann.
Ändere ich den Wert der Stromstärke, bekomme ich nur die Publish Nachricht (mit der Stromstärke - hier 7A), gefolgt von einer Publish Nachricht (null).
Somit habe ich stets leere Werte bei Stromstärke und kWh zu laden:
Client mosqsub|2322-fhem received PUBLISH (d0, q0, r0, m0, 'fhem/openWB/config/set/sofort/lp/1/current', ... (1 bytes))
fhem/openWB/config/set/sofort/lp/1/current 7
Client mosqsub|2322-fhem received PUBLISH (d0, q0, r0, m0, 'fhem/openWB/set/system/topicSender', ... (67 bytes))
fhem/openWB/set/system/topicSender local client uid: ktmkp sent: openWB/config/set/sofort/lp/1/current
Client mosqsub|2322-fhem received PUBLISH (d0, q0, r0, m0, 'fhem/openWB/config/set/sofort/lp/1/current', ... (0 bytes))
fhem/openWB/config/set/sofort/lp/1/current (null)
Client mosqsub|2322-fhem received PUBLISH (d0, q0, r0, m0, 'fhem/openWB/set/system/topicSender', ... (0 bytes))
fhem/openWB/set/system/topicSender (null)
Im o.g. Fall habe ich ein subscribe auf openWB/# gemacht und alle Daten geprüft...
Hat jemand Erfahrung, wie man an die Werte kommt?
Ich habe das jetzt so umgesetzt, dass openWB die Daten an fhem mqtt (TLS) bridged, dort läuft ein mosquitto.
In fhem ist ein MQTT2CLIENT definiert, der als Schnittstelle zu den MQTT2DEVICEs dient.
Ich kam leider erst jetzt dazu, das Projekt weiterzuverfolgen, dazu kommt, dass für mich die Syntax von mqtt2... in fhem nicht so intuitiv war.
Zumindest läuft das ganze nun dahingehend, dass subsriben / publishen prinzipiell möglich ist.
An der Stelle möchte ich an die Beiträge zuvor anknüpfen:
Die Topics in Artikel 1 funktionieren (zum Teil) nicht und scheinen überholt.
Ich wollte die Topics mal auf den aktuellen Stand bringen, scheitere aber teilweise schon daran, dass ich gar keine Werte erhalte.
Mein Verständnis ("soll" Zustand) zu den Topics ist bei einer Wallbox mit Ladepunkt1:
Einstellungen aus der GUI interpretiert mqtt mit:
Code: Alles auswählen
openWB/config/set/sofort/lp/1/...
Code: Alles auswählen
openWB/set/lp/1/...
Code: Alles auswählen
openWB/lp/1/...
Während das ändern das Ändern des Lademodus über folgenden publish funktioniert:
Code: Alles auswählen
openWB/set/ChargeMode x
Code: Alles auswählen
openWB/config/set/sofort/lp/1/current (bzw. /energyToCharge)
Ändere ich den Wert der Stromstärke, bekomme ich nur die Publish Nachricht (mit der Stromstärke - hier 7A), gefolgt von einer Publish Nachricht (null).
Somit habe ich stets leere Werte bei Stromstärke und kWh zu laden:
Client mosqsub|2322-fhem received PUBLISH (d0, q0, r0, m0, 'fhem/openWB/config/set/sofort/lp/1/current', ... (1 bytes))
fhem/openWB/config/set/sofort/lp/1/current 7
Client mosqsub|2322-fhem received PUBLISH (d0, q0, r0, m0, 'fhem/openWB/set/system/topicSender', ... (67 bytes))
fhem/openWB/set/system/topicSender local client uid: ktmkp sent: openWB/config/set/sofort/lp/1/current
Client mosqsub|2322-fhem received PUBLISH (d0, q0, r0, m0, 'fhem/openWB/config/set/sofort/lp/1/current', ... (0 bytes))
fhem/openWB/config/set/sofort/lp/1/current (null)
Client mosqsub|2322-fhem received PUBLISH (d0, q0, r0, m0, 'fhem/openWB/set/system/topicSender', ... (0 bytes))
fhem/openWB/set/system/topicSender (null)
Im o.g. Fall habe ich ein subscribe auf openWB/# gemacht und alle Daten geprüft...
Hat jemand Erfahrung, wie man an die Werte kommt?
-
- Beiträge: 1407
- Registriert: Di Sep 03, 2019 4:13 pm
- Has thanked: 7 times
- Been thanked: 8 times
Re: MQTT
...auf die Topics mit /set/ wird von Dir nicht subscribed, sondern nur ge-published.
OpenWB selbst subscribed diese und löscht diese, wenn der Wert dann "aufgenommen" wird....der Wert wird dann wieder im komplementären Topic von der openWB ge-published.
Beispiel:
- openWB/set/lp/1/ChargePointEnabled ...zum publishen
- openWB/lp/1/ChargePointEnabled ...zum subscriben
OpenWB selbst subscribed diese und löscht diese, wenn der Wert dann "aufgenommen" wird....der Wert wird dann wieder im komplementären Topic von der openWB ge-published.
Beispiel:
- openWB/set/lp/1/ChargePointEnabled ...zum publishen
- openWB/lp/1/ChargePointEnabled ...zum subscriben
Re: MQTT
OK, danke Dir. Das ist gut zu wissen!...auf die Topics mit /set/ wird von Dir nicht subscribed, sondern nur ge-published. OpenWB selbst subscribed diese und löscht diese,..
Es bleibt die Frage, wo ich das o.g. Beispiel subscriben kann?
Wie gesagt, wenn ich auf openWB/# subscribe und am "current" Wert (in der GUI oder per Publish) etwas ändere,
erhalte ich nur die Publish Meldung zu openWB/config/set/sofort/lp/1/current.
Haben andere auch diese Erfahrung?
Ich kann so die Werte für den Ladestrom bzw. kWh bei Sofortladen ja nicht subscriben....
-
- Beiträge: 1407
- Registriert: Di Sep 03, 2019 4:13 pm
- Has thanked: 7 times
- Been thanked: 8 times
Re: MQTT
Ah...jetzt verstehe ich.
Also:
....wenn man ein publish auf "openWB/config/set/sofort/lp/1/current <WERT>" macht,
...dann kommt der <Wert> unter openWB/config/get/sofort/lp/1/current beim "subscribe" zurück?
Das ist ein Feature und kein Bug.
Da dies der Wert für die eingestellte Stromstärke im Sofortladen-Modus ist, wird der in der Konfiguration gespeichert.
Das kannst Du also einstellen, ohne das eine Ladung aktiv ist.
Erst wenn der LP1 aktiviert und das Auto angesteckt ist, bekommst Du die aktuellen Werte des dann laufenden Ladevorgangs - unabhängig vom Lademodus - unter openWB/lp/1/AConfigured via subscribe zurück.
Edit: evtl. hast Du auch das Problem, dass Du zB Werte im mqtt Broker - zB mit MQTT-Explorer - "siehst", diese aber im FHEM mit dem Client nicht "bekommst"?
Auch das ist "normal", je nach dem, wie Du den Client ausprägst....MQTT ist keine Datenbank, sondern ein Kommunikationsprotokoll.
Es gilt ein Publish / Subscribe Mechanismus.
Also, ein Client subscribed zu einem Topic....das ist wie ein Abo auf die Daten dieses Topic.
Ist das Topic vorhanden und wurde der Wert/das Topic zuvor mit dem "retain Flag" ge-published, dann bekommt der Client jetzt *einmal* diesen Wert über das "subscribe".
Ohne Retain Flag bekommt der Client erstmal nix, erst wenn ein anderer ein Publish macht, nachdem das Subscribe "Abo" besteht, wird der Wert an den Subscriber gepusht.
openWB puplished erfolgt immer mit "retain"...also bekommt der Client erstmal "alles", aber nur einmal.
danach nur, wenn es ein update gibt.
Das sieht man schön im MQTT-Explorer.
Um nochmal alles zu bekommen, muss der Client die Verbindung zum Broker trennen und neu aufbauen.
Also:
....wenn man ein publish auf "openWB/config/set/sofort/lp/1/current <WERT>" macht,
...dann kommt der <Wert> unter openWB/config/get/sofort/lp/1/current beim "subscribe" zurück?
Das ist ein Feature und kein Bug.
Da dies der Wert für die eingestellte Stromstärke im Sofortladen-Modus ist, wird der in der Konfiguration gespeichert.
Das kannst Du also einstellen, ohne das eine Ladung aktiv ist.
Erst wenn der LP1 aktiviert und das Auto angesteckt ist, bekommst Du die aktuellen Werte des dann laufenden Ladevorgangs - unabhängig vom Lademodus - unter openWB/lp/1/AConfigured via subscribe zurück.
Edit: evtl. hast Du auch das Problem, dass Du zB Werte im mqtt Broker - zB mit MQTT-Explorer - "siehst", diese aber im FHEM mit dem Client nicht "bekommst"?
Auch das ist "normal", je nach dem, wie Du den Client ausprägst....MQTT ist keine Datenbank, sondern ein Kommunikationsprotokoll.
Es gilt ein Publish / Subscribe Mechanismus.
Also, ein Client subscribed zu einem Topic....das ist wie ein Abo auf die Daten dieses Topic.
Ist das Topic vorhanden und wurde der Wert/das Topic zuvor mit dem "retain Flag" ge-published, dann bekommt der Client jetzt *einmal* diesen Wert über das "subscribe".
Ohne Retain Flag bekommt der Client erstmal nix, erst wenn ein anderer ein Publish macht, nachdem das Subscribe "Abo" besteht, wird der Wert an den Subscriber gepusht.
openWB puplished erfolgt immer mit "retain"...also bekommt der Client erstmal "alles", aber nur einmal.
danach nur, wenn es ein update gibt.
Das sieht man schön im MQTT-Explorer.
Um nochmal alles zu bekommen, muss der Client die Verbindung zum Broker trennen und neu aufbauen.