[PATCH] Devspec und mqtt-bridge.

[blecher-at]

Dieser patch ermöglicht es, eine devspec (https://fhem.de/commandref_DE.html#devspec) bei der definition der MQTT_BRIDGE zu nutzen. Das vereinfacht das konfigurieren vieler devices die alle über MQTT erreichbar sein sollen, und sorgt bei mir für eine viel aufgeräumtere konfiguration.

Beispiel

Code Auswählen Erweitern


define MQTT_BRIDGE_OFFICE MQTT_BRIDGE OFFICE_LIGHT_.*
attr MQTT_BRIDGE_OFFICE IODev MQTT
attr MQTT_BRIDGE_OFFICE publish-topic-base PROX2/+/
attr MQTT_BRIDGE_OFFICE publishState PROX2/+/state
attr MQTT_BRIDGE_OFFICE room MQTT
attr MQTT_BRIDGE_OFFICE stateFormat transmission-state
attr MQTT_BRIDGE_OFFICE subscribeSet PROX2/+/state/set


"+" wird vom modul dann beim publish/subscribe automatisch durch das entsprechende gerät ersetzt.

Das Gegenstück wäre dann ein "autocreate" feature für MQTT_DEVICE. Hier felht es mir aber noch an der richtigen idee wie das umzusetzen wäre.

[blecher-at]

Hab den Patch nochmal aufgeräumt nachdem ich nachgelesen habe dass NOTIFYDEV devspec unterstützt.

[hexenmeister]

... Vortsetzung der Diskussion von hier: https://forum.fhem.de/index.php/topic,81418.msg737597.html#msg737597
Ich finde schon, dass dieser Patch die uhrsprüngliche Funktionalität des Moduls sehr stark verändert, er stellt diese sogar quasi auf den Kopf. Das Bridge-Modul war ja als eine Abstraktion konzipiert, eine Trennung zw. den konkreten FHEM-Geräten und den abstrakten Aktionen und Werten, die durch die Topics definiert werden. Das bedeutet, dass die Namen der FHEM-Gräte extra außen vor gelassen wurden, Dein Patch bringt sie aber wieder zurück. Daher gehört diese Funktionalität mMn nicht in das Modul rein. Bei einem Extra-Modul wird Dir natürlich keiner was für oder gegen sagen.

Was meine ich mit 'Schichtentrennung' und warum das ganze?
Das Modul erlaubt eine Art "Hardware Abstraction Layer" zu definieren, wo einzelne phisikalische Geräte mit ihren ganzen verschiedenen Eigenschaften für die oberen, abstrakteren Schichten verborgen bleiben. Es soll dort keinen Unterschied machen, ob ein Gerät ein Mehrkanal-Relaismodul ist, oder mehrere Einzelgeräte. Dort existieren "Deckenlampe" und "Garagenlicht", die an oder aus sind (ode reben gedimmt). Es soll aber egal sein, mit welcher Technik und wo, sie tatsächlich geschaltet werden. Auch viele technischen Readings (s. z.B. HomeMatic) sollen nicht wirklich weiter per MQTT übertragen werden. Damit kann dann business logic frei von Eigenschaften von HomeMatic oder EnOcean sein, sie regelt nur das Wesentliche, also ob die Lichter (Heizung, Belüftung etc.) eingeschltet werden, wann, für wie lange und unter welchen Bedingungen. Diese Logik soll auch unverändert bleiben können, wenn ein Aktor durch einen anderen ersetzt wird (werden muss).

[blecher-at]

Der patch ändert die Funktionalität nicht, nur wenn ich eine devspec angebe (was zuvor nicht möglich war), wird der gerätename in das topic hineingeneriert.
Ein eigenes Modul macht aus meiner Sicht keinen sinn weil der code zu 99% gleich ist und abwärtskompatibel, und gebe ich eine devspec in der definition an, so ist offensichtlich die intention hier mehrere gleichartige geräte auch gleich zu übertragen, das ging ja vorher garnicht. Wer das feature nicht will kann auch weiterhin pro gerät eine bridge erstellen.

Die Bridge verwendet bereits in der Originalversion als default (wenn du kein Topic angibst) den Gerätenamen als topic, es funktionierte nur wegen einem tippfehler in der programmierung nicht.

FHEM macht ja bereits die Abstraktion von hardware-Gerät (z.b. zwave id) zu einem virtuellen namen. Eine weitere abstraktionsschicht ist mmn deswegen nicht unbedingt notwendig, bzw. sehe ich diese nur in Ausnahmefällen angebracht. Ich habe schon oft hersteller gewechselt, der gerätename in FHEM blieb aber gleich (z.b. Deckenlampe). Für die weitere abstraktion der Geräte in FHEM gibt es ja bereits dummys, readinggroups und hunterte andere module mehr; diese funktionalität über ein Protokollmodul wie MQTT zu machen läuft ein wenig der "separation of concerns" entgegen.
Aber das ist mein Setup/Sichtweise... Je mehr Möglichkeiten es gibt, deßto besser für die fhem Plattform

[hexenmeister]

Wir verstehen offensichtlich separation of concerns grundlegend anders