Bedienungssperre für Rollladen

Begonnen von Timmy.m, 09 Juli 2015, 21:55:20

Vorheriges Thema - Nächstes Thema

Timmy.m

Ich würde es toll finden, wenn Rollladen-Schalter in Abhängigkeit von einem anderen Device nicht geschaltet werden kann. Zum Beispiel, weil eine Tür oder ein Fenster auf oder gekippt ist. Dies könnte man als Eigenschaft in einem "Rollladenschalter" in FHEM einbinden. Bisher muss ich in jede Aktion, die eine Rolllade bedient auch eine Sperre einbauen.

Grüße Tim
FHEM5.9@RaspPi.3B|HMLAN|CUL868V3|1Wire|HUE|FritzBox|BotVacDconnected|3xKindleDisplay|
FHEM2FHEM|
FHEM5.9@RaspPi.2B|nanoCul868|TCM310|JeeLinkClone|RFXTRX433E|ZWave|Zigbee|xiaomi
RaspberryMatic@RaspPi.3B+ in Planung

Hollo

Kommt das nicht auf das gleiche heraus?
Nicht fahren weil heisst ja im Umkehrschluss auch, Du musst eine Sonderbehandlung definieren, was passieren soll, wenn die "Sperre" nicht mehr aktiv ist.

Zum Testen könnte man mal mit "inhibit" oder einem userreading spielen.
Dann hast Du zumindest immer nur 1 Bedingung zu berücksiichtigen, die immer genau dem Device zugeordnet ist.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

Timmy.m

Hallo Hollo!

Vielen Dank für die Rückmeldung.
Du hast schon recht... man kann es selbst lösen. Jedoch bevorzuge ich Lösungen für alle. Warum muss man bei allen Steuervorgängen etwas einbauen, was eigentlich von allen benötigt wird und an einer zentralen Stelle gelöst werden könnte.
Ich könnte mir vorstellen, dass man in die jeweiligen Devices mit State Einträge, die ein Schalten der Rollländen verhindern.


Vorschlag:
attr Rolllade_WzDoor conditionLock HM_RHS_WzDoor:Tilt, HM_RHS_WzDoor:open

Dann würde auch ein direktes schalten des Devices "set Rolllade_WzDoor down" blokkieren.

Grüße Tim
FHEM5.9@RaspPi.3B|HMLAN|CUL868V3|1Wire|HUE|FritzBox|BotVacDconnected|3xKindleDisplay|
FHEM2FHEM|
FHEM5.9@RaspPi.2B|nanoCul868|TCM310|JeeLinkClone|RFXTRX433E|ZWave|Zigbee|xiaomi
RaspberryMatic@RaspPi.3B+ in Planung

marvin78

Dsas muss man IMHO schon selbst lösen, da es zu viele individuelle Bedingungen geben kann. Man kann hierbei nicht von sich selbst auf andere schließen. Ich verstehe auch nicht, warum es für alles eine allgemeingültige (und damit eng gesteckte) Lösung geben muss. Zumal dieses "Problem" auf viele Arten und sehr einfach zu lösen ist.

viegener

Eine Lösungsskizze, die jeder individuell ohne Codeänderungn am Core gehen sollte:

- Ein neues gloables Attribut definieren, in dem die Bedingung hinterlegt ist, die erfüllt sein sollte, damit eine Rolladenbewegung ausgelöst wird (Beispiel: movingCondition).
- An einem Rolladen kann man dann diese Bedingung hinterlegen, Beispiel:
( movingCondition ( ReadingsVal("tuer_1","state","open") ne "open" )
- Eine my_utils-Funktion anlegen, die 2 Parameter übergeben bekommt: Den Device/Rolladen, der bewegt werden soll und der Befehl der ausgeführt werden soll. Beispiel
moveOnCondition( $$ )
- In der Routine wird am Device der übergeben wurde geschaut, ob eine Bedingung hinterlegt ist. Wenn eine Bedingung hinterlegt wird, wird diese als Perl-Konstrukt ausgewertet. Wenn keine Bedingung hinterlegt ist oder die Bedingung wahr ergibt wird das übergebene Kommando an den Device gesendet ansonsten nicht

Wie gesagt nur eine Skizze, aber sie ermöglicht ohne zu viel Aufwand bei den Aktionen dezentral und generisch die Anforderung zu realisieren, auch wenn es natürlich etwas Programmierung erfordert sollte es aber ohne Änderung möglich sein.



Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können