Modul-Konzeption: Generic MQTT Bridge

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

Vorheriges Thema - Nächstes Thema

Mitch

Zitat von: dev0 am 25 Dezember 2017, 11:59:19
Kannst Du das bitte in einem neuen Thread zeigen/presentieren, um hier nicht offtopic zu werden?

+1  ;)
FHEM im Proxmox Container

pula

Hi,

hab mich in letzter Zeit auch ziemlich viel mit fhem und mqtt beschäftigt.
hab mir zb einen sketch zurechtgebastelt, der mehrere schalter und pirs bedient und je nach zustand ein relais schaltet (dämmerung, konfigurierbares timeout etc).
was mir dabei momentan nicht wirklich gefällt, ist die trennung zwischen publish und subscribe. wäre es nicht schöner, wenn man die beiden dinge zusammenfassen könnte?
Beispiel:
publish: blablub/set 1
subscribe: blablub/get  --> das wäre toll, wenn das wieder auf das set zurückgespiegelt würde (im gleichen Reading)

Cheers,
Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

hexenmeister

Das kannst Du bereits jetzt realisieren (zwei mal den gleiche String verwenden). Halte ich jedoch nicht für sinnvoll. Wenn so von außen etwas empfangen wird und auch gesetzt wird, wird es ja gleich wieder gepublisht. So können unschöne Schleifen entstehen. Daher ist die Trennung zwischen 'get' und 'set' durchaus sinnvoll und auch gewollt.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

pula

Ok, verstehe ich. Stimmt auch wieder, daß hier Schleifen entstehen können, Du hast recht...
Vielleicht könnte man hier ein Attribut (donotrepublish oder so) einführen, um so etwas zu unterbinden?
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

hexenmeister

Wäre ja nur bedingt hilfreich (Es gibt ja ggf. auch andere Teilnehmer im MQTT-Netzt). Ich halte eine generelle Trennung von 'setzen' und 'lesen' Attributen für sinnvoll. Läuft bei mir problemlos und stabil. Wofür genau benötigst Du das?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

pula

Es läuft bei mir eh auch gut und stabil. ich denke nur, daß es komfortabler sein könnte, Dinge zusammenzufassen.
Ein Beispiel:
Ich habe ein device, bei dem das topic vz/vz_licht_pir_active den Status setzt, dass die bewegungserkennung aktiv ist (aus fhem gesetzt, weil dunkel).
Das zugehörige Reading (subscribe) heisst vz/vz_licht_motion_activate_state. Das sind jetzt zwei Readings in dem device.
Schön wäre es, wenn man es einfach setzen könnte und die Rückmeldung vom device in das Reading einfliessen würde....
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

hexenmeister

verstehe. leider funktioniert das modul derzeit so nicht.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Master_Nick

#37
 ;D Guten Abend,

Hexenmeister - verstehe ich deine Herangehensweise korrekt:

Ein Device in FHEM der direkt bei veränderung das in ein definiertes Topic schreibt mit defniertem State (on/off/true/false/ ... whatever)? :-)
Also pro Device, dass mit MQTT arbeitet ein Device in FHEM.
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

hexenmeister

Ja, jedes FHEM-Device soll so konfiguriert werden können, dass Änderungen per MQTT gesendet werden. Auch andersherum ist geplant.
Jetzt muss ich noch Zeit finden, zu Ende zu bringen. Bin jetzt auf ner Dienstreise in München, hoffe habe nächste Woche etwas mehr Zeit.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Master_Nick

#39
 ;) Job geht vor  8)

Erlaube mir die vorsichtige Frage, was unterscheidet dein Modul von dem hier: https://forum.fhem.de/index.php/topic,27532.0.html ?

*EDIT ich ziehe die Frage zurück! - Exakt JEDES FHEM-Device soll so konfiguriert werden können. :-)

Also aktuell geht es nur in eine Richtung? Ich sehe bei MQTT was die Devices als State haben aber kann nicht sagen nun schalte um?
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

hexenmeister

Zitat von: Master_Nick am 05 Februar 2018, 10:52:26
Also aktuell geht es nur in eine Richtung? Ich sehe bei MQTT was die Devices als State haben aber kann nicht sagen nun schalte um?

Geplant sind natürlich beide Richtungen. Es kommt nur immer etwas dazwischen, wenn ich mich daran setzen will :(
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Master_Nick

 ;)

Keine Angst so geht es vielen. Ich hab jetzt gerade meine ersten SonOffs in MQTT drin und hab sie seit einer Woche nur in so eingesteckt statt schon an Ort und Stelle verbaut ;-)
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

Master_Nick

Der Einbau von Toggle wäre auch was feines  ;)
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

hexenmeister

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Master_Nick

#44
Also gehen wir z. B. von on und off aus oder true und false, dann schaltet es zwischen beiden umher ohne einen von beiden zu nennen. Einfach aufgrund des aktuellen Zustands wird der ander gewählt.

Anwendung:

Ich habe einen Flic-Button der bei Klick das Zimmer in Wach- oder Schlafmodus schaltet (Kinderzimmer  mit Babyphone und Lichtautomatik über Bewegungsmelder am Tag).

Aktuell gelöst mittels aufwändigem Notify - wäre machbar mittels einem Befehl wenn es Togglen könnte.

Man bräuchte nur sagen bei Click -> Toggle.


Für native MQTT Devices kam es auch erst vor kurzem ;-)
https://forum.fhem.de/index.php/topic,82240.msg743072.html#msg743072
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)