[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

[Beta-User]

Moin,

nachdem ich am WE mal dazu gekommen bin, mir das eine oder andere am Verhalten der Rollläden mit der Version 0.4.0.11beta3 anzusehen, ein paar Anmerkungen dazu, selbst wenn es ggf. bereits überholt sein sollte:

- Das morgendliche Öffnungsverhalten am WE ist nicht erwartungsgemäß (WE-up-Time liegt vor der spätesten allgemeinen): Die Rollläden fahren gar nicht, einzige Ausnahme scheinen solche zu sein, die bereits weiter geöffnet sind als sie sein sollten (ASC-Typ 2-Rollläden). Die normale Fahrt unter der Woche ist dagegen ok. Beim Schreiben gemerkt: Die Rollläden haben sich wieder geschlossen! Leider habe ich die manuell wieder aufgemacht, aber einer stand noch auf night close? Dann habe ich die Shutters-Info angesehen: Da stand jetzt bei allen die WE-Öffnen Zeit als nächster Timer für heute morgen drin...

- Fensterkontakte:
-- (Nicht im Detail untersucht, aber) nach wie vor komisch kommt mir das Verhalten der Fensterkontakte vom Typ threeState vor. Da passiert mir irgendwie zu wenig (comfort ist gesetzt)...
-- Bei einer Tür mit Jalousie (=lange Laufzeit) habe ich auch einen twoState. Klappt gut mit dem Öffnen, allerdings bin ich manchmal dann mit dem Schließen schneller als die Jalousie zum Erreichen der Fenster-Offen-Position. Statt direkt wieder umzukehren oder das bei Erreichen der Zielposition zu tun, passiert nichts mehr.
-- (In dem Zusammenhang: die Zeit für das Erkennen einer manuellen Fahrt ist in manchen Fällen m.E. zu knapp; evtl. müßte man das auch irgendwie ändern. Ideen dafür: konfigurierbare Zeit (via Attr. im ASC (all:default bzw. Rollladendevice1:value1 Rollladendevice2:value2)), nach Aktor-Typ (HM sendet direkt ein motor-Event)...

- Das Wind-Verhalten ist zu Event-Basiert:
Gestern abend war ja weiterhin ausreichend Wind (eigentlich sogar für alle Rollläden, nicht nur meinen Tester); trotzdem sind die Rollläden alle zugefahren.

Besonders der letzte Punkt hat mich (ausgehend vom gestrigen Post von Wuppi86) zur Überlegung gebracht, ob es nicht besser wäre, für jeden Rollladen eine Art zentraler Statusliste zu haben, in der dann bei einem Event der entsprechende Teilstatus aktualisiert (oder auch gelöscht) wird und ein "genereller Prozesscode" aufgerufen wird, der dann insgesamt abgearbeitet wird.
Ins unreine: Alle möglichen blockierende Elemente werden unter Berücksichtigung ihrer Priorität abgearbeitet, wenn sie eingetragen sind, abgelaufene timer werden ggf. gelöscht (z.B. manual blocking) usw.. Diesen Code könnte man dann auch aufrufen, wenn ein timer abläuft (z.B. manual).
Was den Wunsch von Wuppi86 angeht: Evtl. wäre es eine gute Idee, zwar ein Reading für den aktuellen Zielzustand zu haben, ob man intern aber mehrere braucht ("Eigentliches Ziel": Öffnen/Schließen morgens bzw. abends, vorübergehendes Ziel: Beschattung, Lüften ...), wäre eine weitere (Vor-) Frage.

Ist schon klar, dass das zum Teil wieder kompliziert gedacht ist, ich hoffe, du kannst was mit meiner Darstellung anfangen?

[CoolTux]

Dann werden wir nach dem kleinen Attributsumbau uns der weiteren Sachen annehmen. Aber erstmal möchte ich eine funktionierende Version mit den neuen Attributen haben.

Auf alle Fälle gehen wir die Beobachtungen und Wünsche an.

[Beta-User]

Keine Eile, und wenn ich irgendwo helfen kann/soll: laß wissen...

Soll ich jetzt erst mal wieder die Normalversion installieren und die Attribute an den Rollläden entsprechend auf ASC-alt-Standard zurückschrauben, oder erst mal die Version von github-devel weiter nutzen bzw. wie lange wirst du ggf. noch benötigen für die nächste Iteration? Wenn die Rollläden wieder zugehen, ist das mit zunehmender Tageslichtdauer WAF-unfreundlich...

PS: hast du im anderen Thread gesehen, auch welche workarounds man kommen kann, um ein simples An- bzw. Ausschalten von Teilbereichen der Automatik zu realisieren ?

[CoolTux]

PS: hast du im anderen Thread gesehen, auch welche workarounds man kommen kann, um ein simples An- bzw. Ausschalten von Teilbereichen der Automatik zu realisieren ?

Ja habe gelesen 

Ich bilde mir ein das ich bis morgen eine neue Version zum testen habe. Fertig ist sie schon ich muß jetzt nur Teilbereiche testen. Wenn Du so lange warten kannst.

[Beta-User]

Ja habe gelesen 

Ich bilde mir ein das ich bis morgen eine neue Version zum testen habe. Fertig ist sie schon ich muß jetzt nur Teilbereiche testen. Wenn Du so lange warten kannst.

Kein Ding, morgen ist völlig ok, und ich nehme gerne auch "gewisse Restrisiken" in Kauf...

[CoolTux]

Sieht auch gut aus aktuell. Läuft erstmal soweit.
Will aber alles noch mal in Ruhe durchgehen.

[CoolTux]

Es darf wieder fleißig getestet werden. Bitte beachtet die deutsche Commandref bezüglich der String Vorgabe der neuen Attribute


DEVICE:READING MIN:MAX
DEVICE:READING MIN

MIN:MAX


So als Beispiel

Runterladen aus meinem eigenen Git vom Branch devel

[Beta-User]

Moin,

habe vorhin die 0.4.0.11beta26 mal installiert. Die Timer sehen im Prinzip ok aus, es ist erkannt, dass day up schon durch ist, allerdings stehen da Morgens-Timer von heute drin, die auf $we passen würden (Kontroll-Aufruf?).

Beim Umwandeln des Temp-Sensors hatte ich hinterher das Reading temperature drin; das stimmt nicht, vorher war das state (ist ein ReadingsProxy; jetzt habe ich auf das eigentliche Device umgestellt, das hat temperature2).
Ein resident war nicht definiert, Windsensor steht weiter auf dem Wetterdevice ohne Readingangabe (sehr gut!).

In der NOTIFYDEV steht jetzt nur das Winddevice drin, den Tempsensor sehe ich nicht. Ist das ok so? Dafür habe ich einige alte umbenannte Rollladen-Devices drin; wie bekomme ich die nochmal raus? (Scannen hilft nicht...)(EDIT:gefunden...)

Spontan nicht so zugesagt hat mir die Zusammenfassung der Brightness-Geschichte "all in one"; wie geschrieben macht sowas für mich erst dann Sinn, wenn wirklich alle Einstellmöglichkeiten über andere Wege verfügbar sind, sonst finde ich die Trennung von Sensorangaben (erster Teil) und Schwellenwerten (2. Teil) besser, aber auch nur dann, wenn man jeweils auf den "unnötigen Teil", der errechnet werden kann verzichten kann.
Hier kommt noch dazu, dass der Sensor für zwei Dinge Verwendung finden soll, nämlich Öffnen/Schließen morgens und Beschattung. Da jetzt nur eine Teilfunktionalität (morgens/abends) verpflichtend (?) mit reinzupacken, finde ich unlogisch, vor allem, wenn man die gar nicht nutzen will.

Lt. commandref ist ASC_WindParameters - TRIGGERMAX[:HYSTERESE] DRIVEPOSITION Wenn das so zu verstehen ist, dass DRIVEPOSITION verpflichtend anzugeben ist, ist es anders, als vorgeschlagen und daher - ohne anderweitige separate Einstellmöglichkeit - unpraktischer wie vorher.

Was uU. auch hilfreich sein könnte, wäre im ASC-Device die zentralen Sensor-Readings als (nichttriggernde) Infos mit anzuzeigen; wäre evtl. auch für lists zum ASC-Device zum einfacheren Debuggen interessant, um Fehler in der Konfiguration durch die user leichter zu finden.

Soviel mal auf die Schnelle, ich erläutere die Punkte gerne nochmal mehr in Ruhe .

[CoolTux]

Moin,

habe vorhin die 0.4.0.11beta26 mal installiert. Die Timer sehen im Prinzip ok aus, es ist erkannt, dass day up schon durch ist, allerdings stehen da Morgens-Timer von heute drin, die auf $we passen würden (Kontroll-Aufruf?).

Kannst Du mir da ein list von geben? Ich kann mir das immer nicht so gut vorstellen. WE hast Du anscheinend auf on?

Beim Umwandeln des Temp-Sensors hatte ich hinterher das Reading temperature drin; das stimmt nicht, vorher war das state (ist ein ReadingsProxy; jetzt habe ich auf das eigentliche Device umgestellt, das hat temperature2).

Ich prüfe das noch mal, hatte eigentlich gestern ein paar Tests gemacht, allerdings in der Tat alle mit Temperature

Ein resident war nicht definiert, Windsensor steht weiter auf dem Wetterdevice ohne Readingangabe (sehr gut!).

Das freut mich

In der NOTIFYDEV steht jetzt nur das Winddevice drin, den Tempsensor sehe ich nicht. Ist das ok so? Dafür habe ich einige alte umbenannte Rollladen-Devices drin; wie bekomme ich die nochmal raus? (Scannen hilft nicht...)(EDIT:gefunden...)

Der Temsensor ist nur zum auslesen, kein Triggern. Daher kein Notifydev Eintrag

Spontan nicht so zugesagt hat mir die Zusammenfassung der Brightness-Geschichte "all in one"; wie geschrieben macht sowas für mich erst dann Sinn, wenn wirklich alle Einstellmöglichkeiten über andere Wege verfügbar sind, sonst finde ich die Trennung von Sensorangaben (erster Teil) und Schwellenwerten (2. Teil) besser, aber auch nur dann, wenn man jeweils auf den "unnötigen Teil", der errechnet werden kann verzichten kann.
Hier kommt noch dazu, dass der Sensor für zwei Dinge Verwendung finden soll, nämlich Öffnen/Schließen morgens und Beschattung. Da jetzt nur eine Teilfunktionalität (morgens/abends) verpflichtend (?) mit reinzupacken, finde ich unlogisch, vor allem, wenn man die gar nicht nutzen will.

Die Einstellungen für Brightness werden vorrangig im Rollladen gemacht. DEVICE:READING MIN:MAX
Darüber hinaus ist es Möglich auch für die MIN MAX Werte eine globale Einstellung im ASC zu machen. So wurde es mal gewünscht.
Bei Brightness kann ich nichts berechnen (Brightness für Sonnenauf und Untergang) denn es kann durchaus sein das der Min Wert großer ist wie der Max Wert. Eigentlich müsste das auch nicht Min und Max heißen sondern Sunset und Sunrise, so das man weiß das dies die Werte für Sonnenaufgang und Sonnenuntergang sind.

Lt. commandref ist ASC_WindParameters - TRIGGERMAX[:HYSTERESE] DRIVEPOSITION Wenn das so zu verstehen ist, dass DRIVEPOSITION verpflichtend anzugeben ist, ist es anders, als vorgeschlagen und daher - ohne anderweitige separate Einstellmöglichkeit - unpraktischer wie vorher.

Habe ich mir gerade angeschaut, kannst Du bitte einmal testen ob es auch ohne die Angabe von Position geht? Vorallem aber ohne Hyst und ohne Pos.

Was uU. auch hilfreich sein könnte, wäre im ASC-Device die zentralen Sensor-Readings als (nichttriggernde) Infos mit anzuzeigen; wäre evtl. auch für lists zum ASC-Device zum einfacheren Debuggen interessant, um Fehler in der Konfiguration durch die user leichter zu finden.

Soviel mal auf die Schnelle, ich erläutere die Punkte gerne nochmal mehr in Ruhe .

Ich glaube ohne eine richtige Liste wie wir was machen wollen geht es nicht mehr. Es ist einfach zu viel. Wir müssen anfangen die Dinge zu Verwalten.
Was Debuggen an geht so träume ich von einer automatisierten Möglichkeit. Der User bekommt ein set Befehl welcher die wichtigsten angaben Darstellt und er das dann hier preisgeben kann, oder später zu mir senden kann auf einen System bei mir Vorort was ich für eine Auswertung verwende. Aber das ist noch ein Träumchen

[Beta-User]

Kannst Du mir da ein list von geben? Ich kann mir das immer nicht so gut vorstellen. WE hast Du anscheinend auf on?

WE ist auf on, leider ist das mit dem list schwierig, weil ich grade nicht auf den Server komme und die Daten ja auch verändert wären. Ich habe "getShuttersInfo" (?) aufgerufen und da gesehen, dass die up-Timer auf heute stehen, genauer: 2 Sekunden nach meiner WE-up-Time.

Der Temsensor ist nur zum auslesen, kein Triggern. Daher kein Notifydev Eintrag

OK, nachvollziehbar. Aber: warum eigentlich nicht ein notify drauf legen und dann einfach den Wert in einem Internal, z.B. {outsidetemp} festhalten? Das ist zwar doppelte Datenhaltung, aber dafür hast du den Wert zukünftig immer an derselben Stelle unmittelbar im Zugriff, ohne groß ReadingsVal() (uU. noch iVm. einer komplizierten Ermittlung des Namen:Readingnamen) nochmal für jeden betroffenen Rolladen aufrufen zu müssen. Eine weitere Auswertung/Reaktion im Sinne eines echten notify muß ja (erst mal?) bei Eintreffen des Werts gar nicht erfolgen...

Die Einstellungen für Brightness werden vorrangig im Rollladen gemacht. DEVICE:READING MIN:MAXDarüber hinaus ist es Möglich auch für die MIN MAX Werte eine globale Einstellung im ASC zu machen. So wurde es mal gewünscht.
Bei Brightness kann ich nichts berechnen (Brightness für Sonnenauf und Untergang) denn es kann durchaus sein das der Min Wert großer ist wie der Max Wert. Eigentlich müsste das auch nicht Min und Max heißen sondern Sunset und Sunrise, so das man weiß das dies die Werte für Sonnenaufgang und Sonnenuntergang sind.

Dann benenne es doch bei der Gelegenheit gleich um... Und dazu eine Logik Sunset[:Sunrise] mit Sunrise=Sunset, wenn nicht angegeben (oder anders herum, also beginnend mit Sunrise)?
Zur Erläuterung nochmal: Im Ergebnis brauchst du natürlich - sofern das feature überhaupt aktiv ist - im Ergebnis beide Werte, die Frage war nur, wo sie stehen bzw. wo sie hergenommen werden. Im Moment denke ich, es wäre gut, da eine interne Datenstruktur bei der Inititialisierung des Moduls zu generieren, über die man dann im laufenden Betrieb die relevanten Werte wieder rausholt. Das vereinfachte Beispiel dazu wäre das mit dem {outsidetemp} von oben.
(Bei Bedarf erläutere ich gerne noch, wie ich mir die Datenstruktur z.B. für den Teil Brightness-Steuerung vorstellen könnte).

Würde halt bedingen, dass man die einzelnen Devices auch auf Attributänderung überwacht und dann diesen Teil der Datenstruktur ggf. updated. Wäre aber sicher auch nicht besonders schwierig, wenn wir modular arbeiten.

Habe ich mir gerade angeschaut, kannst Du bitte einmal testen ob es auch ohne die Angabe von Position geht? Vorallem aber ohne Hyst und ohne Pos.

Mache ich, wenn ich wieder etwas Zeit und ordentlichen Zugriff auf den Server habe (via Handy ist das Mist...)

Ich glaube ohne eine richtige Liste wie wir was machen wollen geht es nicht mehr. Es ist einfach zu viel. Wir müssen anfangen die Dinge zu Verwalten.
Was Debuggen an geht so träume ich von einer automatisierten Möglichkeit. Der User bekommt ein set Befehl welcher die wichtigsten angaben Darstellt und er das dann hier preisgeben kann, oder später zu mir senden kann auf einen System bei mir Vorort was ich für eine Auswertung verwende. Aber das ist noch ein Träumchen

Jup, eine Liste wäre nicht schlecht; dann wäre es auch einfacher, erst mal bestimmte Detailaspekte auszuprobieren (wie das mit der internen Datenstruktur) und ggf. Zwischenergebnisse festzuhalten, wenn sich was nicht bewährt hat.

Was das Sichtbarmachen, lists usw. angeht, fände ich eine entsprechende Logik auch nicht schlecht, optimalerweise mit anonymisierten Gerätenamen usw. wenn gewünscht (deswegen vermeide ich im Moment lists...). Wenn wir eine standardisierte interne Datenstruktur hätten: Im Rahmen von MiLight@MQTT hatte ich kurz mit toJSON rumexperimentiert. Das schien in der Lage zu sein, manches ganz praktisch zu verpacken, allerdings bin ich da nie vertieft eingestiegen, könnte aber ggf. helfen.
Ob das Prio hat: keine Ahnung.

[Beta-User]

Habe ich mir gerade angeschaut, kannst Du bitte einmal testen ob es auch ohne die Angabe von Position geht? Vorallem aber ohne Hyst und ohne Pos.

Also Zwischenstand dazu:
- Nur Angabe von "45" => Rollladen geht auf genau 50% Öffnung bei Überschreiten des Werts. Keine Reaktion, wenn ich dann die Windgeschwindigkeit wieder reduziere (getestet u.a. mit 23).
- "60 100" führt dazu, dass der Rolladen nach oben (100%) geht bei Überschreitung, und dann auch wieder auf 0%, wobei das vermutlich der vorigen Position entspricht, weil ich erst bei einem vorherigen Test einen stop bei 50% hatte. Wenn es die vorherige Position ist, wäre die Frage, ob das dann noch sinnvoll ist, wenn zwischenzeitlich ASC-bedingt eine andere Zielposition eintreffen soll und die blocking-Time abgelaufen ist,
- "volle Lösung" scheint zu funktionieren, "40:10" gibt das 50%-Problem.

Die 50%-Position (als default oder Fallback) ist übrigens m.E. keine gute Sache, bei Teilöffnung ist das Windproblem m.E. sogar größer wie ganz geschlossen/ausgefahren. Kurz hatte ich nach einer Einstellmöglichkeit für den default-Wert am ASC gesucht, aber die scheint es nicht zu geben.

Das war's erst mal für heute...

[Beta-User]

So, zur Veranschaulichung des Themas mit den Timern wenigstens noch ein Screenshot, dann kannst du dir das ggf. besser vorstellen.

Bitte nicht daran stören, dass die Jalousien auf manual stehen, da ist einfach die Laufzeit länger als der feste Timeout von ASC. (Dazu habe ich auch eine Idee, aber vielleicht komme ich die Tage mal dazu, einen patch einzureichen, der das - wenigstens mal für die von mir verwendeten HM-Typen - automatisch und pro Aktor aus den dortigen Werten ableitet.

Während ich das hier so schreibe, sind übrigens drei von den 4 "manual"-Jalousien wieder nach unten gefahren, k.a. warum, und warum der 4. nicht (der ist der mit der kürzesten "zu langen" Laufzeit). Der Rest (alles Rollläden mit kleinerer Laufzeit) sind weiter oben geblieben.  Auch dazu ein screenshot von der RG mit den Zeiteinstellungen dazu anbei.

Links ist mein Wind-Tester (sollte aber im Notfall oben bleiben), links und rechts haben keinen FK, Mitte und WZ je einen dualState, beide schon länger auf geschlossen.


Lüften:
Einer der Schlafzimmerrollladen an dem Fenster, das ich morgens oft öffne, reagiert auch nach wie vor auf das öffnen m.E. nicht ganz stringent:
Der FK an sich scheint bekannt zu sein, jedenfalls hat das gestern nach der Nachtschließung mit unterschiedlichen Höhen soweit funktioniert. Heute morgen (innerhalb einer eventuellen blockingtime) vor der automatischen Öffnung wollte der Rollladen jedoch nicht; als Ursache kommt aber noch in Frage, dass ich die alle zusammen zuvor auch etwas manuell geöffnet hatte (aber weniger als offen-Position).

[CoolTux]

Was mir auffällt sind die ja schon von Dir erwähnten Fahrzeiten für WE. Ist bei Dir Feiertag heute? Denn wenn nicht kann ich mir nicht erklären wieso Deine Rolllos zu WE Zeit fahren wollen.

Ich teste heute noch mal die Übernahme der Temperatur und schaue ob ich was wegen wind und den default Sachen machen kann. Aber ich glaube da ging nichts.

[Beta-User]

 
Jup, {$we} liefert "1"?!?
{$wday} gibt "4" aus...

Meine holiday-devices (list -r TYPE=holiday):

Code Auswählen Erweitern

define bw holiday
attr bw alias Feiertage Baden-Württemberg
attr bw group Kalender
attr bw icon time_calendar
attr bw room Startseite
attr bw stateFormat Heute: state, morgen: tomorrow

define ferien holiday
attr ferien alias Ferien Baden-Württemberg
attr ferien group Kalender
attr ferien icon time_calendar
attr ferien room Startseite,Steuerung->Kalender
attr ferien stateFormat heute: state, morgen: tomorrow

define muell holiday muell
attr muell alias Müll
attr muell devStateIcon kein:dustbin@grey morgen.*:dustbin@red .*Bio.*:dustbin@brown .*Rest.*:dustbin@black
attr muell group Kalender
attr muell icon dustbin
attr muell room Startseite
attr muell stateFormat {if (ReadingsVal("muell","state","none") ne "none") {\
return "heute: ".ReadingsVal("muell","state","none");;\
} elsif (ReadingsVal("muell","tomorrow","none") ne "none"){\
return "morgen: ".ReadingsVal("muell","tomorrow","none");;\
} else {\
return "kein";;\
}}

setstate bw Heute: none, morgen: none
setstate bw 2019-03-14 00:00:02 state none
setstate bw 2019-03-14 00:00:02 tomorrow none
setstate bw 2019-03-14 00:00:02 yesterday none

setstate ferien heute: none, morgen: none
setstate ferien 2019-03-14 00:00:02 state none
setstate ferien 2019-03-14 00:00:02 tomorrow none
setstate ferien 2019-03-14 00:00:02 yesterday none

setstate muell kein
setstate muell 2019-03-14 00:00:02 state none
setstate muell 2019-03-14 00:00:02 tomorrow none
setstate muell 2019-03-14 00:00:02 yesterday Bioabfall

global (Auszug):

Code Auswählen Erweitern

Internals:
   DEF        no definition
   FD         3
   NAME       global
   NR         1
   STATE      no definition
   TYPE       Global
   currentlogfile ./log/fhem-2019-03.log
   logfile    ./log/fhem-%Y-%m.log
Attributes:
   autoload_undefined_devices 1
   autosave   0
   commandref modular
   configfile configDB
   holiday2we bw,ferien

[Beta-User]

tsss: Es liegt an den stateFormat-Angaben!!!

Gelöscht, jeweils ein reload durchgeführt und es gibt die "0"...