[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.10

Begonnen von CoolTux, 22 Juni 2020, 12:38:36

Vorheriges Thema - Nächstes Thema

muede

Guten Morgen zusammen,

nachdem ich die Rollofunktion nun seit Längerem nutze und ich abgesehen von Kleinigkeiten, die aber eher an der eigenen Hardware liegen, glücklich bin (bei der Beschattung arbeite ich mich langsam in den Zielkooridor :o), ist mir nun aber aufgefallen, dass der DriveUp_WE seit mind. zwei Wochen nicht funktioniert, obwohl hier keine Änderungen an meinerKonfiguration vorgenommen wurden.
Zeitlich könnte das in Zusammenhang mit einer Urlaubseintragung im "holiday" Device stehen. Kann es sein, dass hier eine Unverträglichkeit zum "holiday" Device besteht und das ASC zur Auswertung nun einvordefinierte Eingabe wie z.B. Urlaub fordert?

Danke vorab.

LG,
muede   

bicmac

Hi,
ich habe gestern das ASC auch mal für meien DUOFERN Rademacher Rollladen installiert. Bisher scheint es gut zu funktionieren.
Nun möchte ich aber auch externe Trigger mit ASC_ExternalTrigger einbinden bzw habe das auch erfolgreich für einen Trigger gemacht.

Ich habe nun 3 Fragen:

1) kann ich auch in einem Device mehrere trigger einbauen? Wenn ja wie gebe ich diese an?

2) Kann mann ggf auch im ASC Device selber dieses Attribute einfügen so das dieser auslst und alle Rollos hochfährt (zum Beispiel wenn Rauchmelder angehen und "Feuer" signalisieren") oder muss ich das in jedem Device extra machen?

3) kann ich im Down "time" mode irgendwie erreichen das die Rollos abens in einem Zeitraum "zufällig" herunterfahren und nicht alle zu einem Zeitpunkt? Ich würd dazu gern sagen die Rollos können sollen zum Beispiel zw. 18:00 - 19:30 runten. Die genaue Zeit in dem Zeitraum soll aber zufällig sein. Das dient dazu um ein wenig "manuelle Tätogkeit" im Haus vorzuspielen wenn man das Haus von außen beobachtet. So das man nicht erkennt das niemand daheim ist. Bei Duofern bietet der Homepilot genau die Funktion und ich fand das super. Jetzt im FHEM mit ASC geht das wie ich verstanden habe leider nicht. Oder?

D3ltorohd

Frage zu einem Szenario ::

Draußen noch hell, Rollos manuell runtergefahren. So wenn ich jetzt Fenster auf mach, fahren sie in Lüftungsposition. Dies sollte aber erst nach einer bestimmten Uhrzeit passieren z.b. 22:30 wenn es dunkel ist. Da das für die Kids zu hell ist, bleiben die Rollos erst mal unten. Ich lasse die Rollos dann um 22:30 wenn sie sicher schlafen auf 50 % fahren, damit sie frische Luft bekommen. Dazu sollte ich aber die Fenster öffnen, nachdem ich die Rollos manuell unten habe.

Kann ich das mit bocking time befor day realisieren ? Oder könnte man da was einbauen ?
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

cbl

Zitat von: muede am 26 Juli 2020, 10:10:56
..., dass der DriveUp_WE seit mind. zwei Wochen nicht funktioniert, obwohl hier keine Änderungen an meinerKonfiguration vorgenommen wurden.
Zeitlich könnte das in Zusammenhang mit einer Urlaubseintragung im "holiday" Device stehen. Kann es sein, dass hier eine Unverträglichkeit zum "holiday" Device besteht und das ASC zur Auswertung nun einvordefinierte Eingabe wie z.B. Urlaub fordert?

Bei mir funktioniert das seit Wochen stabil. An welchen Wochentagen hat es nicht funktioniert? Samstag/Sonntag oder an einem Werktag, der durch das Holidaydevice zum Wochenendr werden sollte?
Was hast du im Holidaydevice verändert?

FunkOdyssey

CoolTux war im Urlaub fleißig: https://svn.fhem.de/trac/changeset/22473/
Du sollst dich doch erholen.  :)

Aber auch vielen Dank.

ch.eick

Hallo zusammen,

ich habe da auch noch etwas konfiguriert. Für den Fall, dass z.B. nicht alle Fenster einen Fenterkontakt haben.
Meine Situation für das nächtliche Querlüften um die Haustemperatur zu senken ist, dass ich immer beide Terrassentüren öffne.
Geschieht das zwischen 22:00 und 08:00 Uhr, erzeuge ich ein Fenster open für ein weiteres Fenster, das keinen Fensterkontakt hat.


defmod BA_N_Fenster DOIF \
################################################################################################################\
## 1 Fensterkontakt offen, wenn Küche und Wohnzimmer in der Nacht offen sind\
##\
([KU_S_Fenster:state] eq "open" and\
  [WO_W_Fenster:state] eq "open" and\
  [22:00-08:00] )\
\
    (setreading $SELF BA_N_Fenster open)\
\
################################################################################################################\
## 2 ansonsten Fensterkontakt schließen\
##\
DOELSEIF\
([KU_S_Fenster:state] eq "closed" or\
  [WO_W_Fenster:state] eq "closed" )\
    (setreading $SELF BA_N_Fenster closed)

attr BA_N_Fenster DbLogExclude .*
attr BA_N_Fenster DbLogInclude state
attr BA_N_Fenster alias BA_N_Fenster
attr BA_N_Fenster comment Dummy Fensterkontakt für das Querlüften in der Nacht. Gekoppelt mit WZ und KU
attr BA_N_Fenster devStateIcon open:fts_window_2w_open_l closed:fts_window_2w
attr BA_N_Fenster disable 0
attr BA_N_Fenster do always
attr BA_N_Fenster event-on-change-reading .*
attr BA_N_Fenster group ASC Rollos
attr BA_N_Fenster icon fts_window_2w
attr BA_N_Fenster room Rollos
attr BA_N_Fenster sortby 21
attr BA_N_Fenster state [$SELF:BA_N_Fenster]
attr BA_N_Fenster verbose 0


Dieser Fensterkontakt wird dann im ASC als twostate definiert.

Viele Spass
     Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

CoolTux

Zitat von: FunkOdyssey am 27 Juli 2020, 09:26:53
CoolTux war im Urlaub fleißig: https://svn.fhem.de/trac/changeset/22473/
Du sollst dich doch erholen.  :)

Aber auch vielen Dank.

Das meiste war vor meinem Urlaub  ;D
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

CoolTux

Zitat von: D3ltorohd am 26 Juli 2020, 20:32:59
Frage zu einem Szenario ::

Draußen noch hell, Rollos manuell runtergefahren. So wenn ich jetzt Fenster auf mach, fahren sie in Lüftungsposition. Dies sollte aber erst nach einer bestimmten Uhrzeit passieren z.b. 22:30 wenn es dunkel ist. Da das für die Kids zu hell ist, bleiben die Rollos erst mal unten. Ich lasse die Rollos dann um 22:30 wenn sie sicher schlafen auf 50 % fahren, damit sie frische Luft bekommen. Dazu sollte ich aber die Fenster öffnen, nachdem ich die Rollos manuell unten habe.

Kann ich das mit bocking time befor day realisieren ? Oder könnte man da was einbauen ?

Mir würde da auf die schnelle nichts einfallen. BlockingTime könnte man nehmen aber du weißt ja nicht wann Du lüften willst.
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

bicmac

Hi,
hab heut wieder den halben Tag gelesen und bastelt aber ich konnt mir die Fragen unten nicht selber beantworten. Hat jemand eine Idee?

Zitat von: bicmac am 26 Juli 2020, 13:23:41
Hi,
ich habe gestern das ASC auch mal für meien DUOFERN Rademacher Rollladen installiert. Bisher scheint es gut zu funktionieren.
Nun möchte ich aber auch externe Trigger mit ASC_ExternalTrigger einbinden bzw habe das auch erfolgreich für einen Trigger gemacht.

Ich habe nun 3 Fragen:

1) kann ich auch in einem Device mehrere trigger einbauen? Wenn ja wie gebe ich diese an?

2) Kann mann ggf auch im ASC Device selber dieses Attribute einfügen so das dieser auslst und alle Rollos hochfährt (zum Beispiel wenn Rauchmelder angehen und "Feuer" signalisieren") oder muss ich das in jedem Device extra machen?

3) kann ich im Down "time" mode irgendwie erreichen das die Rollos abens in einem Zeitraum "zufällig" herunterfahren und nicht alle zu einem Zeitpunkt? Ich würd dazu gern sagen die Rollos können sollen zum Beispiel zw. 18:00 - 19:30 runten. Die genaue Zeit in dem Zeitraum soll aber zufällig sein. Das dient dazu um ein wenig "manuelle Tätogkeit" im Haus vorzuspielen wenn man das Haus von außen beobachtet. So das man nicht erkennt das niemand daheim ist. Bei Duofern bietet der Homepilot genau die Funktion und ich fand das super. Jetzt im FHEM mit ASC geht das wie ich verstanden habe leider nicht. Oder?

crusader85

Zitat von: D3ltorohd am 26 Juli 2020, 20:32:59
Frage zu einem Szenario ::

Draußen noch hell, Rollos manuell runtergefahren. So wenn ich jetzt Fenster auf mach, fahren sie in Lüftungsposition. Dies sollte aber erst nach einer bestimmten Uhrzeit passieren z.b. 22:30 wenn es dunkel ist. Da das für die Kids zu hell ist, bleiben die Rollos erst mal unten. Ich lasse die Rollos dann um 22:30 wenn sie sicher schlafen auf 50 % fahren, damit sie frische Luft bekommen. Dazu sollte ich aber die Fenster öffnen, nachdem ich die Rollos manuell unten habe.

Kann ich das mit bocking time befor day realisieren ? Oder könnte man da was einbauen ?

Ich schummle da etwas. Ich stelle, wenn die Kinder schlafen (gibt einen Knopf, der dann auch Klingel stummschaltet z.B.) die ventilatepos auf 100 Prozent und ändere sie wieder, wenn ich ins Bett gehe. Damit funktioniert es bei mir eigentlich ganz gut. Die Rollos fahren allerdings mit etwas Verspätung, aber sie verändern dann die ventilate Pos. (Alles mit DoIfs)

D3ltorohd

Zitat von: CoolTux am 27 Juli 2020, 17:10:03
Mir würde da auf die schnelle nichts einfallen. BlockingTime könnte man nehmen aber du weißt ja nicht wann Du lüften willst.
Es wird immer ab 22 Uhr gefahren, per Timer. Also müsste ich irgendeinen Timer haben, der zwischen sagen wir 20 und 22 Uhr das Lüften blockiert. Und gegebenenfalls danach das Lüften nachholt, sofern in der Zeit die Fenster aufgemacht wurden.

Zitat von: crusader85 am 27 Juli 2020, 19:40:11
Ich schummle da etwas. Ich stelle, wenn die Kinder schlafen (gibt einen Knopf, der dann auch Klingel stummschaltet z.B.) die ventilatepos auf 100 Prozent und ändere sie wieder, wenn ich ins Bett gehe. Damit funktioniert es bei mir eigentlich ganz gut. Die Rollos fahren allerdings mit etwas Verspätung, aber sie verändern dann die ventilate Pos. (Alles mit DoIfs)

Das wäre noch eine Idee, mit der Lüftungsposition, diese zu ändern.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

ch.eick

Zitat von: D3ltorohd am 28 Juli 2020, 10:58:41
Das wäre noch eine Idee, mit der Lüftungsposition, diese zu ändern.
Aber bedenke, dass das ein Attribut aendert und auch gerne wieder in der fhem.cfg gespeichert werden moechte.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

D3ltorohd

Zitat von: ch.eick am 28 Juli 2020, 11:03:13
Aber bedenke, dass das ein Attribut aendert und auch gerne wieder in der fhem.cfg gespeichert werden moechte.

Ich würde das versuchen über ioBroker zu ändern, auch per Timerscript.
Base : Intel NUC Debian 9, FHEM aktuell || Zigbee (Coordinator FW Z-Stack 1.2 default Koenkk) || MaxCUL (culfw V 1.67 nanoCUL868) || SIGNALduino 433MHz (V 3.3.2.1-rc8 ) || Shelly s1

ch.eick

Zitat von: D3ltorohd am 28 Juli 2020, 11:08:44
Ich würde das versuchen über ioBroker zu ändern, auch per Timerscript.
Der Weg der Aenderung waere egal, bei der Aenderung von Attributen zeigt bei mir FHEM immer an, das die Config nicht gesichert wurde.
Ich hatte sowas auch irgendwo im Forum mal gelesen.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

flummy1978

Hallo Markus,

Zitat von: meier81 am 24 Juli 2020, 11:22:00
Hi und guten Morgen,

ich hab mal eine Frage bezüglich des shadings. Bei mir funktioniert soweit alles so wie es soll, habe zur Zeit nur etwas Probleme mit den "Fahrzeiten" der Rollläden. Ich habe z.B. auf der Ostseite 5 Rollläden die zeitgleich ins shading fahen, siehe hier:

2020.07.24 08:17:04 3: SIGNALduino: JaroLift set up 9
2020.07.24 08:17:04 3: SIGNALduino: JaroLift set up 8
2020.07.24 08:17:04 3: SIGNALduino: JaroLift set up 5
2020.07.24 08:20:54 3: SIGNALduino: JaroLift set up 6
2020.07.24 08:20:54 3: SIGNALduino: JaroLift set up 7


da noch niemand darauf Bezug genommen hat, meine (vielleicht auch doofe) Idee dazu:

So direkt aus dem Kopf heraus, würde mir da nichts ASC spezifisches einfallen, was die Verzögerung möglich machen würde, außer: Wie wäre es damit diesen "Überlauf" entweder:

- Extern lösen (JaroLift set up XX - XX Abfangen und dann setzen, wenn gerade kein anderes Gerät drauf zugreift) - Hätte den Vorteil, dass Du dann auch 2 (oder mehr) Jalousieen von Hand fahren könntest ohne dass es zu diesem Überlauf käme (Brächte allerdings ein wenig programmierfähigkeit voraus - wäre dafür global einsetzbar)

- den Shading Zeitpunt zu manipulieren indem Du ASC_Shading_WaitingPeriod etwas veränderst: z.B: 600 620 640 660 ....(oder entsprechend an Deine Zeiten angepasst)  Dann hättest Du beim Beschatten immer eine 20 sekündige und beim entschatten mind 10 Sek verzögerung  zwischen den Fahrzeiten -WENN alle auf die gleichen Trigger wie Sonne, Helligkeit etc reagieren.

Viele Grüße
Andreas