Zukunft von Bindings - wie sollte man die Anbindungen gestalten

[Willnix]

Hallo,

ich habe mal eine Frage an die Experten.
Ich habe angefangen - mit Hilfe von ChatGPT5 - mir selber ein Binding zu bauen für meinen ID.Buzz.
Das funktioniert erstaunlich gut und einfach, da ChatGPT vieles selber macht und mit dem Projekt von Till (https://github.com/tillsteinbach/CarConnectivity) die Vorlage bereits existiert.

Jetzt stelle ich mir nur die Frage ist das richtig?
Sollten nicht lieber alle Anbindungen über z.B. MQTT laufen - was ja auch bei Till in seinem Projekt möglich ist ?
Oder bauen wir uns in OpenHAB dann die Bindings selber, immer mit der Frage wer pflegt diese?
Auf der anderen Seite haben vielleicht nicht alle zu Hause einen eigenen MQTT Server?

Eine MQTT Anbindung nutze ich aktuell für meiner E3DC Anlage und dem Projekt RSCP2MQTT (https://github.com/pvtom/rscp2mqtt), weil ich in dem Modbus Binding z.B. keine Begrenzung der Batterieladeleistung umsetzen kann. Das läuft sehr gut und stabil.

Wie ist eure Meinung? Gibt es diese Diskussion schon für die Weiterentwicklung von OpenHAB?

Vielen Dank und viele Grüße
Ulf

[peter-pan]

Ich hab zwar keine Anbindung an an ein Car-Binding und bin auch nur ganz normaler OH-User, also auch kein Experte, aber ich kann mir nicht vorstellen, dass es einen OH-User gibt, der keinen MQTT-Server laufen hat, da der m.E. zur "Muss-Ausstattung/-Erweiterung" von OpenHAB gehört und es dafür auch einen Client (Binding) für OH gibt.

Bei mir laufen mittlerweile ca. 150-160 Geräte/Devices, die per MQTT/Z2M Daten an OH liefern. Und die meisten davon basieren auf der Firmware "Tasmota" und "ZigBee", aber auch Scripte, die interne Daten ermitteln und die aufbereiten Ergebnisse per MQTT an OH weitergeben.

Ach so: Ich benutze "Mosquitto" als Server.

Hilft dir das weiter ?

[udo1toni]

Da gehen die Meinungen gerne auseinander. Meine zwei Cent:

mqtt ist ein Protokoll, wie z.B. http. Es gibt die Möglichkeit, auf diverse Geräte per http zuzugreifen und in vielen Fällen kann man damit Geräte leicht einbinden, ohne extra ein Binding schreiben zu müssen. Sobald es allerdings mit hohem Aufwand verbunden ist (z.B. Abfrage nur über einen Link möglich, der dann unterschiedlichste Daten liefert, die mittels Scripten in eine geeignete Form gebracht werden müssen), ist es sinnvoll und wünschenswert, dass es ein eigenes Binding gibt.

Einen mqtt Server aufzusetzen ist trivial (ganz besonders, wenn man schon openHAB erfolgreich zum laufen gebracht hat ) und es gibt so viele Geräte, die mqtt als Grundlage verwenden, dass es mir sehr sinnvoll erscheint, mqtt mindestens als sinnvolle Ergänzung zu sehen.

Speziell zum Thema VW:
Ursprünglich hieß es mal we-connect. Inzwischen heißt es "VW Connect" (siehe https://www.volkswagen.co.uk/en/connect ... nnect.html).

Im Fall von weconnect (da gibt es auch ein Produkt von Till Steinbach) gibt es schon ein "echtes" openHAB Binding, allerdings ist das leider in der Entwicklung stecken geblieben. Unter openHAB5 läuft das Binding meines Wissens nicht mehr. Die letzte direkt verfügbare Version ist für 4.1.2 gebaut (siehe Link in diesem Posting: https://community.openhab.org/t/connect ... 92378/1327) und die habe ich bis zuletzt unter openHAB4 parallel zu weconnect genutzt
Leider ist es so, dass Till Steinbachs weconnect Service andere Daten liefert als sein carConnectivity Service (und Wolfgang Rosenauers Binding liefert nur einen kleinen Bruchteil der Infos), beide Dienste parallel laufen zu lassen erhöht natürlich die API Zugriffe, das könnte also irgendwann zu Problemen führen.
Da der carConnectivity wie der weconnect Service die Daten schon aufbereitet zur Verfügung stellt, sehe ich für mich keine dringende Notwendigkeit, ein eigenes Binding zu nutzen. Einen passenden Container kann ich mit wenigen Handgriffen starten und mit mqtt steht ein hinreichend schlankes und dennoch flexibles Protokoll zur Verfügung, um die Daten bequem in openHAB verfügbar zu machen. Wie oben angedeutet habe ich noch andere mqtt-Datenquellen, hauptsächlich Tasmota, aber auch ZigBee2mqtt und noch ein paar andere Geräte (z.B. Wallbox)