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

[OstfrieseUnterwegs]

@hydrotec
Bei den Adaptern könntest Du vlt auf den prinzipiellen Unterschied hinweisen:
Es gibt spezielle Adapter, wie z.B. den Sonoff (Tasmota) Adapter. Er kommuniziert zwar über MQTT mit den Geräten, aber nur, wenn diese ihre Payload auch im Tasmota-Standard (keine Ahnung, ob das das der richtige Begriff ist) aufbauen. Der Vorteil ist, dass diese Adapter die Payload, die im JSON Format vorliegt, in Attribute zerlegen und automatisch entsprechende Datenpunkte in ioBroker anlegen. Der Nachteil ist, dass man bei den einbindbaren Geräten eingeschränkt ist.
Die beiden nativen MQTT Adapter (Client/Broker, Client) sind prinzipiell vollkommen offen, was die Struktur und Art der Payload angeht. Der Nachteil ist, dass der Anwender eventuell weitere Verarbeitungsschritte selbst einfügen muss um in ioBroker einzelne Datenpunkte für Attribute anzulegen.

[hydrotec]

@ostfrieseunterwegs

Danke für deine Anregung.
Bei dem Thema "Adapter" innerhalb der Doku bin ich noch nicht fertig.
Bin dran ;-)

[Homoran]

@ostfrieseunterwegs sagte in [Doku] Themensammlung zu MQTT allgemein:

Es gibt spezielle Adapter, wie z.B. den Sonoff (Tasmota) Adapter. Er kommuniziert zwar über MQTT mit den Geräten, aber nur, wenn diese ihre Payload auch im Tasmota-Standard (keine Ahnung, ob das das der richtige Begriff ist) aufbauen.

ich bin da der Meinung, man sollte nur auf diese Adapter hinweisen, dass sie intern mit MQTT arbeiten und deswegen auf doppelte Portbelegung geachtet werden muss

@hydrotec
Also im Prinzip Punkt 1 und 2 nach unten schieben und 3/4 als echte MQTT-Adapter beschreiben. Ich weiß, dein Screenshot sortiert es anders

[Asgothian]

@homoran sagte in [Doku] Themensammlung zu MQTT allgemein:

ich bin da der Meinung, man sollte nur auf diese Adapter hinweisen, dass sie intern mit MQTT arbeiten und deswegen auf doppelte Portbelegung geachtet werden muss

Dieses sehe ich auch so. Das bestimmte Adapter intern mit einem Protokoll arbeiten welches auch von anderen genutzt ist sollte nicht dazu führen das man darauf im Detail eingeht. Das ist am Ende für die Nutzer nicht relevant.

[hydrotec]

@hydrotec sagte in [Doku] Themensammlung zu MQTT allgemein:

@mickym sagte in MQTT Broker/Client Adapter:

Wenn Du alle Adapter raussuchst, die MQTT sprechen, ist das ggf. gefährlich.

Das ist, zumindest bis jetzt, nicht der Plan.
Wenn ich alle Adapter in Betracht ziehe, welche auch nur in geringster Form mit dem MQTT-Protokoll zu tun haben,
würde es meiner Meinung nach, den Rahmen einer allgemeinen Dokumentation sprengen.
In der Doku werde ich unter den Adaptern nur diejenigen erwähnen,
welche über den Filter "MQTT" auf der Admin Oberfläche gefunden werden.

Mein aktueller Plan sieht eine detailierte Beschreibung eines Adapters nicht vor.
Ich werde lediglich den Adapter "MQTT Broker/Client" dazu verwenden um die jeweilige Möglichkeit (Broker/Client),
wie sie in ioBroker machbar ist, aufzuzeigen.
Details gehören meiner Meinung nach in die Adapter-Beschreibung.

@homoran sagte in [Doku] Themensammlung zu MQTT allgemein:

Also im Prinzip Punkt 1 und 2 nach unten schieben und 3/4 als echte MQTT-Adapter beschreiben.

Das ist nur eine Aufzählung der Adapter, welche unter dem Stichwort "MQTT" als Filter auf der Admin-Oberfläche gefunden werden. Ich glaube nicht das es einen Unterschied macht, an welcher Position welcher Adapter erwähnt wird.
Sie werden nicht ausführlich beschrieben, und an einer Hilfestellung/Entscheidungsmatrix bin ich noch am überlegen wie ich das allgemein umsetzen kann. Wenn jemand vorhat ein Tutorial zu bestimmten MQTT Adaptern zu erstellen, nur zu, nehm ich gerne als Hinweis in die allgemeine Dokumentation mit auf.

[Homoran]

@hydrotec sagte in [Doku] Themensammlung zu MQTT allgemein:

Mein aktueller Plan sieht eine detailierte Beschreibung eines Adapters nicht vor.

dann stellt sich natürlich wieder die anfängliche Frage, was das für ein Werk wird.
Es gibt im Moment Adapterreferenz, da wird nur ein Adapter beschrieben. die Doku muss in das Adapterrepo, oder Tutorial. Da habe ich aber überhaupt keinen Schimmer wie tief man da reingehen soll und muss, ohne einen Einsteiger, der sich anhand des Tut für eine Installation da entlang hangelt, abzuhängen

Weitere Elemente der Doku wären noch eine FAQ oder das Glossar.
Für letzteres wird es definitiv zu viel Inhalt, für FAQ IMHO auch

[hydrotec]

@homoran sagte in [Doku] Themensammlung zu MQTT allgemein:

dann stellt sich natürlich wieder die anfängliche Frage, was das für ein Werk wird.

So wie es anfänglich gedacht war, eine allgemeine Dokumentation zu MQTT.
Wenn es eine Hilfestellung für Einsteiger sein soll, in welcher sie durch einen Konfigurationsprozess geleitet werden, dann ist es in einem Tutorial, oder Ähnlichem, besser aufgehoben. Die Erwähnung eines solchen Tutorial in der allgemeinen Dokumentation ist sinvoll, und eigentlich auch so geplant.

[Homoran]

@hydrotec sagte in [Doku] Themensammlung zu MQTT allgemein:

eine allgemeine Dokumentation zu MQTT.

das Thema hatten wir bereits im Chat.
Ich weiß nicht was du darunter verstehst.

Aber ich fürchte so eine Kategorie gibt es nicht.
Ich wüsste nicht, wo ich so etwas unterbringen soll.

[hydrotec]

Das Thema wurde auch in einem anderen Thread besprochen, nur eine Lösung wurde noch nicht gefunden.

@apollon77 sagte in Grundidee der Themenausrichtung der Doku:

@ostfrieseunterwegs sagte in Grundidee der Themenausrichtung der Doku:

@apollon77 Genau, herstellerübergreifende Standards und Protokolle: mqtt, zigbee, z-wave, knx, ... und wie diese sich integrieren kurz beschreiben und dann die Details bei den einzelnen Adaptern.

So eine Seite haben wir noch nicht...müsste man mal überlegen wo man das in die Struktur einsortiert, aber ja könnte für Interessenten vor allem interessant sein ...

@homoran sagte in Grundidee der Themenausrichtung der Doku:

@apollon77 sagte in Grundidee der Themenausrichtung der Doku:

Am Ende ist die "Logik und Automatisierung"-Startseite genau so ein Bereich. Hier sollten Abschnitte sein über "Scenes", "JavaScript" mit den Regelformen Rules, Blockly, Skripte und am Ende auch Node-Red.

Genau - da passt dann z.B. node-red hinein.

Aber diese Diskussion hatten wir bei Zigbee und jetzt bei MQTT - also Protokolle
Ich muss mir nochmal die "Struktur hinter der Doku" ansehen, ob da nicht auch schon was geplant war, oder ob das nur eine Kategorie bei den Adaptern geworden ist

@apollon77 sagte in Grundidee der Themenausrichtung der Doku:

@homoran "IoT Technologien und Protokolle" :-))

---

@homoran sagte in [Doku] Themensammlung zu MQTT allgemein:

Ich weiß nicht was du darunter verstehst.

Eine allgemeine Dokumentation, und nicht auf einen oder zwei Adapter abgestimmte.
So grob kann man das auch in meiner bisher erstellten Doku erkennen.

[Homoran]

@hydrotec sagte in [Doku] Themensammlung zu MQTT allgemein:

Eine allgemeine Dokumentation, und nicht auf einen oder zwei Adapter abgestimmte.
So grob kann man das auch in meiner bisher erstellten Doku erkennen.

Das Schlimme an deinem Entwurf ist ja, dass er gut ist :-)

Eine Entscheidungshilfe was ein Interessierter User für seine Fragestellung nehmen soll wäre wohl der Ansatz.
Aber er passt nicht zu Logik (wie node-red)
und ob ein weiterer Menüpunkt Protokolle, ganz abgesehen davon, ob der Punkt noch eingeschoben werden kann, einem Interessierten oder Einsteiger wirklich etwas sagt, bleibt dahingestellt.
Was außer MQTT sollte dann da noch drunter fallen?

BTW: ich weiß auch nicht, warum die bisherigen Änderungen an der Menüstruktur immer noch nicht greifen :-(

[hydrotec]

@homoran sagte in [Doku] Themensammlung zu MQTT allgemein:

Das Schlimme an deinem Entwurf ist ja, dass er gut ist

Dankeschön :-)

Ich habe für mich auf GitHub entschieden, das unter dem Menüpunkt "Technologie -> Kommunikation" solche allgemeinen Dokumentationen sehr gut aufgehoben sind. Da würden dann auch so Themen wie Zigbee, Z-Wave, usw. gut rein passen.
Wie das Menü letztendlich aussehen soll müsst ihr im Core-Team entscheiden, da will ich mich nicht einmischen.

@homoran sagte in [Doku] Themensammlung zu MQTT allgemein:

BTW: ich weiß auch nicht, warum die bisherigen Änderungen an der Menüstruktur immer noch nicht greifen

Da kann ich dir nur etwas Trost spenden, doch wirklich helfen nicht. ;-)

EDIT: Der Interessierte kann über die Suchfunktion in der Doku etwas zu MQTT finden.

[apollon77]

@homoran sagte in [Doku] Themensammlung zu MQTT allgemein:

Was außer MQTT sollte dann da noch drunter fallen?

ja nicht ganz so simpel ... aus gegebenem anlass könnte man noch "Websockets" und "HTTP" dazu nehmen wenn man nicht auf MQTT-"Flavours" will

[Homoran]

@hydrotec sagte in [Doku] Themensammlung zu MQTT allgemein:

das unter dem Menüpunkt "Technologie -> Kommunikation" solche allgemeinen Dokumentationen sehr gut aufgehoben sind. Da würden dann auch so Themen wie Zigbee, Z-Wave, usw. gut rein passen.

wo ist der denn?

[hydrotec]

@homoran sagte in [Doku] Themensammlung zu MQTT allgemein:

wo ist der denn?

Bei meiner Ordnerstruktur auf GitHub, nicht in der offiziellen Doku.

[Homoran]

@hydrotec sagte in [Doku] Themensammlung zu MQTT allgemein:

Bei meiner Ordnerstruktur auf GitHub, nicht in der offiziellen Doku.

:joy:

[hydrotec]

Update:
Den Bereich Adapter in der Doku fertig gestellt.

[hydrotec]

Hallo zusammen,

ich bräuchte noch einmal eine allgemeine Unterstützung von euch.
Es dreht sich um Punkt 1.) unter Issues in der jetzigen Fassung der Doku zu MQTT.
Wenn ich diese Schritte nacheinander durchführe, ändert sich bei mir nichts, und ich kann keine Datenpunkte unter mqtt.0.* erstellen. Seither hatte ich einen anderen Weg genommen, um unter mqtt.0.* eigene Datenpunkte anzulegen.

Liegt es eventuell an dem aktuellen admin v5.3.0, bzw. js-controller v4.*, auf meiner Testumgebung?
Kann das jemand bestätigen oder dementieren?

Systeminfo

{
 "hosts": [
   {
     "version": "4.0.6",
     "platform": "Javascript/Node.js",
     "type": "linux"
   }
 ],
 "node": "v14.19.0",
 "arch": "x64",
 "adapters": {
   "mqtt": {
     "version": "2.4.0",
     "platform": "Javascript/Node.js"
   },
   "javascript": {
     "version": "5.2.13",
     "platform": "Javascript/Node.js"
   },
   "admin": {
     "version": "5.3.0",
     "platform": "Javascript/Node.js"
   }
 },
 "statesType": "redis",
 "objectsType": "redis",
 "noInstances": 7,
 "compactMode": false,
 "noCompactInstances": 0,
 "model": "AMD Ryzen 5 PRO 3400G with Radeon Vega Graphics",
 "cpus": 8,
 "mem": 31550902272,
 "ostype": "Linux",
}

Vorab schon einmal Danke für eure Unterstützung.
Gruß, Karsten

[apollon77]

@hydrotec der aktuelle Admin sollte an sich erlauben im expertenmodus eigene States anzulegen.

[hydrotec]

@apollon77
Dankeschön für den Hinweis :+1:

Eben schnell ausprobiert, das ist jetzt sehr gut, und einfach, gelöst. :-)

Gruß, Karsten

Edit:

Muss doch noch einmal kurz nachhaken.
In der Adminversion <5.3.0 ist der von mir beschriebene Weg noch gültig, bzw. funktionabel?

[apollon77]

@hydrotec sagte in [Doku] Themensammlung zu MQTT allgemein:

In der Adminversion <5.3.0 ist der von mir beschriebene Weg noch gültig, bzw. funktionabel?

Geht seit 5.2.1