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
Problem #1 und #2 ist mit eventMap und structure-Attributen auch bei structure zu loesen.
Kannst Du bitte Problem #3 genauer erklaeren?
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. :)
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.
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.
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.
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?