MQTT => Topic Trees organisieren, wie macht ihr das?

[Rince]

Hi,

ich bin auf der Suche nach einer Art "best practice" für eine MQTT Implementation:
Habe ein Gebäude, in welchem die Lichter mit Arduino und Relais Board per Taster gesteuert werden. Nun soll ein Ethernetshield eine Verbindung zu fhem herstellen.


Wie organisiert ihr eure Topics?

In state soll der Arduino den Zustand reinschreiben, also publishen, die Teile mit set sollten zum subscriben sein, damit Befehle empfangen werden können.

Vorschlag 1:
Wohnhaus/1OG/Flur/Licht/state/
Wohnhaus/1OG/Flur/Licht/set/

Wohnhaus/1OG/Wohnzimmer/Licht/Decke/state/
Wohnhaus/1OG/Wohnzimmer/Licht/Decke/set/

Wohnhaus/1OG/Wohnzimmer/Licht/Wand/state/
Wohnhaus/1OG/Wohnzimmer/Licht/Wand/set/


Vorschlag 2
state/Wohnhaus/1OG/Flur/Licht/
set/Wohnhaus/1OG/Flur/Licht/

state/Wohnhaus/1OG/Wohnzimmer/Licht/Decke/
set/Wohnhaus/1OG/Wohnzimmer/Licht/Decke/

state/Wohnhaus/1OG/Wohnzimmer/Licht/Wand/
set/Wohnhaus/1OG/Wohnzimmer/Licht/Wand/


Wie macht ihr das denn so?
Und wenn in einem Raum mehrere Geräte gleicher Art (siehe oben mit den 2 Lichtern im Wohnzimmer) sind, wie dann?

[P.A.Trick]

Gute Frage ich bin noch am experimentieren. Als alter Unix Nutzer würde ich aber alles klein schreiben, vermindert die Fehlerhäufigkeit durch Vertipper.

Aber ich tendiere eher zu Vorschlag 1:

Code Auswählen Erweitern

<GESCHOSS>/<ZIMMER>/<GERÄT><FUNKTION>/state
<GESCHOSS>/<ZIMMER>/<GERÄT><FUNKTION>/set

[supernova1963]

Das Thema steht auch bei mir noch auf der Agenda.
Ich würde auch den Vorschlag 1 präferieren. Allerdings soll bei mir neben der Hausautomatisierung auch diverse Systemstatus, die nichts bzw. nur indirekt der Hausautomatisierung zuzurechnen sind und auch eine andere Struktur benötigen, in MQTT verfügbar sein. Demnach überlege ich noch eine Ebene, z.B. <THEMA>, davor einzusetzen. Damit hätte ich zusätzlich die Möglichkeit mehrere Häuser/Wohnungen zu identifizieren und z.B. die Themen Energiemessung, Systemüberwachung, ... mit einer bedarfsgerechten "Sub-Struktur" abzubilden.
Der Vorschlag von P.A.Trick auch das Gerät (den Sender/Empfänger) zu identifizieren ist imo je nach Ausbaustufe sehr wichtig.

Code Auswählen Erweitern


<THEMA>/<GESCHOSS>/<ZIMMER>/<GERÄT><FUNKTION>/state
<THEMA>/<GESCHOSS>/<ZIMMER>/<GERÄT><FUNKTION>/set


In der Pflichtlektüre zu FHEM befindet sich ein Link zur einem Vorschlag von Device-Namen (https://www.fischer-net.de/hausautomation/fhem/22-fhem-devicenamen.html).
Hat man dieses Schema in FHEM abgebildet, und FHEM ist das führende System, macht es vielleicht auch Sinn dieses auch in MQTT abzubilden:

Code Auswählen Erweitern


Prefix 1:  Beschreibt die Lokation im Gebäude / auf dem Grundstück
Prefix 2:  Beschreibt den Raum
Prefix 3:  Beschreibt den Typ des Senders / Empfängers
Name:      Der eigentliche Devicename
Postfix 1: Laufende Nummer oder weitere Zuordnung
Postfix 2: Weitere Zuordnung

<Prefix1>/<Prefix2>/<Prefix3>/<Name>/<Postfix1>/<Postfix2>/state
<Prefix1>/<Prefix2>/<Prefix3>/<Name>/<Postfix1>/<Postfix2>/set


Ich würde auch hier noch eine Ebene darüber einsetzen um andere Sub-Strukturen zu ermöglichen.
Letztendlich ist es für alle NICHT-"Genies-die-das-Chaos-überblicken", - wie mich -, wichtig, eine Struktur zu haben und konsequent zu nutzen.

Ich bin gespannt ob, es noch andere Gedanken dazu gibt,

Gernot

[Rince]

Ja...
Vorschlag 2 kann das schon auch
Hier wird ganz zu Anfang unterschieden in state und set

Vorschlag 1 sieht zumindest optisch eher nach fhem aus. 1 Gerät, dort einen state und ein set
Auch wenn es dennoch zwei völlig verschiedene Topics sind.

Was das <Thema> vorne weg betrifft, hm, ich denke es ist nicht nötig:

state/#/Temperatur

Sollte alle Topics finden, die vorne mit state losgehen und hinten mit Temperatur aufhören.
state/Kueche/Temperatur
state/Garten/Ostseite/Temperatur
state/Garten/Suedseite/Temperatur

So gesehen böte es sich an, keine eigenen Themen parallel zu entwerfen, weil nicht nötig.

Geht übrigens auch für Variante 1:
#/Temperatur/state

HausMuenchen/1_OG/Temperatur/state
HausNewYork/30_OG/Temperatur/state
HausMoskau/4_UG/FSB/Temperatur/sate


So gesehen, scheint es herzlich egal zu sein ob Variante 1 oder 2, ein eigenes Topic für <Themen> wie du es nennst, braucht es eher nicht wirklich.

Gut, meine Klasse kann jetzt Topics entgegen nehmen

Code Auswählen Erweitern

Taster taster_1(38, 22, "Wohnort/Wohnhaus/1_OG/Kueche/Licht/set", "Wohnort/Wohnhaus/1_OG/Kueche/Licht/state");
Inputport, Outputport, InputTopic, OutputTopic

=> Signal an Port 38 => Schaltet Port 22 => Published Status in Wohnort/Wohnhaus/1_OG/Kueche/Licht/state

[Rince]

Wenn es interessiert:
https://forum.fhem.de/index.php/topic,67672.msg605368.html#msg605368
Habe da mal den momentanen Code gepostet.

Ziel:
Eine 16x Relais Platine mit einem Arduino Mega und W5100 Ethernetshield mit 16 Tastereingängen zu schalten
Zusätzlich publishen des echten Zustandes der Relais (sind wg. Optokoppler invertiert)

Was noch nicht geht:
Topic subscriben und Schaltbefehle ausführen

[eisler]

Vorschlag 2 mit einem Prefix ist auch ok:

z.B.

ArduinoMega/state/Wohnhaus/1OG/Flur/Licht/
ArduinoMega/set/Wohnhaus/1OG/Flur/Licht/

ArduinoMega/state/Wohnhaus/1OG/Wohnzimmer/Licht/Decke/
ArduinoMega/set/Wohnhaus/1OG/Wohnzimmer/Licht/Decke/

ArduinoMega/state/Wohnhaus/1OG/Wohnzimmer/Licht/Wand/
ArduinoMega/set/Wohnhaus/1OG/Wohnzimmer/Licht/Wand/


Grüße
Stephan

[supernova1963]

Danke @RInce,  für die Gedanken und Tips.
Wenn es ausschliesslich um Hausautomation geht, gebe ich dir uneingeschränkt recht.
Mein MQTT soll jedoch, - unter Anderem -, auch die CPU Temperaturen, RAM und Festplattenspeicher-Auslastung, Status von Diensten ... von diversen zentralen Maschinen sammeln. Bei einer zentralen Heizung, einer Solaranlage und vergleichbaren Einrichtungen sehe ebenfalls nur einen stark eingeschränkten Maße die Notwendigkeit, diese mit einem Stockwerk oder Raum in einem Zusammenhang zu bringen. 

Wie auch immer ein Patentrezept für alle muss es ja nicht geben.

[Rince]

Nachdem ich viel gelesen habe:

Vorschlag 2 mit einem Prefix ist auch ok:

z.B.

ArduinoMega/state/Wohnhaus/1OG/Flur/Licht/
ArduinoMega/set/Wohnhaus/1OG/Flur/Licht/

ArduinoMega/state/Wohnhaus/1OG/Wohnzimmer/Licht/Decke/
ArduinoMega/set/Wohnhaus/1OG/Wohnzimmer/Licht/Decke/

ArduinoMega/state/Wohnhaus/1OG/Wohnzimmer/Licht/Wand/
ArduinoMega/set/Wohnhaus/1OG/Wohnzimmer/Licht/Wand/

Das ist die sinnvollste Möglichkeit.
Die # darf nur am Schluss verwendet werden. Das + steht immer für 1 Level.

+/state/#

Würde so den Zustand aller Geräte anzeigen. Jedenfalls wenn man das retained Flag gesetzt hat.

Für eine Wohnung / Haus allgemein also:

EindeutigeBezeichnungClient/set/...(dann z.B. wie in FHEM üblich)
EindeutigeBezeichnungClient/state/...(dann z.B. wie in FHEM üblich)

[slor]

btw, das geht mit den Sonoff Geräten und der Tasmota firmware nicht, da im Topic keine / zugelassen werden.