[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.6.x

Begonnen von CoolTux, 27 April 2019, 08:04:52

Vorheriges Thema - Nächstes Thema

JHo

Zitat von: FunkOdyssey am 13 Juni 2019, 11:28:17
- ASC fährt runter (shading in)
- ich fahre wieder hoch
- ASC fährt wieder runter
Wird denn deine manuelle Fahrt erkannt? Das klingt doch sehr danach, als ob nicht... müsste im showShuttersInformations als lastDrive stehen.
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120


CoolTux

Zitat von: FunkOdyssey am 13 Juni 2019, 11:28:17
Hat sich in den letzten Updates irgendetwas bzgl. der Beschattung geändert? Aktuell habe ich 0.6.17 aktiv.
Ich kämpfe hier gerade gegen Windmühlen:
- ASC fährt runter (shading in)
- ich fahre wieder hoch
- ASC fährt wieder runter

Ich habe das Debugging mal aktiviert und beobachte.

Direkt in der Shading Funktion hat sich nichts geändert. Drum Rum habe ich in Bezug auf Shading aber einiges gemacht. Gerade wenn Events kommen wie home oder absent.
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

FunkOdyssey

Die Events kommen vom Astro-Modul und vom Helligkeitssensor.
Aber wenn ich manuell eingegriffen habe, so sollte ASC doch die Finger anschließend davon lassen, oder?

Außerdem habe ich folgende Konfiguration:
blockingTime in den Rollo-Devices ist: default
ASC_blockAscDrivesAfterManual im ASC-Device ist: 1


CoolTux

Da du wahrscheinlich ganz hoch gefahren hast ist das eine bekannte Position. Daher greift
ASC_blockAscDrivesAfterManual im ASC-Device ist: 1
nicht. Aber zu mindest sollte er eine Stunde 20 min blockieren.
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

felskrone


Hallo zusammen,

ich habe letzte Woche meine zuvor zusammengebastelte Rolladen-Steuerung durch ASControl ersetzt.
Vielen Dank an CoolTux für die viele Arbeit und die Bereitschaft, das Ganze allen zur Verfügung zu stellen und auch noch so engagiert zu supporten!

Insgesamt finde ich mich langsam zurecht, habe aber an machen Stellen immer wieder Schwierigkeiten:


       
  • Nachvollziehbarkeit: Ich kenne die Option debug - trotzdem fällt es oft schwer, das Verhalten nachzuvollziehen, insbesondere bei der Beschattung und diesen ganzen Blocking-Zeiten. Hier fehlt mir eine funktionale Beschreibung.
  • Aktualität der Doku: Ich habe eben ein Update durchgeführt und gesehen, dass ein neues Attribut eingefügt wurde - aber welches und wozu? Welche Quelle beinhaltet die aktuellste Doku, ist also führend? Die Commandref (deutsch oder englisch) oder das Wiki?
  • im Wiki gibt es ein Attribut für Rolladen (ASC_Pos_after_ComfortOpen) die Benennung ist super, da weiß man was es steuern soll, aber in FHEM wird mit das Attribut nicht angezeigt... gibt es das nun oder nicht?
  • ASC_BlockingTime_afterManual welche Aktion schaltet wieder in den Auto-Modus zurück, wenn einmal manuell gefahren wurde?
  • eine Stunde blocken nach manueller Fahrt, ist das ein Default-Wert? Kann man die Dauer einstellen? Steht das irgendwo in der Doku?
Ich hoffe, ich stelle keine Fragen, die an anderer Stelle schon beantwortet wurden oder in der Doku stehen - ich habe zumindest viel gelesen und versucht selbst zu finden...
___________________________
FHEM 5.8 auf Raspi 1B und HMLAN

FunkOdyssey

Zitat von: CoolTux am 13 Juni 2019, 13:06:26
Da du wahrscheinlich ganz hoch gefahren hast ist das eine bekannte Position. Daher greift
ASC_blockAscDrivesAfterManual im ASC-Device ist: 1
nicht. Aber zu mindest sollte er eine Stunde blockieren.

Natürlich habe ich ganz hochgefahren. Ich bleibe ja nicht dabei stehen und stoppe 1% vorher. 😄
Ehrlich gesagt, ist das Thema "manuelle Übersteuerung" wirklich unglücklich. Wir hatten diese Diskussion ja schon häufiger bei den normalen Fahrten. Nun bei der Beschattung erneut.
Kann ASC nicht einfach die Finger davon lassen, wenn man manuell eingegriffen hat?

Die Rollos werden teilweise schon 10min nach der manuellen Korrektur wieder runtergefahren. Häufig aber zwischen 20-30min. Halt je nach Erscheinen des Events.

Jetzt einmal kurz andersherum gefragt:
Selbst wenn blockingTime berücksichtigt werden würde; wie läuft das bei euch allen im Alltag? Belässt ihr jedesmal die Rollos auf der Beschattungsposition? Greift ihr wirklich nie manuell ein?



CoolTux

Zitat von: felskrone am 13 Juni 2019, 13:29:11
Hallo zusammen,

ich habe letzte Woche meine zuvor zusammengebastelte Rolladen-Steuerung durch ASControl ersetzt.
Vielen Dank an CoolTux für die viele Arbeit und die Bereitschaft, das Ganze allen zur Verfügung zu stellen und auch noch so engagiert zu supporten!

Insgesamt finde ich mich langsam zurecht, habe aber an machen Stellen immer wieder Schwierigkeiten:


       
  • Nachvollziehbarkeit: Ich kenne die Option debug - trotzdem fällt es oft schwer, das Verhalten nachzuvollziehen, insbesondere bei der Beschattung und diesen ganzen Blocking-Zeiten. Hier fehlt mir eine funktionale Beschreibung.
  • Aktualität der Doku: Ich habe eben ein Update durchgeführt und gesehen, dass ein neues Attribut eingefügt wurde - aber welches und wozu? Welche Quelle beinhaltet die aktuellste Doku, ist also führend? Die Commandref (deutsch oder englisch) oder das Wiki?

Führend ist für ASC immer die deutsche Commandref, Dank unserem Christoph sollte auch die englische Commandref der deutschen in Aktualität gleich sein.


Zitat von: felskrone am 13 Juni 2019, 13:29:11
   
  • im Wiki gibt es ein Attribut für Rolladen (ASC_Pos_after_ComfortOpen) die Benennung ist super, da weiß man was es steuern soll, aber in FHEM wird mit das Attribut nicht angezeigt... gibt es das nun oder nicht?

Das Attribut heißt aktuell ASC_ComfortOpen_Pos.


Zitat von: felskrone am 13 Juni 2019, 13:29:11
   
  • ASC_BlockingTime_afterManual welche Aktion schaltet wieder in den Auto-Modus zurück, wenn einmal manuell gefahren wurde?
  • eine Stunde blocken nach manueller Fahrt, ist das ein Default-Wert? Kann man die Dauer einstellen? Steht das irgendwo in der Doku?

ASC_BlockingTime_afterManual bedeutet das für den Wert in Sekunden jeglische Aktionen unterdrückt werden. Es wird erst wieder aktiv gefahren wenn die Zeit überschritten ist.
Der Wert von einer Stunde ist ein default Wert und zwar der default Wert welcher gesetzt ist wenn das Attribut nicht gesetzt wurde.
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

FunkOdyssey


CoolTux

Zitat von: FunkOdyssey am 13 Juni 2019, 14:15:22
Natürlich habe ich ganz hochgefahren. Ich bleibe ja nicht dabei stehen und stoppe 1% vorher. 😄
Ehrlich gesagt, ist das Thema "manuelle Übersteuerung" wirklich unglücklich. Wir hatten diese Diskussion ja schon häufiger bei den normalen Fahrten. Nun bei der Beschattung erneut.
Kann ASC nicht einfach die Finger davon lassen, wenn man manuell eingegriffen hat?

Die Rollos werden teilweise schon 10min nach der manuellen Korrektur wieder runtergefahren. Häufig aber zwischen 20-30min. Halt je nach Erscheinen des Events.

Jetzt einmal kurz andersherum gefragt:
Selbst wenn blockingTime berücksichtigt werden würde; wie läuft das bei euch allen im Alltag? Belässt ihr jedesmal die Rollos auf der Beschattungsposition? Greift ihr wirklich nie manuell ein?

Also wenn ich Dich richtig verstehe. Lässt Du das Rollo in die Beschattung fahren und wenn Dir danach ist fährst Du wieder aus der Beschattung raus. Warum? Dann kannst Du auch die automatische Beschattung ganz lassen und von Hand Beschatten wenn Du es brauchst. Oder verstehe ich das falsch.
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

eurofinder

@CoolTux:
ZitatDa du wahrscheinlich ganz hoch gefahren hast ist das eine bekannte Position. Daher greift
ASC_blockAscDrivesAfterManual im ASC-Device ist: 1
nicht. Aber zu mindest sollte er eine Stunde blockieren.
Würde mich freuen, wenn du das nochmals überdenkst. Von Anwenderseite fahre ich den Rollladen, wenn er in shading in ist, manchmal manuell auch komplett nach oben (bei mir Position 0) und nicht auf eine davon abweichende Position. Ich denke alles davon abweichende würde auch den WAF nicht dienlich sein.
Es sollte doch softwaretechnisch machbar sein, dass nachdem erstmalig shading in erfolgt ist, ein erneutes shading in zu unterbinden, wenn vor Eintritt von shading out, manuell eine Positionsveränderung vorgenommen wurde.
Gruß
eurofinder
RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

CoolTux

Ich habe für die Beschattung nun eine kleine Änderung vorgenommen. Vorerst nur bei mir lokal, wenn ich es getestet habe gebe ich es im Devel frei damit Ihr einmal testen könnt.
Ich habe es nun so gemacht das kein Fahrbefehl kommt sofern die Rollos nicht vor dem "shading in" in "shading out" gegangen sind. Damit sollte es möglich sein das Rollo bei Beschattung in eine andere Position zu fahren und diese sollte behalten werden so lange kein "shading out" passiert ist oder ein anderes Event wie Wind oder Regen.

Ich teste die Tage ob die Beschattung generell klappt damit und ob der gewünschte Effekt bezüglich nicht immer in die Beschattung fahren erzielt wird.
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: FunkOdyssey am 13 Juni 2019, 14:15:22
Natürlich habe ich ganz hochgefahren. Ich bleibe ja nicht dabei stehen und stoppe 1% vorher. 😄
Ehrlich gesagt, ist das Thema "manuelle Übersteuerung" wirklich unglücklich. Wir hatten diese Diskussion ja schon häufiger bei den normalen Fahrten. Nun bei der Beschattung erneut.
Kann ASC nicht einfach die Finger davon lassen, wenn man manuell eingegriffen hat?

Die Rollos werden teilweise schon 10min nach der manuellen Korrektur wieder runtergefahren. Häufig aber zwischen 20-30min. Halt je nach Erscheinen des Events.

Jetzt einmal kurz andersherum gefragt:
Selbst wenn blockingTime berücksichtigt werden würde; wie läuft das bei euch allen im Alltag? Belässt ihr jedesmal die Rollos auf der Beschattungsposition? Greift ihr wirklich nie manuell ein?


Bitte einmal die aktuelle Devel Version testen. Jetzt sollte Deine manuelle Fahrt nicht mehr einfach so korrigiert werden, erst wenn wieder komplett die Beschattung einmal beendet wurde und dann neu beschattet wird.
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

eurofinder

@CoolTux:
ZitatJetzt sollte Deine manuelle Fahrt nicht mehr einfach so korrigiert werden, erst wenn wieder komplett die Beschattung einmal beendet wurde und dann neu beschattet wird.
Ist das so gemeint, dass eine der Voraussetzungen für Beschattung nicht mehr erfüllt sein darf, die somit shading-out aktiviert?

Dazu eine Frage:
Ausgangsposition ist 0. Sagen wir mal shading-in-Position ist 70 (100=geschlossen). Ich fahre dann manuell auf Position 50. Wird dann nach Beenden von Shading-out der Rollladen wieder auf Position 0 gefahren oder verbleibt der bei Position 50?

Gruß und 1000 Dank für dein tolles Modul und dein Engagement
eurofinder
RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

CoolTux

Zitat von: eurofinder am 13 Juni 2019, 17:41:13
@CoolTux:Ist das so gemeint, dass eine der Voraussetzungen für Beschattung nicht mehr erfüllt sein darf, die somit shading-out aktiviert?

Dazu eine Frage:
Ausgangsposition ist 0. Sagen wir mal shading-in-Position ist 70 (100=geschlossen). Ich fahre dann manuell auf Position 50. Wird dann nach Beenden von Shading-out der Rollladen wieder auf Position 0 gefahren oder verbleibt der bei Position 50?

Gruß und 1000 Dank für dein tolles Modul und dein Engagement
eurofinder

Berechtigte Frage. Muss ich mir in Ruhe anschauen.
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