Modul-Konzeption: Generic MQTT Bridge

Begonnen von hexenmeister, 21 Dezember 2017, 22:35:38

Vorheriges Thema - Nächstes Thema

Ma_Bo

Sehr interessantes Thema hier, bzw. Themen.
Ich nutze Node Red im Zusammenhang mit Google Home und zur Kommunikation mit FHEM nutze ich mqtt...

Nach den Weihnachtstagen teste ich Mal hexenmeister's Modul...

Mit Node Red die Visualisierung zu machen klingt interessant...


Tapatalk iPhone, daher kurz gehalten.
NUC mit FHEM, HM Heizungsthermostate, HM Wandthermostate, Intertechno Funksteckdosen, 10" Tablet als Wanddisplay, KeyMatic, Fensterkontakte, Fensterkontakte umgebaut als Wassermelder und Briefkastenmelder, Aussenthermostat, Anwesenheitssteuerung über Fritz Box, Google Home usw. usw.

hexenmeister

#16
Zitat von: AndreasR am 25 Dezember 2017, 11:13:20
Daher verstehe ich deinen Wunsch nach dem Stern * - vielleicht zaubert Hexenmeister ja einen rein .. 
* für alle Readings eines Gerätes habe ich (etwas widerwillig ;D ) eingbaut. Für eine Stern für "alle Geräte und alle Readings" sehen ich jedoch wirklich nicht.

Zitat von: Harst am 24 Dezember 2017, 18:24:35
Was spricht dagegen, alle fhem- Nachrichten zu mqtt zu übertragen? Mein Ziel wäre gerade, diese vielen Experten Definitionen von fhem nicht zu benötigen. GUI ist schöner und mit GUI meine ich nicht, im Webinterface zu programmieren.

Nach meinem Verständnis spricht einiges dagegen, ich möchte jedoch meine Meinung nicht als Absolute Wahrheit verkaufen, jeder hat seine Vorstellungen und eigenen Einsatzzweck.
Für mich stellt MQTT-Schicht einen neuen Abstractionslevel dar, der rein von technischen Details der unteren Schochten sein soll. Vlt. wird es an einem Beispiel deutlicher:
Bei mir laufen mehrere Gerätearten im Haus. So wurde die nachträgliche Installation per Funk mit HomeMatic realisiert (weil alles andere viel zu großen Aufwand verursacht hätte), beim Ausbau habe ich jedoch drahtgebundene Installation mit EnOcean (Eltako) gewäht. Also habe ich parallel HomeMatic und Eltako Rolladenaktoren am Werk. Dummerweise verhalten sich diese nicht gleich. EnOcean verwendet für Rolladenpostion (logischerweise) 'position'-Eigenschaft, HomeMatic besteht jedoch auf 'pct'. Dann zählen die Beiden die Prozentwerde jeweils andersrum. Ich rechne daher alles in FHEM zu einem gemeinsamen Nenner um und übertrage über MQTT die Namen und Werte (in beide Richtungen natrülich) gleichartig. So muss die drüber liegende Schicht nicht wissen, welche Art Aktor installiert ist. Für sie sind alle Rolladen (Lichter, Heizung, Sensoren,..) immer gleich.
Insgesamt ist MQTT für mich eine Integrationschicht. Für jeden Bus läuft eine eigen FHEM-Instanz (meiste davon parallel auf einem RPI3), eine Instanz für die Logik (MQTT - rein, MQTT - raus), eine für die Visualisierung. Das schöne daran, man kann auch was ganz anderes darüber einbinden, z.B. habe ich mit dem IOBrocker mit seiner fortgeschrittenen Visualisierung gespielt. Würde gut funktionieren, hatte aber Stabilitätsprobleme mit der damaligen IOBrocker-Version.
Lange Rede... ich denke, wenn man einfach alles wahlfrei nach außen trägt, dann entsteht ein verteilter Riesenmischmasch, den man nicht mehr Herr werden kann.

P.S. NodeRed werkelt hier auch noich dazwischen, wird für Szenenbildung und Alexa-Anbindung genutzt.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

dev0

ZitatLange Rede... ich denke, wenn man einfach alles wahlfrei nach außen trägt, dann entsteht ein verteilter Riesenmischmasch, den man nicht mehr Herr werden kann.
Ja und nein ;) jsonlist2 "exportiert" auch alles ohne weitere Parameter und es gibt kein Chaos ;) Das hängt einfach davon ab wie man es verarbeitet. Ich benutze MQTT zur Zeit nur sehr rudimentär, aber ein vollständiger Export hört sich (ohne tiefer darüber nachgedacht zu haben) erst einmal sehr interessant an um andere Systeme anbinden zu können.

hexenmeister

Auch mit json bleiben bei einer generischen Alles-Übertragung verschiedenen benannte Readings mit unterschiedlich interpretierten Werten. Immer noch eine monolitische Aufbau und keine saubere Integrationsschicht. Finde ich immer noch unbeherrschbar und sehe keine Vorteile.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

blecher-at

Etwas ähnliches habe ich vor ein paar wochen in das standardmodul integriert. https://forum.fhem.de/index.php/topic,81133.0.html

vor/nachteil (je nach Sichtweise) ist, dass die Topics nicht bei den Geräten konfiguriert werden sondern über Patterns auf der Bridge.
durch die devspec https://fhem.de/commandref_DE.html#devspec hat man mehr kontrolle darüber was exportiert wird. z.B. "room=kitchen" oder TYPE=FS20 oder reguläre ausdrücke

hexenmeister

#20
Habe ich gesehen. Aus meiner Sicht gehört das nicht in das Bridge-Modul, sondern ggf. in ein eigenes. Zu groß ist die Änderung der vorhandenen Funktionalität. Aber das ist natürlich meine Meinung.
Was Deine Lösung für mich unbrauchbar macht, ist die Tatsache, daß Gerätenamen in Topics verwendet werden. Genau das will ich ja mit der Schichtentrennung vermeiden. Weiterhin befürchte ich, dass bei mehreren Dutzenden von Geräten jegliche Übersicht flöten geht. Daher finde ich es auch besser an dem jeweiligen Gerät zu konfigurieren. Quasi an der Quelle. Und meine GenericBrigde ist dabei ein "define and forget"-Device.
Natürlich alles Frage der Sichtweise  :)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

P. S. Mache doch daraus ein neues Modul. Namensvorschlag: MQTT_GROUP
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

blecher-at

Mein Patch ändert eigentlich die Funktionalität garnicht, bringt das bridgemodul nur näher an den fhem standard, drum finde ich dafür ein eigenes modul overkill (und hätte viel duplicate code). Mal sehen :)

So wie ich MQTT nutze ist eigentlich als pseudo-Layer unterhalb von FHEM, also dort wo der globale eventloop angesiedelt ist. Damit kann man dann Geräte über mehere fhem instanzen verteilen und es ist egal wo das gerät läuft. Drum ist mir der name des mqtt topics egal weil mqtt ausschließlich von fhem genutzt wird. Bei deinem modul hab ich dasselbe Problem wie mit dem derzeitigen MQTT_BRIDGE: ich muss den gerätenamen 200x öfter in der config stehen haben, was zu fehlern und arbeit bei neuen geräten erzeugt, und will ihn eigentlich nur 1x definieren.
Finde es interessant wie unterschiedlich leute das naming machen ... warum muss in deinem Usecase der topicname unterschiedlich vom gerät sein?

Die Idee hinter deinem Modul erinnert mich an die von mir gestellte Anfängerfrage: warum definiere ich einen notify als eigenes Gerät und nicht einfach als Attribut am gerät "ontoggle". Ich denke mal modularisierung ist der Grund dafür.
Damit das ganze im FHEM gut funktioniert bräuchten aber mmn solche attribute einen prefix (z.b. attr DEVICE x-mqttGenericBridge-pubNames) damit es auf keinen fall mit nativen Attributen des gerätes selbst kollidiert. Das müsste mmn eine namenskonvention für modulentwickler sein die global gilt.

Um mehrere Usecases zu bedienen sollte dein mqttTopicPrefix attribut auch perlexpressions erlauben damit ich dann dort z.b. einfach den Gerätenamen oder ein bestimmtes attribut reinlegen kann.

Harst

Das * bei den Meldungen eines Gerätes scheint mir die Lösung für die Automatisierung zu sein. Also Ok. Sobald meine Installation wieder läuft teste ich das mal bei mir aus.
Alle zu übertragen war unüberlegt, denn viele Geräte sind sinnfrei. In der Oberfläche brauche ich die (echten) Schalter(Intertechno, FS20), nicht die Empfangshardware (CUL,SDuino)

Jetzt würde mir noch eine Liste der Geräte fehlen, die man dann als Basis in Node-Red verwursten kann.

Horst

hexenmeister

Zitat von: blecher-at am 27 Dezember 2017, 01:45:54
Mein Patch ändert eigentlich die Funktionalität garnicht, bringt das bridgemodul nur näher an den fhem standard,

FHEM-Standards sind so 'ne Sache... Es gibt zu viele davon, oder keine, wie mas's mag... ABer das wir hier ein wenig OT. Ich antworte in Deinem alten Thread weiter (https://forum.fhem.de/index.php/topic,81133.0.html).
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Zitat von: blecher-at am 27 Dezember 2017, 01:45:54
Finde es interessant wie unterschiedlich leute das naming machen ... warum muss in deinem Usecase der topicname unterschiedlich vom gerät sein?
Weil sie miteinander nichts zu tun haben. Vlt. sieht man das anhand eines Beispiels:
Gerätename (EnOcean, DImmer, Adresse 000018, installiert in der Unterverteilung in der Wohnzimmer auf dem Dachgeschoss): DG_WZ_DA_ENO_A18
Topic (Zustand): /ha/dg/wz/licht/seiten/level
Topic (zum Schalten): /ha/dg/wz/licht/seiten/set

Zitat von: blecher-at am 27 Dezember 2017, 01:45:54
Damit das ganze im FHEM gut funktioniert bräuchten aber mmn solche attribute einen prefix (z.b. attr DEVICE x-mqttGenericBridge-pubNames) damit es auf keinen fall mit nativen Attributen des gerätes selbst kollidiert. Das müsste mmn eine namenskonvention für modulentwickler sein die global gilt.
Prefix ist geplant und in Arbeit.

Zitat von: blecher-at am 27 Dezember 2017, 01:45:54
Um mehrere Usecases zu bedienen sollte dein mqttTopicPrefix attribut auch perlexpressions erlauben damit ich dann dort z.b. einfach den Gerätenamen oder ein bestimmtes attribut reinlegen kann.
Genau das finde ich nicht zielführend. Wozu soll das gut sein? (für den Namen des Geräts habe ich auf Wunsch dennoch eine Unterstützung eingebaut).
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

blecher-at

ZitatGerätename (EnOcean, DImmer, Adresse 000018, installiert in der Unterverteilung in der Wohnzimmer auf dem Dachgeschoss): DG_WZ_DA_ENO_A18
Das ist aus meiner Sicht unnötig kompliziert. Hersteller und Adresse haben im Gerätenamen nichts verloren, das steht ohnehin in der definition.
Was spricht dagegen, dein Gerät einfach "DG_WZ_Licht" zu nennen?

hexenmeister

Was bringt mir das? In den Listen der Geräte ist mir wichtiger zu sehen, wo sie installiert sind und welche Technik dahinter steckt. Wenn ich einen Aktor ersetzen muss, nehme ich den nächten freien aus der Reserve ohne was umbenennen zu müssen. Hier hat die Verwendung nicht verloren. Genausowenig wie die Technik in der Bisiness logic. Principle separation of concerns.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

blecher-at

#28
Ich habe das bei meinen Geräten großteils über dummys gelöst. Das Gerät das dann über MQTT raussendet hat dann bereits den logischen Namen, bei einigen Geräten muss ich den State-inhalt umschreiben oder mehrere Geräte/States auf eines zusammenfassen.

Das durch MQTT zu ersetzen so wie du es machst finde ich eine sehr interessante Idee, ich hätte aber eine extra Schicht eingezogen, das wäre in deinem Fall also Hardwaregerät -> MQTT -> Integrationsschicht -> MQTT -> Businesslogik.
Die Topics am 1. Broker haben dann den technischen namen (den ich aber dennoch hersteller-agnostisch halten würde), am 2. broker dann die logischen.

Um wieder ontopic zu werden: 8)
Dein Modul unterstützt derzeit noch kein "set". Wäre das ein 2. attribut am Gerät oder über eine konvention/einstellung am hauptgerät zu realisieren?

hexenmeister

Dummies nutze ich eigentlich fast gar nicht. Für solche Fälle habe ich ein eigenes Spezialmodul (https://forum.fhem.de/index.php/topic,79116.msg711686.html#msg711686). Ist etwas mächtiger. Jedoch möchte ich auch davon möglichst wenige haben, daher die Idee mit GenericBridge.

Zwei MQTT-Schichten? Welcher Vorteil kann man dabei erzielen? Ich finde, es macht wenig Sinn, mehrere FHEM-Intanzen so eng aneinander zu binden, dass alle Geräte quasi iberall vorhanden sind. Was soll man mit den 'fremden' Geräten machen, wenn business logic eh darüber liegt? Das wäre doch eigentlich nur ein unnötiger Netztzwerklast.

Das Modull soll publish und auch subscribe unterstützen (letzteres möchte ich noch einbauen, hatte nur noch leider keine Zeit für gefunden. Soll ähnlich wie mit subscribe konfiguriert werden).

Was genau soll ein 'set' machen? Oder meinst Du eben 'publish'?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy