Manche Geräte sprechen kein MQTT und werden es nie tun — sie sind nur über die Cloud ihres Herstellers erreichbar. Cloud2MQTT fragt diese Cloud ab, normalisiert die Werte und veröffentlicht sie retained auf deinem eigenen Broker. Befehle gehen denselben Weg in die Gegenrichtung.

Erstes Ziel sind Levoit-Luftreiniger über die VeSync-Cloud.

Was es kann

• Fragt die VeSync-Cloud in festem Takt ab und veröffentlicht jedes Gerät als ein retained JSON, dazu jeden Wert auf einem eigenen Topic
• Befehle über MQTT (cmnd/<eigenschaft>) — die Weboberfläche geht genau denselben Weg, einen zweiten gibt es nicht
• Nur, was das Modell kann: Die Brücke fragt jedes Gerät nach seinen Fähigkeiten. Felder, die ein Modell nicht hat, werden weggelassen und nicht als null geschickt
• Home-Assistant-Discovery, abschaltbar — und Abschalten entfernt die Entitäten wieder, statt Geister zu hinterlassen
• Topic-Export für EisBär SCADA V3/V4 — Kanal-CSV und Payload-Profil-XML
• Diagnosepaket: Bericht, Konfiguration ohne Zugangsdaten und Log in einem ZIP — Konto, Broker und Gerätenamen durch Platzhalter ersetzt
• Oberfläche deutsch und englisch, hell und dunkel

Die Topics

Alles liegt unter dem konfigurierten Basis-Topic und wird retained veröffentlicht:

cloud2mqtt/<gruppe>/<gerät>/state          ein vollständiges JSON je Gerät
cloud2mqtt/<gruppe>/<gerät>/status/<feld>  jeder Wert auf eigenem Topic
cloud2mqtt/<gruppe>/<gerät>/cmnd/<feld>    hierhin gehen Befehle
cloud2mqtt/status                          Verfügbarkeit (Last Will)
cloud2mqtt/health/cloud/state              online / degraded / offline

Befehle liegen mit Absicht in einem eigenen Zweig: So kann die eigene Statusmeldung der Brücke ihr nicht als Befehl zurückkommen.

Der Topic-Export spart das Abtippen — als allgemeines CSV oder für EisBär SCADA als Payload-XML samt Kanal-CSV. Daneben das Diagnosepaket: Bericht, Konfiguration ohne Zugangsdaten und Log, mit Platzhaltern statt deines Kontos, deiner Brokeradresse und deiner Gerätenamen.

Installation

services:
  cloud2mqtt:
    image: cheetahlab/cloud2mqtt:latest
    container_name: cloud2mqtt
    restart: unless-stopped
    ports:
      - "8088:8088"
    environment:
      TZ: Europe/Berlin
      CLOUD2MQTT_PASSWORD: "ein-gutes-passwort"
    volumes:
      - ./configdir:/config

Dann docker compose up -d und http://<host>:8088 öffnen. Ohne gesetztes Passwort gibt die Schnittstelle überhaupt keine Daten heraus — auch nicht an ein anderes Programm im selben Netz. Die Zeile darf verschwinden, sobald sie einmal gelaufen ist; das Passwort liegt dann als Hash im Datenordner.

Ein Detail, das auf der Synology sonst Zeit kostet: Eingehängt wird ein Verzeichnis, nicht die Konfigurationsdatei selbst. Die Oberfläche schreibt sie mit os.replace, und ein Umbenennen genau auf den Einhängepunkt einer Einzeldatei scheitert grundsätzlich — auf jedem Dateisystem, DSM eingeschlossen.

Wohin es spricht

Die Brücke hält deine VeSync-Zugangsdaten. Deshalb gehört klar gesagt, mit wem sie redet:

• der VeSync-Cloud, um Geräte zu lesen und Befehle zu senden
• deinem eigenen Broker, unter der Adresse, die du einträgst
• Docker Hub, und nur um die öffentliche Versionsliste zu lesen — abschaltbar

Sonst niemandem. Das Diagnosepaket verschickt sich nicht selbst; du lädst es herunter und entscheidest.

Cloud2MQTT spricht HTTP. Im eigenen Netz ist das in Ordnung; über das Internet gehört ein Reverse Proxy mit TLS davor, sonst reist das Passwort im Klartext.

Und eines gibt VeSync vor, nicht wir: Das Konto erlaubt meist eine aktive Sitzung. Das Abfragen kann die Handy-App abmelden, und die Handy-App die Brücke.

Aufbau

Ein Kern (MQTT, Abfrageschleife, Topics) plus austauschbare Adapter. Ein Adapter übersetzt ein Cloud-Gerät in ein zielneutrales Objekt, und der Kern weiss von keiner bestimmten Cloud. Eine weitere Hersteller-Cloud anzubinden heisst, einen neuen Adapter zu schreiben — der Kern bleibt unangetastet.

Wo es liegt

• Docker Hub — cheetahlab/cloud2mqtt
• Quelltext — github.com/CheetahLab/cloud2mqtt

Lizenz Apache-2.0.