[Hinweis] Preview CometVisu mit MQTT

[Chris M.]

In der nächsten CometVisu Version 0.12.0 (und damit auch in den aktuellen Release Candidates) ist bereits Unterstützung für MQTT als Backend implementiert. Da hier Stand heute noch keine ausreichende Test-Tiefe vorhanden ist, ist dieses Feature aktuell noch im Status "Preview".

Um die MQTT-Schnittstelle auszuprobieren braucht es nur ein paar einfache Schritte:

Als erstes wird ein MQTT Broker, wie Mosquitto, benötigt. Dieser Broker muss MQTT über Websockets bereit stellen. Ob der Broker auf dem TWS in einem Docker-Container läuft, oder wo anders im Netz läuft, ist egal.
Wichtig ist aber, dass wenn die CometVisu über HTTPS läuft (also über den Proxy), so muss die WebSocket-Schnittstelle des Brokers auch über Secure WebSockets (also "wss:" statt "ws:") erreichbar sein. Mit der neuesten TWS Software (3.0 Release Candidate 1.1) kann hier der TWS-Proxy auch für WebSocket verwendet werden.

In der CometVisu muss nun nur in der Config-Datei im <pages>-Element mit dem Attribut backend="mqtt" der MQTT-Modus ausgewählt werden. Über das Attribut backend-url wird die URI der Websocket-Schnittstelle angegeben. Mit den optionalen Attributen username und password können, so notwendig, auch noch die Credentials übergeben werden.

Beispielsweise könnte das <pages>-Element so aussehen:

Code: Alles auswählen

 <pages backend="mqtt" backend-url="wss://timberwolf123.local:443/proxy/mqtt/ws" username="testUser" password="testPasswort" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" lib_version="9" design="pure" xsi:noNamespaceSchemaLocation="../visu_config.xsd">

In der Config selbst sind bei den <address>-Elementen die MQTT spezifischen Transforms zu benutzen: https://www.cometvisu.org/CometVisu/de/ ... .html#mqtt
Bei Werten in JSON-Strukturen gibt es hier nun ein neues Feature bei den Transforms: diese können für solche speziellen Fälle erweitert werden. So fügt beispielsweise dieser Code

Code: Alles auswählen

    <switch>
      <label>switch JSON</label>
      <address transform="MQTT:json:c.d" retain="true">mqtt/switch_js</address>
    </switch>

ein Switch hinzu, dass unter mqtt/switch_js ein JSON der Form {"c":{"d":"1"}} beschreibt, bzw. liest.
Das bedeutet, dass ein JSON in verschiedenen Widget durchaus mit seinen verschiedenen einzelnen Teilen verwendet werden kann.
Aber, was aktuell nicht geht, ist so ein JSON mit mehreren Werten gleichzeitig zu erzeugen.

[PeterB]

In der CometVisu muss nun nur in der Config-Datei im <pages>-Element mit dem Attribut backend="mqtt" der MQTT-Modus ausgewählt werden

Kann Ich dann nur mehr MQTT verwenden oder geht zeitgleich auch KNX?

LG

[blaubaerli]

Hallo Chris,

das hört sich ja super an, werde sehen, dass ich das kurzfristig teste.

Danke und beste Grüße
Jens

[StefanW]

Hi zusammen,

es wird noch ein Update des Reverse Proxy (und der Oberfläche) geben mit RC2, weil wir hier noch die Einstelloptionen überarbeiten (TLS Proxy oder nicht für Websockets).

lg

Stefan

[StefanW]

Hi Chris,

wunderbar.

Sollten wir für die CV mit MQTT eine eigene APP-Version haben? Z.B. eine die für MQTT parametriert ist und entsprechende Attribute ansteuern kann, so dass die Einstellungen über die Oberfläche des APP-Managers vorgenommen werden können?

lg

Stefan

[Chris M.]

In der CometVisu muss nun nur in der Config-Datei im <pages>-Element mit dem Attribut backend="mqtt" der MQTT-Modus ausgewählt werden

Kann Ich dann nur mehr MQTT verwenden oder geht zeitgleich auch KNX?

Es geht immer nur ein Backend. Also entweder KNX oder OpenHAB oder (nun neu) MQTT.

[Chris M.]

Sollten wir für die CV mit MQTT eine eigene APP-Version haben? Z.B. eine die für MQTT parametriert ist und entsprechende Attribute ansteuern kann, so dass die Einstellungen über die Oberfläche des APP-Managers vorgenommen werden können?

Letztendlich soll das in die App.

Aber dazu sollen/müssen die Informationen über das Backend (wie die URI unter der die Websockets zu erreichen sind) als Environment in der Docker-Container Config stehen (= Aufgabe der App) und von dort dann der CometVisu bereit gestellt werden (= noch nicht implementiert)

Hier sollte aber auch geklärt werden ob der Broker dann als App angeboten wird.

[StefanW]

Hi Chris,

Aber dazu sollen/müssen die Informationen über das Backend (wie die URI unter der die Websockets zu erreichen sind) als Environment in der Docker-Container Config stehen (= Aufgabe der App) und von dort dann der CometVisu bereit gestellt werden (= noch nicht implementiert)

Was können wir uns hier zeitlich von Eurer Seite vorstellen?

Weil wir wollten jetzt die Hauptversion V 3.x finishen und entweder machen wir das nun so und die "CV mit MQTT als APP" kommt später oder - wenn das ein übersichtlicher Zeitraum wäre - dann KÖNNTE man darüber NACHDENKEN, das noch in die V 3.x mit rein nehmen

Hier sollte aber auch geklärt werden ob der Broker dann als App angeboten wird.

Klar, das eine würde das andere nach sich ziehen

lg

Stefan

[Chris M.]

Aber dazu sollen/müssen die Informationen über das Backend (wie die URI unter der die Websockets zu erreichen sind) als Environment in der Docker-Container Config stehen (= Aufgabe der App) und von dort dann der CometVisu bereit gestellt werden (= noch nicht implementiert)

Was können wir uns hier zeitlich von Eurer Seite vorstellen?

Das wollte ich noch in die 0.12.0 bringen, dafür ist der Aufwand nicht so groß.

[StefanW]

Das wollte ich noch in die 0.12.0 bringen, dafür ist der Aufwand nicht so groß.

ok, sehr schön. Was schätzt Du, wie lange ihr noch in der RC Phase verbleibt, weil dann können wir zusehen, dass wir mit der 3.x auch die CV 0.12 voreinstellen bei den Apps.

MQTT dann womöglich mit einer Version danach, wobei sich diese dann nicht so ziehen muss. Es gibt nur viele Nutzer der Hauptversion 2.0 die sehnlichst die nächste Hauptversion erwarten.

lg

Stefan