Um es einfach auszudrücken, mein Sensor sendet mit einem Topic (z. B. « dsmr/reading/phase_currently_delivered_l3 ») und Gladys erlaubt mir nur, auf einem automatisch generierten und nicht änderbaren Topic zu hören (z. B. « gladys/master/device/mqtt:consommation_instantanee/feature/mqtt:consommation_instantanee/state »)
Fazit: Um etwas ‹ Einfaches › zu tun, muss ich über Node-RED gehen, um die Information von einem Topic zu einem anderen zu übertragen.
Wäre es also möglich, einen Mapper zu erstellen, um diese Lücke zu schließen? Oder das von Gladys erstellte Topic bearbeitbar zu machen?
Danke für die Anfrage, ich habe den Titel bearbeitet, damit es klarer ist.
Für mich gibt es zwei Möglichkeiten mit ihren Vor- und Nachteilen:
Das über Szenen machen, mit einem Trigger „Wenn eine MQTT-Nachricht empfangen wird“, der als Parameter ein MQTT-Topic und ein Beispiel einer empfangenen Nachricht nimmt. Anschließend wird in der Szene eine Variable injiziert, die überall nutzbar ist (Telegramm-Nachricht senden, Zustand eines Sensors festlegen, etc.). Der Vorteil ist, dass es unendlich anpassbar ist, der Nachteil ist, dass man eine Szene pro Sensor erstellen muss, was mühsam sein kann.
Das direkt in der MQTT-Integration machen, über ein „benutzerdefiniertes“ Topic, das anpassbar ist. Der Vorteil ist, dass es einfach in der Bedienung ist, der Nachteil ist, dass es überhaupt nicht anpassbar ist (wenn die MQTT-Nachricht ein spezifisches Format hat, wie geht man dann vor?)
Es ist wahr, wie ich bereits erwähnt habe, dass dies eine Einschränkung bei festen oder begrenzten Publish- oder Subscribe-Funktionen auf bestimmten Geräten darstellt. Es bleibt abzuwarten, ob es in Gladys möglich ist, die Funktionsweise eines Objekts (Schalter, Ein-/Ausschaltlampe usw.) einem anpassbaren Subscribe oder Publish zuzuweisen, anstatt die etwas umständliche aktuelle Syntax zu verwenden (das « mqtt: » im Namen der Subscribe- oder Publish-Funktionen ist unnötig). Das wäre ein Pluspunkt, da es derzeit eine nicht logische Einschränkung im Vergleich zur MQTT-Funktionsweise darstellt.
Super, ich denke, dieser Zusatz kann dabei helfen, verschiedene Sensoren einfach zu integrieren.
In Bezug auf die Benutzeroberfläche hätte ich mir einen Schalter auf Geräteebene vorgestellt, um festzulegen, ob der Payload vom Typ JSON oder „Sub-Topic“ ist, und eventuell das übergeordnete Topic zu definieren. Anschließend auf Funktionsebene den JSON-Pfad oder das Sub-Topic definieren (ich bin mir nicht sicher, ob die Kombination beider gleichzeitig notwendig ist).
Es gibt noch Arbeit, denn aktuell unterstützt die MQTT-Integration nicht das mehrfache Hören auf ein und dasselbe Thema, was die Verwendung eines Themas für mehrere Funktionen verhindern würde, was in diesem Fall problematisch ist
Ich weiß nicht, das könnte jede Funktion in der Länge verlängern (und sie ist schon lang)
Ach, ich hatte nicht verstanden, dass du auf Geräteebene sprichst!
Keine Ahnung, am besten wäre es, wenn es so einfach wie möglich wäre, nichts zu aktivieren, einfach nur auszufüllen, wenn der Nutzer es verwenden möchte.
Ich sehe Vor- und Nachteile bei beiden Optionen, ehrlich gesagt
Auf der einen Seite enthält das MQTT-Thema für Geräte oft eine eindeutige ID (die Seriennummer des Geräts oder dessen MAC-Adresse), daher erschien es mir einfacher, dies einmal auf Geräteebene zu definieren. Allerdings wirkt sich dies stärker auf die Schnittstelle aus.
Auf der anderen Seite bietet es mehr Flexibilität, das vollständige Thema jedes Mal zu spezifizieren, und belastet die Schnittstelle weniger. Allerdings erfordert dies ein „JSON-Pfad“-Feld, das verwirrend sein kann, wenn die Metriken „flach“ gesendet werden.
Ich habe die Funktion fertiggestellt und füge gerade einen „Debug MQTT“-Reiter hinzu, mit dem man leichter verstehen kann, was auf der Instanz passiert:
Ich habe es gerade getestet, es funktioniert für ein Gerät, das mit einem Topic/Metrik postet. Allerdings funktioniert bei einem Gerät, das verschiedene Metriken innerhalb eines JSON postet, nur die erste „Funktionalität“, die zweite, die auf demselben Topic, aber mit einem anderen JSON-Pfad konfiguriert ist, erfasst keine Daten. Beispiel für Daten:
Zum Schluss hatte ich das nicht mehr im Kopf, als ich das erwartete Verhalten definiert habe, aber es ist klar, dass das Ausfüllen der externen ID ziemlich umständlich ist; es wäre gut, einen standardmäßig generierten Wert zu haben, wenn das Feld bei MQTT leer gelassen wird.
Ich denke, es gibt ein UI-Bug, wenn man diese Werte bei der Erstellung des MQTT-Geräts ausfüllt, aber beim Bearbeiten funktioniert es sehr gut… Danke für das Feedback, ich werde daran arbeiten und melde mich wieder bei dir
Allerdings habe ich den Fall getestet, mehrere Metriken im selben JSON zu haben, und das funktioniert gut:
Ja, warum nicht. Ich mag die Logik von Netbox für die Definition der Slugs. Im Grunde, wenn das Feld nicht ausgefüllt ist, definiert es dies auf der Grundlage des Namens, den es „URL-sicher“ macht.
