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

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

Vorheriges Thema - Nächstes Thema

edition

Zitat von: flummy1978 am 03 August 2020, 01:43:57
Guten Abend alleine, edition

Bitte unbedingt das beachten: Unbedingt vor dem ersten Post lesen


die Glaskugel sagt ..... Keine unterschiedlichen Positionen, die Zeiten passen nicht zu den Einstellungen (ASC_AutoModeUp/Down - ASC_Down/Up usw oder kein localisation Device beim Versuch über Sonnenstand zu fahren )  und und und und mist nu is die Glaskugel kapputt  ;)
Sprich man muss schon wissen, was Du alles gemacht hast Wiki & Commandref studiert ? Komisch dass die Beschattung angeblich funktioniert und der Rest quasi gar nicht - Sicher dass die Beschattung vom ASC kommt ? (oder noch alte leichen aus anderen Modulen / Selbstbauten ? )
Bitte lists jeweils vom ASC Modul und den Rollos oder zumindest einem. Wenn eines fährt, werden die anderen sicherlich auch schnell zum laufen gebracht.

Auch wenn ich selbst sicherlich noch kein Profi bin, alles zu finden woran es liegt... möchte ich helfen und versuche es auch. Aber ohne Infos ist das Ganze dann doch sehr schwierig.... und nur mal ein Tipp von mir (weil das Modul so mächtig ist, dass man sich selbst schnell ein Beinchen stellt: Speziell als Anfänger (aber eigentlich gar)NICHT alles auf einmal probieren zu aktivieren. Imho wäre mein Vorschlag Block / Lock etc erst mal außenvor zu lassen. Dann Zeiten / Beschattung etc einstellen und dann erst Funktion für Funktion in Betrieb nehmen

Viele Grüße
Andreas

Hat sich soeben erledigt. Die Rollläden fahren jetzt, wie sie programmiert sind.
Woran es lag, weiß ich nicht wiklich. Nach dem Sonntäglichen update und fhem neustart habe ich mit dem Rolladen der Terassentür ein wenig herumgetestet. Da hat alles auf Anhieb funktioniert. Am Abend sind alle Rolläden gemäß Programmierung herunter gefahren und heute Morgen wieder hoch.
Weil das Tool so umfangreich ist und an mehreren Stellen Einstellungen vorgenommen weden können, wusste ich nicht, was ich posten soll. Darum wollte ich erst fragen, welche Informationen von euch benötigt werden, um einen möglichen Fehler zu finden.

Gruß
edition

CoolTux

Hallo Leute,

Ich habe die letzten Wochen Eure Posts zum großen Teil gelesen und auch mir schon das ein oder andere auf Github angeschaut.
Leider fühle ich mich aktuell aus persönlichen Gründen noch nicht in der Lage größere Anfragen zu bearbeiten. Tut mir wirklich leid. Aber keine Sorge, weiter gehen wird es. Zu mindest erstmal die Bugfixes. Ich weiß nur noch nicht wann.


Grüße
Marko
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

flummy1978

Guten morgen,

@ms_steini: Ich habs selbst noch nicht eingerichtet, aber nette Idee für Nachtschichtler (momentan fahre ich von Hand, bzw spiel ein wenig mit dem Roommate device)

onTopic: Ist 9 Uhr auch die sonstige "Feiertags / WE Zeit? - Dann würde mit Zitat aus: https://wiki.fhem.de/wiki/AutoShuttersControl#Basics
ZitatWenn Feiertage berücksichtigt werden sollen: Ein oder mehrere holiday2we-Angaben in global samt entsprechender holiday-Dateien[2] [3].

.... schon mal Deine Schulferienproblematik lösen. 

Was die Nachtschicht angeht *grübel* Ich bin mir sicher es geht irgendwie einfacher (irgendwer wird da sicher eine nette Idee haben) aber vielleicht hilft es schon mal in die Richtung:

ZitatASC_Time_Up_Early       05:00    Sonnenaufgang frühste Zeit zum Hochfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
ASC_Time_Up_Late       08:30    Sonnenaufgang späteste Zeit zum Hochfahren  !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!

D.h. wenn Du Dich ein wenig mit Perl auskennst und dort eine Abfrage machst mit "Nachtschicht Ja -> 14 Uhr nein -> 8 Uhr" würde es wohl funktionieren.....

@edition: Freut mich sehr, dass es allem Anschein nach genauso fährt wie gewünscht :) Wahrscheinlich war der simple Neustart nach dem Update des Rätsels Lösung ;) (Bin davon ausgegangen, dass Du den schon hattest,  weil Shading ja auch funktioniert hat)

@CoolTux: Die Leute vermissen Dich schon sehr wie man sieht,.... ABER privates hat sowas von Vorrang, (hoffe sehr dass es nichts schlimmes ist) also mach in Ruhe und dann wird es bald sicher auch mit neuem Elan möglich sein. Wünsche Dir alles Gute.

Viele Grüße
Andreas

Beta-User

Das Nachtschicht-Thema könnte ggf. auch über den ROOMMATE-Status gelöst werden?

@CoolTux: Laß dir Zeit!

@all: ggf. wäre es gut, wenn wir CoolTux irgendwie die Arbeit erleichtern könnten. Meinem persönlichen Eindruck nach ging das hier über die diversen Threads leider teils ziemlich wirr durcheinander. Vielleicht hat jemand eine Idee, wie wir eine Art Vorklärung etablieren könnten, damit CoolTux sich dann eher auf "Second-level-support" konzentrieren/beschränken könnte?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

flummy1978

Zitat von: Beta-User am 03 August 2020, 10:26:45
@all: ggf. wäre es gut, wenn wir CoolTux irgendwie die Arbeit erleichtern könnten. Meinem persönlichen Eindruck nach ging das hier über die diversen Threads leider teils ziemlich wirr durcheinander. Vielleicht hat jemand eine Idee, wie wir eine Art Vorklärung etablieren könnten, damit CoolTux sich dann eher auf "Second-level-support" konzentrieren/beschränken könnte?

Das ist nicht nur Dein persönlicher Eindruck, sondern meiner auch (früher) schon gewesen. Ich habe bei meinen Versuchen das Ganze einzurichten immerwieder drauf gepocht, zu erfahren wie man auf den Fehler kommen könnte um eben NICHT jeden Beitrag auf 100Seiten++ ansteigen zu lassen. Ich habe in meinem Fall sogar noch vergleichsweise WENIG eingestellt und bin sicher, auch viele Dinge nicht zu erkennen oder falsch zu machen, aber ich versuche dennoch die Hilfe die mir gegeben wurde, auch weiter zu geben.
CoolTux hat mit seine Fürsorge und mega Support leider auch dafür gesorgt, dass kaum mehr jemand Wiki oder Commandref befragt hat, sondern direkt Fragen gepostet hat, weil es bequemer war und bedingt durch CoolTux`Einsatz auch die Erfolgsversprechendere Variante war.

Wie könnte man es am besten Abfangen ... *grübel* die ersten Ideen wären:

Das einfachste für Anfänger wäre wohl eine Schritt für Schritt Einrichtung eines Rollos, mit Erklärungen warum wieso weshalb. Da ich aber eher zu der Try or Error Fraktion gehöre, wäre ich da wohl nicht in der lage dazu.

Was aber in meinen Augen 90% der Fehler erschlagen würde, wären markante Infos (Im Modul bsw wenn man entsprechende Attribute auswählt) dass es zwei GANZ WICHTIGE Einschränkungen beim Setup gibt:
1. Positionen dürfen sich innerhalb eines Rollos nicht überschneiden - Auch ASC_Closed_Pos 100 night 99 ASC_Shading_Pos 98 ASC_ComfortOpen_Pos 97 usw... sind bereits unterschiedliche Positionen.
2. Sensoren dürfen sich im ASC Device nicht überschneiden - D.h. wurde bereits die Temperatur vom Wettermodul genommen so muss für die Regen oder Windinfos ein anderes Device / Dummy zwischen gelegt werden.

Wenn man das in die Commandref / Wiki übernehmen könnte, (oder auch bei der Attribut Auswahl als Hilfe (vergesse immer wieder der Teil heisst -.-)) dass die Leute immer und immer und immerwieder drüber stolpern, bin ich mir sicher, dass hier bereits sehr viele Anfragen sich von vorne herein erledigen. Ich hatte bereits den Beschattung Teil in der Wiki angepasst, weil viele sicherlich erwarten, dass beim Überschreiten von Helligkeitsgrenzwerten SOFORT gefahren wird. Aber das ist erstmal nur ein kleine Tropfen auf dem heißen Stein ;)

Wenn ich helfen kann, wie gesagt gern, "versuche dennoch die Hilfe die mir gegeben wurde, auch weiter zu geben..."

Viele Grüße
Andreas

ms_steini

Zitat von: flummy1978 am 03 August 2020, 10:00:36
Guten morgen,

@ms_steini: Ich habs selbst noch nicht eingerichtet, aber nette Idee für Nachtschichtler (momentan fahre ich von Hand, bzw spiel ein wenig mit dem Roommate device)

Was die Nachtschicht angeht *grübel* Ich bin mir sicher es geht irgendwie einfacher (irgendwer wird da sicher eine nette Idee haben) aber vielleicht hilft es schon mal in die Richtung:

D.h. wenn Du Dich ein wenig mit Perl auskennst und dort eine Abfrage machst mit "Nachtschicht Ja -> 14 Uhr nein -> 8 Uhr" würde es wohl funktionieren.....
......

Das ist ja eine super Idee, klar mit Perl kann ich den ics Kalender auf Nachtdienst abfragen und die entsprechenden Uhrzeiten setzen, das ginge dann natürlich auch mit den Schulferien ical kalender.
die Schulferien mit in Global holiday2we packen ist schlecht, da ja dann alle Rollos betroffen sind. Dann scheint mir das über Perl irgendwie angenehmer zu sein.

Besten Dank für den anschupser


ich teste das mal, sollte eigentlich so schon funktionieren.
ASC_Time_Up_Early  {(fhem('get Schichtplan events format:custom="$U" limit:from=-1d,to=0d') =~ "_Nacht" ? "14:00":"06:30")}
ASC_Time_Up_Late   {(fhem('get Schichtplan events format:custom="$U" limit:from=-1d,to=0d') =~ "_Nacht" ? "14:00":"07:30")}




flummy1978

Zitat von: ms_steini am 03 August 2020, 12:04:38
Besten Dank für den anschupser


ich teste das mal, sollte eigentlich so schon funktionieren.
ASC_Time_Up_Early  {(fhem('get Schichtplan events format:custom="$U" limit:from=-1d,to=0d') =~ "_Nacht" ? "14:00":"06:30")}
ASC_Time_Up_Late   {(fhem('get Schichtplan events format:custom="$U" limit:from=-1d,to=0d') =~ "_Nacht" ? "14:00":"07:30")}

Sehr gern ... da Du scheinbar noch mehr in Perl drauf hast als ich, war das wohl der richtige Wink ;)

Da würden mich die Ergebnisse sehr interessieren. Sollte das so funktionieren, hättest Du meine Nachtschichtproblematik gleich mal mit gelöst  8)

VG
Andreas

Beta-User

Zitat von: flummy1978 am 03 August 2020, 11:24:20
Wie könnte man es am besten Abfangen ... *grübel* die ersten Ideen wären:

Das einfachste für Anfänger wäre wohl eine Schritt für Schritt Einrichtung eines Rollos, mit Erklärungen warum wieso weshalb. Da ich aber eher zu der Try or Error Fraktion gehöre, wäre ich da wohl nicht in der lage dazu.

Was aber in meinen Augen 90% der Fehler erschlagen würde, wären markante Infos (Im Modul bsw wenn man entsprechende Attribute auswählt) dass es zwei GANZ WICHTIGE Einschränkungen beim Setup gibt:
1. Positionen dürfen sich innerhalb eines Rollos nicht überschneiden - Auch ASC_Closed_Pos 100 night 99 ASC_Shading_Pos 98 ASC_ComfortOpen_Pos 97 usw... sind bereits unterschiedliche Positionen.
2. Sensoren dürfen sich im ASC Device nicht überschneiden - D.h. wurde bereits die Temperatur vom Wettermodul genommen so muss für die Regen oder Windinfos ein anderes Device / Dummy zwischen gelegt werden.

Grundsätzlich fände ich es auch zielführend, wenn wir den Wiki-Artikel wieder auf einen aktuellen Stand bringen könnten, und irgendwo zentrale häufige Fehlerquellen benennen würden. Was die Vorgehensweise dazu angeht, fände ich ein (detaillierteres) Einrichtungsbeispiel mit einer Variante (rein zeitgesteuert ohne brightness?) und einem normalen Rollladen und einer Terrassentür einen guten Anfang; dann kann man ggf. davon ausgehend dann noch Bewohner und Brightness-Varianten ergänzen (oder mit brightness beginnen).
Ein paar Hinweise habe ich grade reingebastelt, hoffe, das paßt auch inhaltlich.

Ansonsten habe ich den Eindruck, dass jede Überarbeitung von jemandem was bringt, der sich in letzter Zeit intensiver mit der Modulfunktionalität auseinandergesetzt hat. Besser eine halbwegs aktuelle 65%-Lösung als zu lange diesen (mMn. zwischenzeitlich weitgehend überholten) Stand...
(Ich werd's für's erse nicht machen, denn zum einen bin ich ziemlich raus, zum anderen habe ich noch eine andere größere Doku-Baustelle.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

kjmEjfu

Zitat von: flummy1978 am 03 August 2020, 12:18:03
Da würden mich die Ergebnisse sehr interessieren. Sollte das so funktionieren, hättest Du meine Nachtschichtproblematik gleich mal mit gelöst  8)

ich würde solche Sachen, wie auch Schulferien o.ä. gar nicht mehr unterschiedlichen Fahrzeiten lösen.
Habe das bei mir wie folgt gelöst:

- Rollos in normalen Aufenthaltsräumen (Wohnzimmer, Küche, ...) haben ASC_Time_Down_Early, ASC_Time_Down_Late, ASC_Time_Up_Early, ASC_Time_Up_Late und ASC_Time_Up_WE_Holiday definiert. Grundsätzlich fahren sie aber per brightness gesteuert.
- Rollos in Schlafräumen sind analog angelegt, haben aber zusätzlich in ASC_Roommate_Device einen (Kinderzimmer) oder zwei (Schlafzimmer) Einträge. Dadurch fahren die Rollos abends zum Brightness oder Time_Down_Late Ereignis runter - oder aber, wenn der Roommate vorher den Status auf "asleep" gesetzt hat. Hoch fahren die Rollos morgen dadurch erst, wenn der Roommate auf "awoken" gewechselt hat und gleichzeitig brightness und mindestens Time_Up_Early erreicht ist. Hat man zwei Roommates in einem Rollos hinterlegt, müssen übrigens beide wach sein, bevor das Rollo fährt.
- Rollos in kritischen Räumen (z.B. Flur zwischen den Schlafräumen) ist wie die Schlafräume angelegt. Im ASC_Roommate_Device stehen prinzipiell alle Familienmitglieder, außer die Tiefschläfer die nix hören ;-)

Wenn nun jemand meint morgens länger schlafen zu müssen als ASC_Time_Down_Late vorgibt, so kann er das machen und wird nicht durch hochfahrende Rollos geweckt. Ebenso kann er, wenn er abends (oder sogar schon nachmittags) früher schlafen will, dies machen und das Rollo fährt runter.
Ist eine Person, die in einem ASC_Roommate_Device hinterlegt ist, nicht zu hause (away oder absent), so fahren die ihm zugehörigen Rollos so als wäre in ASC_Roommate_Device gar nichts eingetragen. In meinem Fall also nach brightness innerhalb der definierten Zeitfenster.
Ist super flexibel und es muss nichts mit irgendwelchen Schichtplänen, wechselnden Arbeitstagen u.ä. verändert werden. Wenn natürlich das Rollo gleichzeitig der sanfte Wecker sein soll, so muss man etwas anpassen, geht aber auch ;-)
Migriere derzeit zu Home Assistant

ms_steini

Zitat von: kjmEjfu am 03 August 2020, 16:12:59
.....
- Rollos in Schlafräumen sind analog angelegt, haben aber zusätzlich in ASC_Roommate_Device einen (Kinderzimmer) oder zwei (Schlafzimmer) Einträge. Dadurch fahren die Rollos abends zum Brightness oder Time_Down_Late Ereignis runter - oder aber, wenn der Roommate vorher den Status auf "asleep" gesetzt hat. Hoch fahren die Rollos morgen dadurch erst, wenn der Roommate auf "awoken" gewechselt hat und gleichzeitig brightness und mindestens Time_Up_Early erreicht ist.
............

hört sich auch gut an, aber wie wechselt denn der Status auf "awoken", irgendwoher muss doch die Information kommen. ?? ist mir jetzt irgendwie nicht klar

kjmEjfu

Zitat von: ms_steini am 03 August 2020, 17:29:49
hört sich auch gut an, aber wie wechselt denn der Status auf "awoken", irgendwoher muss doch die Information kommen. ?? ist mir jetzt irgendwie nicht klar

das hat primär mit Roommate, weniger mit ASC zu tun ;-)
Bei uns hat jeder am Bett einen Schalter (kann man z.B. die günstigen von Aqara nehmen) und mit denen kann man (per notify) "gotosleep" bzw. "awoken" schalten. Ist auch in der Kombination mit Homemode (oder DOIF) sehr nützlich, weil man dann automatisch Lichter ausschalten kann usw.
https://fhem.de/commandref_DE.html#ROOMMATE
Migriere derzeit zu Home Assistant

ms_steini

oh ne, sorry. das ist gar nicht nach meinem Geschmack. Wenn ich morgens um 06:00 vom Nachdienst nach Hause komme, muss ich ja noch daran denken einen Knopf zu drücken, das geht garantiert in die Hose.
Ich mag's da lieber automatisiert.

edition

Oh ja, das Nachtschichthema interessiert mich auch. Gerne auch über Onlinekalender. Das macht es vollautomatisch und auch ein wenig flexibel, weil man die Tage an denen man z.b. Urlaub hat ja anpassen kann.
Ideal wäre eine Auswahlmöglichkeit beim Attribut ASC_Up. Soetwas, wie Calendar oder so. Vielleicht kann man aber auch mit dem Kalender den Roomate Status ändern und darüber die Zeiten steuern.

hhhdg

Moin,

erstmal vielen Dank für das coole Modul - ich habe meine eigenen Funktionen so ziemlich alle mittlerweile deaktiviert und bin in den letzten Wochen nach und nach auf ASC gewechselt, weil einfach viel mehr Sonderfälle bereits abgedeckt sind, die ich bei mir immer erst nach dem ersten Auftreten versucht habe zu korrigieren (und dann für Ewigkeiten nicht wieder aufgetreten sind).

Ein Problem(chen) habe ich allerdings noch mit ASC: Ich benutze Eltako-Aktoren für meine Rollos, also mit der Logik 0=offen 100=geschlossen und bei mir Funktionieren die ThreeState Fenstergriffe nicht wie gewünscht. "tilted" führt erfolgreich zu "ventilate", aber "open" bleibt stumm im Log-File mit DEBUG auf 1.

Im Source-Code habe ich dann rausgefunden, dass meine gewählte ComfortOpenPos mit dem Wert 0, also "ganz auf", dazu führt.
Die Zeile die ich meine wäre diese hier: https://github.com/fhem/AutoShuttersControl/blob/338db55e05c1ea09ac22738972ff663bd040a36a/lib/FHEM/Automation/ShuttersControl/EventProcessingFunctions.pm#L483:
if ( defined($posValue) && $posValue ) {

Der zweite Term schägt damit immer fehl und der Block kommt nicht zur Ausführung. Ich behelfe mir jetzt mit ComfortOpenPos auf 1, aber gibt es eine Grund, den ich nicht sehe, warum der zweite Term im if steht?

flummy1978

Zitat von: hhhdg am 03 August 2020, 22:56:39

Im Source-Code habe ich dann rausgefunden, dass meine gewählte ComfortOpenPos mit dem Wert 0, also "ganz auf", dazu führt.

Auch wenn ich nicht weiß ob das der endgültige Fehler ist...Glaskugel vermutet etwas das 3 Postings darüber steht:
Zitat von: flummy1978 am 03 August 2020, 11:24:20
Was aber in meinen Augen 90% der Fehler erschlagen würde, wären markante Infos (Im Modul bsw wenn man entsprechende Attribute auswählt) dass es zwei GANZ WICHTIGE Einschränkungen beim Setup gibt:
1. Positionen dürfen sich innerhalb eines Rollos nicht überschneiden - Auch ASC_Closed_Pos 100 night 99 ASC_Shading_Pos 98 ASC_ComfortOpen_Pos 97 usw... sind bereits unterschiedliche Positionen.
2. Sensoren dürfen sich im ASC Device nicht überschneiden - D.h. wurde bereits die Temperatur vom Wettermodul genommen so muss für die Regen oder Windinfos ein anderes Device / Dummy zwischen gelegt werden.

Vielleicht ist es das ja bereits :)

Grüße
Andreas