Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[MartyBr]

@mickym @Marc-Berg
Ihr macht es mir wirklich schwer :thinking_face:

Bei mir geht es um zwei Werte vom Stromzähler und 10 Werte Temperatursensoren (CuXD).

Ich schalte testweise mal den MQTT-Client an und schaue, ob ich hier weiterkomme.

[mickym]

@martybr Was ist denn schwe daran. Mit dem MQTT-Client kannst Du über das Zahnrad einzelne States publishen. Den anderen Adapter kannst Du als Spiegel nehmen vom Mosquitto nehmen - musst Du aber nicht.

Im mqtt-client gibst Du nur Deinen Broker ein in den Adaptereinstellungen:

Ansonsten kannst Du mit dem Zahnrad mit dem mqtt-Client viel feiner steuern:

Das topic flexibel gestalten, nur Änderungen publishen wenn Du willst - definieren, ob Du publishen oder subscriben willst (beides würde ich Dir nicht empfehlen ;) - habs aber noch nicht ausprobiert, ob das dann mit dem ACK Flag funktioniert).

[MartyBr]

@mickym
Ich habe das mal so eingetragen, nun werden auch die Werte angezeigt:

[mickym]

@martybr Wie gesagt ich würde NICHT beides ankreuzen - sundern nur publishen - oder erhälst Du Deine Werte über mqtt? - Wenn nicht, dann mach den Haken weg.

[MartyBr]

@mickym
Bisher sah das sauber aus. Ich schalte mal einen DP auf deine vorgeschlagene Einstellung.

[MartyBr]

@mickym Eine Frage noch: Die Temperaturwerte bekomme ich über den MQTT. Soll ich hier "abonnieren" anklicken?

[mickym]

@martybr Ja wenn Du die über Deinen Broker bekommst, dann wird das abonnierte topic in den Datenpunkt geschrieben. Dann musst Du aber halt das topic so ändern, dass es dem topic entspricht unter dem es veröffentlicht wird.

[MartyBr]

@mickym
Verstanden. Mach ich sofort.

[MartyBr]

@martybr
So, hier die Einstellung:

Hier Mosquitto:

Habe ich das richtig eingestellt?

[paul53]

@martybr sagte: Die Temperaturwerte bekomme ich über den MQTT.

Nicht über den HM-RPC-Adapter?
Es sind CCU-typische Geräte-IDs.

[mickym]

@martybr ja

[MartyBr]

@paul53 Ja, auch über den HM-RPC. Die CuXD-Geräte (EnOcean) sehe ich in der Homematic. Parallel transportiere ich sie über ccu-jack in den Mosquitto. Ich habe verschiedene Versuche gemacht, die EnOcean über den ioBroker einzubinden. Bei den Tastern hat das funktioniert, die EnOcean Rollos haben Probleme gemacht.
Die Einbindung auf der Homematic über CuXD war dort komfortabler (zumindest für mich :sunglasses: ).
das ist für mich ein Test/Versuch, viele Daten im MQTT zu konzentrieren.

[paul53]

@martybr sagte: Test/Versuch, viele Daten im MQTT zu konzentrieren.

Das ist ein Umweg gegenüber HM-RPC.

[MartyBr]

@mickym Eine Frage noch:
Ich betreibe EnOcean Rollos, der Daten auch im MQTT über ccu-jack gespeichert werden.
Bsp.

Das setzen der Datenpunkte funktioniert über den Set-Befehl:

Bisher steuere ich die Rollos über ein Script:

Muss ich hier sowohl "abonnieren" als auch subscriben" anklicken?

[MartyBr]

@paul53 Richtig. Aber wie gesagt ist das ein Test. Produktiv steuere ich über RPC.

[mickym]

@martybr Nein - wenn Du unterschiedliche topics zum setzen und zum Empfangen hast, dann musst Du einen Alias erstellen und dann kannst Du versuchen den sowohl zu publishen, als auch zu abonnieren.

[MartyBr]

@mickym Okay, dann mache ich mir mal Gedanken über das Vorgehen.

[Fraat]

Ich versuche seit Tagen CCU-Jack mit Iobroker zu verbinden. Bis jetzt werden alle Werte im IoBroker so dargestellt

{"ts":1711112812496,"v":false,"s":0}

Was muss ich ändern?

Das das sind meine Einstellungen: ccu-jack.cfg:
"Bridge": {
"Enable": true,
"Address": "xxxx",
"Port": 1885,
"BufferSize": 0,
"UseTLS": false,
"CACertFile": "",
"Insecure": false,
"Username": "xxxx",
"Password": "xxxxx",
"ClientID": "ccujack",
"CleanSession": true,
"Incoming": [
{
"Pattern": "+/set/#",
"LocalPrefix": "",
"RemotePrefix": "ccujack/",
"QoS": 0
},
{
"Pattern": "+/get/#",
"LocalPrefix": "",
"RemotePrefix": "ccujack/",
"QoS": 0
}
],
"Outgoing": [
{
"Pattern": "+/status/#",
"LocalPrefix": "",
"RemotePrefix": "ccujack/",
"QoS": 0
}
]
}
},

[mickym]

Wieso das ist doch gut - so hast Du alle Infos zusammen. Wenn Du einzelne Werte aus den Objekten haben möchtest, erstellst Du Dir einen Alias oder schreibst diese Werte in eigene Datenpunkte via Blockly, JS oder NodeRed.
Falls Du NodeRed nutzt - habe ich einen Flow - der Dir automatisch alles in einzelne Datenpunkte zerlegt. Aber meines Erachtens braucht es das nicht. Falls Du Dich für das automatische Erstellen in einzelne Punkte interessierst - hier der Thread mit der Anleitung:

https://forum.iobroker.net/topic/43856/json-oder-javascript-objekt-in-iobroker-datenpunkte-zerlegen

Wie Du an den Aufrufen siehst, hat er ja schon vielen geholfen.

Ansonsten wie Du einen einzelnen Wert in einem Alias extrahierst, habe ich hier im Detail beschrieben: https://forum.iobroker.net/post/980575

[PackElend]

Die letzte Antwort ist ein Weilchen her aber wenn man die Frage googelt, wann welcher Adapter, MQTT client oder MQTT server and client einzusetzen ist dies hier ganz oben auf der Liste.
Daher vielleicht nochmal zur eigentliche Frage im Titel.

Wenn ich Eclipse Mosquitto als MQTT Broker einsetzte, warum brauche ich noch den MQTT server and client?
Einzig was mir gerade einfällt sind:

• The ioBroker MQTT-Broker in server mode only simulates the behavior of real MQTT-Broker (like Mosquitto), but it is not the same. Real MQTT-Broker normally does not save the values of the topics and just forwards the message to other subscribed clients.

  Hier stellt sich mir dennoch die Frage, möchte ich das, wenn ich beispielsweise mit Taster arbeite ?

• @mickym sagte in MQTT oder MQTT-Client:

  Der Grund warum die meisten den anderen Adapter nutzen (ich auch) - weil sie mosquitto also Broker nutzen und dann den Client/Server Adapter als Spiegel.

• anstatt mit MQTT Explorer schauen, was alles verfügbar ist, den gesamten Broker spiegeln und nur im iobroker arbeiten

• um die evtl. sehr lange List von verfügbaren Clients des Brokers zu sortieren, in dem diese unterschiedlichen Instanzen des MQTT client zugeteilt werden, über spezifischen Subscribe von Topics. -
  -> aber warum ist hier nicht der erste Weg über ioBroker.alias-manager (ioBroker ALIAS Definitionen)zu gehen?

---

Ich habe mal copilot befragt, manches geht im meine Richtung aber auch nur manches:

Kurz gesagt:

• ioBroker.mqtt (offizieller „MQTT Broker/Client“-Adapter)
  → Kann Broker und Client sein. Gute „Allround“-Wahl, wenn du einen MQTT‑Broker in ioBroker betreiben willst oder dich als Client an einen externen Broker (z. B. Mosquitto) hängen möchtest. Der Adapter ist offiziell gepflegt und bekommt regelmäßig Updates. [github.com], [npmjs.com]

• ioBroker.mqtt-client (Community-Adapter)
  → Reiner Client zum Publish/Subscribe von ioBroker‑States an externe Broker. Besonderheit: feingranulare, pro‑State‑Konfiguration (Topic je Datenpunkt, Publish/Subscribe‑Prefixe, LWT, „on connect“/„on disconnect“‑Nachrichten, zusätzliche freie Subscriptions usw.). [github.com]

---

Was unterscheidet die beiden konkret?

Thema	ioBroker.mqtt (offiziell)	ioBroker.mqtt-client (Community)
Rolle	Broker oder Client (umschaltbar)	Nur Client (für externen Broker)
Use Case	Eigenen MQTT‑Broker in ioBroker bereitstellen oder als Client an einen Broker anbinden	ioBroker gezielt an bestehenden Broker (z. B. Mosquitto) anbinden, pro Datenpunkt sehr fein steuern
Feingranularität	Viele Optionen global in der Instanz (z. B. „Maske zum Bekanntgeben eigener States“, optional getrennte Topics für set/get)	Pro State im Zahnrad‑Menü konfigurierbar (Topic, Publish/Subscribe, Prefixe, u. a.)
Wartung/Aktivität	Offizielles Repo, regelmäßige Commits/Release auf npm	Community‑Repo, aktiv – Fokus auf State‑Mapping‑Features
Besonderheiten	Kann selbst als MQTT‑Broker dienen (inkl. WebSockets‑Port, SSL, Auth)	On‑connect/Last‑Will, freie subscriptions für Topics ohne vorhandene States, publish/subscribe‑Prefix

Quellen: Official README & npm (Broker/Client‑Funktionen, Settings), mqtt‑client README (State‑bezogene Optionen) [github.com], [npmjs.com], [github.com]

---

Wann setze ich welchen Adapter ein?

Nimm ioBroker.mqtt (offiziell), wenn …

1. du keinen externen Broker hast und schnell einen Broker in ioBroker bereitstellen willst. [github.com]
2. du „einfach“ MQTT brauchst (Anbinden, Topics empfangen/senden) ohne pro‑State‑Feintuning. [github.com]
3. dir offizielle Pflege & regelmäßige Releases wichtig sind. (Repo & npm zeigen laufende Pflege/Updates.) [github.com], [npmjs.com]

Nimm ioBroker.mqtt-client (Community), wenn …

1. du bereits einen externen Broker (z. B. Mosquitto) einsetzt und ioBroker nur als Client koppeln willst. [github.com]
2. du pro Datenpunkt genaue Kontrolle über Topic‑Namen, Publish/Subscribe‑Richtung, Prefixe etc. brauchst (z. B. für strukturierte Topic‑Hierarchien oder Sonderfälle). [github.com]
3. du Features wie Last‑Will, on‑connect/on‑disconnect‑Messages oder Zusatz‑Subscriptions (topics ohne vorab definierte States) gezielt nutzen willst. [github.com]

Community‑Feedback spiegelt das oft so wider: „mqtt‑client, wenn man nur Client braucht und pro State steuern will; der offizielle mqtt ist der ‚Universaladapter‘ inklusive Broker.“ [forum.iobroker.net], [forum.iobroker.net]

---

Praxis-Empfehlungen (aus Erfahrung & Community‑Best‑Practices)

1. Du betreibst Mosquitto oder einen anderen „richtigen“ Broker?
   → Kombination: Externer Broker + ioBroker.mqtt im Client‑Modus (für einfache Setups) oder mqtt-client (für pro‑State‑Feintuning). Viele Nutzer bevorzugen externen Broker + Client‑Adapter wegen Stabilität & Skalierung. [forum.iobroker.net]

2. Du willst schnell starten ohne Zusatz‑Komponenten?
   → ioBroker.mqtt als Server/Broker in ioBroker aktivieren. Später kannst du immer noch auf einen externen Broker migrieren. [github.com]

3. Du brauchst saubere, konsistente Topics und Mapping je Objekt (z. B. für Integrationen wie EV-Charger, Visualisierungen, Multi‑System‑MQTT)?
   → mqtt-client – dank per‑State‑Einstellungen behältst du die volle Kontrolle über Topic‑Namen & Richtungen (publish vs. subscribe). [github.com]

---

Beispiel-Szenarien

• Smart‑Home mit vielen Tasmota/Shelly‑Geräten, Broker läuft schon auf dem NAS (Mosquitto):
  → mqtt-client einsetzen, damit du je ioBroker‑State das Topic definieren und sauber zu bestehenden Topic‑Bäumen publishen kannst. [github.com]

• Kleines Lab/POC ohne bestehenden Broker:
  → ioBroker.mqtt als Broker starten; Clients (ESPHome, Tasmota, Test‑Tool) direkt verbinden. [github.com]

• Du willst beides: Empfang aller MQTT‑Topics + selektiv eigene ioBroker‑States veröffentlichen:
  → ioBroker.mqtt im Client‑Modus mit gezielter „Maske zum Bekanntgeben eigener States“ oder mqtt-client mit pro‑State‑Opt‑in. (Maske/Filter im offiziellen Adapter, pro‑State‑Schalter im mqtt‑client.) [npmjs.com], [github.com]

---

Wenn du magst, sag mir kurz, ob bei dir schon ein externer Broker (z. B. Mosquitto) läuft und wie wichtig dir das pro‑State‑Mapping ist. Dann skizziere ich dir eine konkrete Schritt‑für‑Schritt‑Konfig für deinen Aufbau in ioBroker (inkl. Beispiel‑Topics und sinnvollen Defaults).