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

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

[mickym]

@PackElend sagte in MQTT oder MQTT-Client:

Wenn ich Eclipse Mosquitto als MQTT Broker einsetzte, warum brauche ich noch den MQTT server and client?

Na Du brauchst ja wenigstens einen MQTT Client, um mit Deinem MQTT Broker (also z.Bsp. mosquitto) zu kommunizieren. Falls Du keinen Adapter nutzt, kann zum Beispiel auch NodeRed - bzw. der NodeRed Adapter mit Deinem Broker direkt arbeiten und muss nicht über den MQTT Adapter laufen. Blockly braucht aber immer den Adapter.

@PackElend sagte in MQTT oder MQTT-Client:

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.

Normalerweise funktioniert MQTT so, dass es EINE Nachricht an EINEN Client sendet und dann ist die Nachhricht ungültig bzw. nicht mehr existent (außer Du sendest eine Nachricht mit dem retain Flag - dann wird die Nachricht jedesmal bei Wiederverbinden gesendet).
Der iobroker Adapter behält aber in seiner Datenbank den letzten empfangenen Status. Man kann damit also auf einen Blick sehhen, was war die letzte Status - aber zum steuern muss man die Nachrichten immer wieder schicken.

@PackElend sagte in MQTT oder MQTT-Client:

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

Ein Taster arbeitet nur mit einem Triggersignal und das ist dann immer true. - Den Status eines Gerätes über einen Taster ist immer ein anderes Topic, dass das Gerät dann von sich aus sendet. Deswegen triggert man immer mit true - egal ob Du mit dem Taster ein- oder ausschaltest.

@PackElend sagte in MQTT oder MQTT-Client:

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

Ja so mache ich das - man braucht keinen Explorer

@PackElend sagte in MQTT oder MQTT-Client:

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?

Du kannst das machen wie Du willst. Die meisten Geräte bieten ja an unter welchem Topic sie etwas veröffentlichen. Wenn Du die Topics entsprechend frei wählst, dann brauchst Du den Alias eigentlich nicht, weil Du dann ja nicht mit Gerätenamen arbeitest.
Den Alias kannst Du dann verwendet, wenn Du zum Beispiel aus einem JSON einzelne Werte als einzelne Datenpunkte verfügbar haben willst. Wenn Du allerdings dann über Deine Logikmaschine (NodeRed, JS oder Blockly) weitere Steuerungen vornimmst, dann kann man die auch in dem Script oder dem Flow direkt referenzieren.