openWB Forum

...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.

hominidae hat geschrieben: ↑Do Dez 31, 2020 12:13 pm Eine besondere Absicherung der openWB im LAN ist, allgemein so festgelegt, nicht üblich und nötig und daher nicht vorgesehen.

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.

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....

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.

openWB hat geschrieben: ↑Fr Okt 25, 2019 7:01 pm MQTT ist künftig der präferierte Weg der externen Kommunikation.
...

In diesem Listing sind falsche topics aufgeführt und andere fehlen komplett.
ich habe z.B. erst nach einiger Suche irgendwo im Forum gefunden.

Gibt es irgendwo eine Stelle an der zentral verlässlich gültige, aktuelle Informationen gesammelt sind, z.B. ein Wiki?

fraxinas hat geschrieben: ↑Mi Jan 27, 2021 3:16 pm Gibt es irgendwo eine Stelle an der zentral verlässlich gültige, aktuelle Informationen gesammelt sind, z.B. ein Wiki?

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.

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?

...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

...auf die Topics mit /set/ wird von Dir nicht subscribed, sondern nur ge-published. OpenWB selbst subscribed diese und löscht diese,..

OK, danke Dir. Das ist gut zu wissen!

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....

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.