Modul dev_proxy - mehrere Geräte-Readings zusammenfassen/umbenennen/umrechnen

Begonnen von hexenmeister, 06 November 2017, 01:23:37

Vorheriges Thema - Nächstes Thema

hexenmeister

Hallo,

für meine Rolladensteuerung habe ich Funktionalität gebraucht, die überraschenderweise noch nicht in der Form existiert. Eigentlich macht structure so was in der Art, jedoch nicht alles, was ich gebraucht habe. Also habe ich ein eigenes Modul entworfen und implemntiert. Je nach Reaktion (wenns von anderen Benutzern gebraucht wird), kann ich das Modul ggf. einchecken.
Falls jemand andere / bessere Lösungen kennt - würde ich diese gerne kennenlernen :)

VG
Alexander


Problemstellung:
Mehrere Rolladen zweier unterschiedlichen Systeme (HomeMatic und EnOcean (Eltako FSB14)) sollen zwecks gemeinsamer Steuerung in mehrere Gruppen zusammengefasst (pro Zimmer, Etage, ganzes Haus) und per MQTT gesteuert werden.

Problem #1:
HomeMatic verwendet zu Positionssteuerung Reading 'pct', EnOcean jedoch 'position'.

Problem #2:
Bei Homematik sind die Rolladen bei 100 'offen', bei EnOcean steht dieser Wert für 'geschlossen'.

Problem #3:
Für MQTT verwende ich getrennte Topics fürs Setzen und den Zustand (Vermeidung von Endlosschleifen). Dafür benötige ich zwei verschiedenen Readings pro Gruppe. Das geht mit structure leider nicht.


Modulbeschreibung:
Define:    define <name> dev_proxy <dev1> <dev2> ...

Mit diesem virtuellem Gerät können ausgewählte Readings eines anderen oder mehreren Geräte an einer Stelle zusammengefasst werden. Diese können dabei ggf. umbenannt und / oder umgerechnet werden.

Beispiel:    defmod testdev_proxy dev_proxy MQ_DG_WZ_O_Rollo1 MQ_DG_WZ_O_Rollo2

Set:
Die hier angegebenen Werte werden an die Originalgeräte weitergeleitet. Definierte Umbenennungen und Umrechnungen werden berücksichtigt.

Get:
wird nicht unterstützt

Attributes:
- observedReadings: bestimmt zu überwachende Readings (durch Leerzeichen separierte liste)
    (wenn dieses Attrubut nicht angegeben wird, werden 'state', 'dim'und 'position' überwacht)
    Beispiel:    attr <name> observedReadings state level

- setList: Durch Leerzeichen getrennte Liste der Werte für Set-Befehl.
    Diese Liste wird bei "set name ?" ausgegeben. Damit kann das FHEMWEB-Frontend Auswahl-Menüs oder Schalter erzeugen.
    Die gesetzten Werte werden an die entsprechende Readings der Geräte weitergereicht. Dabei wird im mapReadings definierte Umsetzungsregel beachtet.
    Es wird jedoch nicht geprüfft, ob angegebene Reading in observed_reading vorhanden ist. Ggf. wird einfach 'blind' weitergereicht.
    Beispiel:    attr <name> setList opens:noArg closes:noArg stop:noArg up:noArg down:noArg position:slider,0,1,100

- mapValues: Erlaubt Änderungen/Umrechnungen an den Werte der Readings ggf. abhängig von den jeweiligen Device- und Readingsnamen.
    Die Werte müssen in als eine Hash-Map angegeben werden. <STATE> soll als state angesprochen werden.
    Form: {'<device>:<reading>'=>{'<value>'=>'new value',..},..}
    <device>, <reading> und <value> können auch mit * angegeben werden. Diese Angabe wird als 'Default' verwendet, wenn keine andere gepasst haben.
    Prioritätenreihenfolge für die <device>:<reading>-Paaren: <device>:<reading>, <device>:*, *:<reading>, *:* (oder auch *).
    Für die Umrechnung steht das Originalvalue als $val-Variable zur Verfügung.
    Falls Richtung (von Original-Gerät (bei Notify) oder zu dem Original-Gerät (bei set)) wichtig ist,
    kann diese durch Abfrage der Variable $incoming (jeweils 1 oder 0) abgefragt werden.
    Beispiel:    attr <name> mapValues {'*:position'=>{'*'=>'{100-$val}','down'=>'100', 'closed'=>'100', 'up'=>'0', 'open'=>'0', 'open_ack'=>'0', 'off'=>'0', 'on'=>'100'}}

- mapReadings: Erlaubt Geräte-Readings unter anderem Namen verwenden. * kann als Default anstatt Gerätenamen verwendet werden.
    <STATE> soll als state angesprochen werden.
    attr <name> mapReadings <device>:<original reading>:<hier zu verwendende reading> ...
    Beispiel:    attr <name> mapReadings Rollo1:pct:position Rollo2:pct:position


Beispiele:

    Zusammenfassung zweier Rollläden, Steuerung über die Reading 'position', Umkehrung der Prozentwerte.    defmod test1 dev_proxy Rollo1 Rollo2
    attr test1 mapValues {'*:position'=>{'*'=>'{100-$val}','down'=>'100', 'closed'=>'100', 'up'=>'0', 'open'=>'0', 'open_ack'=>'0', 'off'=>'0', 'on'=>'100'}}
    attr test1 setList opens:noArg closes:noArg stop:noArg up:noArg down:noArg position:slider,0,1,100
    attr test1 webCmd opens:closes:stop:position



    Abbildung für ein Rollladen, Umbenennung der Original-Reading 'pct' in 'pos', Umkehrung der Prozentwerte.    defmod test2 dev_proxy Rollo1
    attr test2 observed_readings pos state
    attr test2 mapValues {'*:pos'=>{'*'=>'{100-$val}','down'=>'100', 'closed'=>'100', 'up'=>'0', 'open'=>'0', 'open_ack'=>'0', 'off'=>'0', 'on'=>'100'}}
    attr test2 setList opens:noArg closes:noArg stop:noArg up:noArg down:noArg pos:slider,0,1,100
    attr test2 mapReadings *:pct:pos
    attr test2 webCmd up:down:stop:pos
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

rudolfkoenig

Problem #1 und #2 ist mit eventMap und structure-Attributen auch bei structure zu loesen.
Kannst Du bitte Problem #3 genauer erklaeren?

hexenmeister

Moin!

Vermutlich kann man die Umbenennung mit Structure-Attribute machen und Umrechnung mit UserReadings in den jeweiligen Devices. Erscheint mir etwas kompliziert und 'auseinandergezogen' (Konfiguration der Gruppe an einer Stelle ist mir lieber).

Zum Problem Nr.3:
Ich reiche, wie gesagt, Devices per MQTT_BRINGDE weiter und (unter anderem) in einer anderen FHEM-Instanz binde ich sie wieder als MQTT_DEVICE. Funktioniert wunderbar, soweit die Topic zum Setzen und zum Anzeigen des Zutandes nicht gleich sind. Wenn sie es sind, dann wird bei jedem setzen gleich wieder gepublisht, was bei zwei Instanzen zum endlosen Nachrichtensenden führt. Außerdem bei getrennten Topics kann ich den Zustand mit 'Retain'-Flag senden, damit bekommen alle Clients immer den Zustand, auch wenn sie zum Sendezeitpunkt offline waren. Bei dem Topic zum setzen ist das eine schlechte Idee - führt ggf. bei jedem FHEM-Neustart zum wiederholen der letzten Schaltbefehlen. Ich hoffe, dass war so halbwegs verständlich. :)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

hexenmeister

Scheint so, dass ich ein recht speziefisches Problem habe (und damit wohl alleine bin) ;D
Ich checke in Contrib ein, vlt. wird irgendwann mal jemandem nützlich sein.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

berlineraxel

Ich habe genau das gleiche Problem.
Schade, dass unser Administrator das mit einem Satz vom Tisch wischt.
Da wäre ein Beispiel schön gewesen, wie man es anders lösen kann.


mcp

Zitat von: hexenmeister am 06 November 2017, 01:23:37
... Je nach Reaktion (wenns von anderen Benutzern gebraucht wird), kann ich das Modul ggf. einchecken.
Falls jemand andere / bessere Lösungen kennt - würde ich diese gerne kennenlernen :)
Hallo Alexander,

hast du evtl. eine aktuellere Version vom deinem dev_proxy Modul?

Ich benötige aktuell ebenso die Funktionalitäten, jedoch crashed mir FHEM immer weg, wenn ich observed readings benutze :-(

Danke dir.
Maintainer: 98_vitoconnect.pm
Raspberry Pi 4B, 4 GB RAM, 32 GB SD Karte
Raspbian Bullseye 32-bit, FHEM up2date

hexenmeister

Hallo,

ich nutze diesen Modul selbst schon länger nicht mehr. Habe jetzt kurz ausprobiert. Bei mir crashed nichts.
Die letzte Version, die ich gefunden habe, hänge ich an.
Was genau ist Dein Anwendungsfall? WIe sehen Konfig und Crash-Logs aus?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy