[gelöst] Zeitschaltuhr: Rolläden herunter fahren deren Fenster geschlossen sind

Begonnen von Rheingold, 03 Februar 2022, 13:52:40

Vorheriges Thema - Nächstes Thema

Rheingold

Hallo,

ich habe einen eigentlich banalen Anwendungsfall, stehe aber völlig auf dem Schlauch wie ich das am sinnvollsten in FHEM umsetzen kann und bin daher für jede Hilfe dankbar.

In FHEM habe ich 6 Rolläden (Rolladen1, Rolladen2, ...) und 6 Fensterkontakte (Fenster1, Fenster2, ...). Wobei ich keine Nummern, sondern Raumnahmen nutze. Die Nummern dienen der Vereinfachten Darstellung.
Zudem habe ich zwei Structures: Rolladen_alle und Fenster_alle

Ich möchte eine Zeitschaltuhr zum Herunterfahren der Rolläden erstellen, die alle Rolläden herunter fährt bei denen das Fenster geschlossen ist. Wenn alle Fenster geschlossen sind, ist es recht simpel ein Structure (für Fensterkontakte) mit einem Structure für alle Rolläden zu koppeln. Aber wie kann ich sagen "Wenn Fenster1 geschlossen ist, fahr Rolladen1 herunter UND wenn Fenster2 geschlossen ist, fahr Rolladen2 herunter UND und und..."

Mit IF schreib ich mich dumm und dämlich.
Bei DOIF fehlt mir gerade der richtige Ansatz um alle Rolläden zu steuern.
Für jeden Rolladen eine einzelne Zeitschaltuhr zu erstellen wäre möglich, aber irgendwie "unsexy" ;-)

Wer hat Ideen?
Fhem auf Raspi 3; Jeelink mit 6x TX29DTH; CUL433 mit 9x RCS 1000 N und Somfy-Steuerung; CUL868; MAX-Cube + Thermostate; Philips Hue & Ikea Tradfri; Google Home Assistant; FTUI für Tablet und SmartPhone via Reverse-Proxy

Beta-User

Zitat von: Rheingold am 03 Februar 2022, 13:52:40
Wer hat Ideen?
Nun ja, die "eierlegende Wollmilchsau" heißt AutoShuttersControl, kurz ASC...

Ansonsten: z.B. "FILTER" (siehe Abschnitt "devspec" in der commandref) könnte beim Fahrbefehl helfen, aber dazu müßte es eine Info am "Zielgerät" geben. Die könntest du übertragen, indem du ein notify oä. darauf ansetzt, dem "Rollladen" einen Fensterkontakt-Wert zuzuweisen (siehe "setreading")...

Oder eben eine myUtils-Routine aufrufen, die alle Rollläden beim Fahrbefehl durchgeht und dann nur jeweils schaltet, wenn der aus dem Rollladennamen abgeleitete Fensterkontakt zu ist.

Viele Wege führen nach Rom, aber meine Kernfrage wäre: Was soll denn passieren, wenn das Fenster dann "später" geschlossen wird?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

CoolTux

Ich würde Dir da ASC empfehlen. In Deinem Fall ist es sogar recht simpel. Du willst ja anscheinend lediglich eine feste Zeit haben. Das sind pro Rollo 4 Handgriffe zum einrichten und fertig.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

zife

Nichts gegen ASC, mächtiges Ding. Aber für die Vielfalt:

Ich hab so was Ähnliches - wenn man das Haus verlässt, zeigt eine LED, dass noch ein Fenster offen ist. Dann drückt man den Taster und es fährt genau der Rolladen runter, wo das Fenster offen ist (quasi "Fenster zu für Faule").

So schlimm finde ich die IF-Kette da nicht:

define TasterLED_FE_1_AI DOIF ([TasterLED_FE_1] eq "AI") (IF ([Kueche_Tuersensor_Sued] eq "open")(set Kuechen_Rolladen_Sued_1 down), IF ([Wohnzimmer_Tuersensor_Sued] eq "open")(set Wohnzimmer_Rolladen_Sued down), ...)


Und bei mir sind's mehr als 6  :)
fhem mit EnOcean, Gardena, Vorwerk, Miele und Teufel/Raumfeld-Integration... nur meine Kinder wollen sich damit nicht anständig steuern lassen. Wer weiß Rat?

Rheingold

Zitat von: zife am 03 Februar 2022, 14:13:15
Nichts gegen ASC, mächtiges Ding. Aber für die Vielfalt:

Ich hab so was Ähnliches - wenn man das Haus verlässt, zeigt eine LED, dass noch ein Fenster offen ist. Dann drückt man den Taster und es fährt genau der Rolladen runter, wo das Fenster offen ist (quasi "Fenster zu für Faule").

So schlimm finde ich die IF-Kette da nicht:

define TasterLED_FE_1_AI DOIF ([TasterLED_FE_1] eq "AI") (IF ([Kueche_Tuersensor_Sued] eq "open")(set Kuechen_Rolladen_Sued_1 down), IF ([Wohnzimmer_Tuersensor_Sued] eq "open")(set Wohnzimmer_Rolladen_Sued down), ...)


Und bei mir sind's mehr als 6  :)

Du bist mein Held! Ich hab das Pferd von hinten versucht aufzuzäumen "Wenn Fenster1 offen, fahre Rolladen 2-6 herunter" usw. Aber dein Ansatz ist ja viel besser! "Wenn Fenster 1 geschlossen, fahr Rolladen1 runter. usw..." :D :D :D

Manchmal kann's so einfach sein :D
Fhem auf Raspi 3; Jeelink mit 6x TX29DTH; CUL433 mit 9x RCS 1000 N und Somfy-Steuerung; CUL868; MAX-Cube + Thermostate; Philips Hue & Ikea Tradfri; Google Home Assistant; FTUI für Tablet und SmartPhone via Reverse-Proxy

Beta-User

Zitat von: zife am 03 Februar 2022, 14:13:15
Aber für die Vielfalt:

Hier noch ein verblichenes Schnippsel "von früher" wegen der Vielfalt:
define Timer_Rolladen_Automode_1 WeekdayTimer TYPE=CUL_HM:FILTER=model=HM-LC-Bl1PBU-FM:FILTER=automode=1 !$we|{sunrise_abs_dat($today,"CIVIL",rand(240),"06:45","08:00")}|on\
$we|{sunrise_abs_dat($today,"CIVIL",rand(240),"08:40","09:00")}|on\
{sunset_abs_dat($today,"CIVIL",rand(240),"20:45","22:20")}|off {fhem ("set\
$NAME:FILTER=STATE!=$EVENT $EVENT")}
Da hat man dann gleich auch die allgemeine Info, ob denn die Rollläden jetzt tendenziell grade offen oder zu sein sollten (als Reading im WeekdayTimer).

Wie gesagt: viele Wege führen nach Rom, aber dieses händische DOIF/IF-Geschubse ist nichts für mich...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

zife

Hier sieht man schön, wie man sich in fhem entwickeln kann... von der kurzzeitigen Denkblockade über IF-Geschubse hin zur Profi-Lösung 8)
Klar, die hat natürlich Vorteile, gerade wenn man später das Fenster schließt.
fhem mit EnOcean, Gardena, Vorwerk, Miele und Teufel/Raumfeld-Integration... nur meine Kinder wollen sich damit nicht anständig steuern lassen. Wer weiß Rat?

Beta-User

Zitat von: zife am 03 Februar 2022, 15:15:33
Hier sieht man schön, wie man sich in fhem entwickeln kann... von der kurzzeitigen Denkblockade über IF-Geschubse hin zur Profi-Lösung 8)
Klar, die hat natürlich Vorteile, gerade wenn man später das Fenster schließt.
Nun ja, aber man muss dann eben immer noch dafür sorgen, dass a) das Reading passend gefüllt wird und b) der Rollladen ggf. geöffnet/geschlossen wird, wenn später das Fenster zugeht.

Deswegen ist das auch "Geschichte" - ASC ist in der Basis nämlich eigentlich auch einfach und ermöglicht dann pro Rollladen noch viel mehr "typische" Abläufe, ohne dass man groß was tun müßte außer den passenden Angaben...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Rheingold

Für die Nachwelt meine Lösung in Anlehnung an zife:

define di_Rolladen_Abend DOIF ([{sunset("HORIZON=-6",0,"16:00","23:00")}] and [Zeitschaltuhr_Rolladen_Abends] eq "on") (
IF ([Fenster_Bad] eq "closed") (set Rolladen_Bad close),
IF ([Fenster_Buero] eq "closed") (set Rolladen_Buero close),
IF ([Fenster_Balkon] eq "closed") (set Rolladen_Wohnzimmer_Zusammen close)
)


usw :)
Danke für die Hilfe und Ideen :)
Fhem auf Raspi 3; Jeelink mit 6x TX29DTH; CUL433 mit 9x RCS 1000 N und Somfy-Steuerung; CUL868; MAX-Cube + Thermostate; Philips Hue & Ikea Tradfri; Google Home Assistant; FTUI für Tablet und SmartPhone via Reverse-Proxy