[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

Beta-User · 03 März 2019, 16:50:09

Zwischeninfo: bin derzeit wieder auf der allgemeinen Version. Heute morgen sind die Rollläden alle wieder zugefahren (ziemlich sicher zur TimeUpLate, die nach der WE-Zeit liegt).
Kann noch nicht sagen, ob das auch in der "normalen" Version so ist, bisher war das allerdings m.E. kein Problem.

CoolTux · 04 März 2019, 11:08:04

Magst Du mal bitte die neuste Version testen.
Ich habe einiges an Code umgeschrieben und ein Code Clean gemacht. Und natürlich das worum es geht.
ASC_windSensor ist nun als Attribut im ASC Device. Angabe erfolgt SENSOR:READING (default Reading ist wind)

Ich muß gestehen das ganze ließe sich einfacher umsetzen wie ich dachte. Frage mich gerade ganz doll woher die Angst kam.

Beta-User · 04 März 2019, 11:32:25

Mache ich vermutlich dann heute abend.

Modul von hier: https://github.com/LeonGaultier/fhem-AutoShuttersControl/tree/devel , oder?

Zitat von: CoolTux am 04 März 2019, 11:08:04
ASC_windSensor ist nun als Attribut im ASC Device. Angabe erfolgt SENSOR:READING (default Reading ist wind)

Ich muß gestehen das ganze ließe sich einfacher umsetzen wie ich dachte. Frage mich gerade ganz doll woher die Angst kam.

.
Danke für's Überwinden der Angst

.

Mal schauen, wie das allgemein von den Usern angenommen wird und welche Rückmeldungen es gibt. M.E. ist das eine Notation, die häufiger so vorkommt (bei anderen Modulen), sollte also eigentlich kein Thema sein...

Vielleicht noch zwei Anmerkungen:
- Die Notationsdenke in Basisangabe[:Option] udn fallback auf einen default-Wert steckte auch bei den anderen Anmerkungen hier als gedanklicher Hintergrund drin, vielleicht werden die jetzt bei nochmaligem Lesen besser verständlich.
- Die Trenner bei pah mit dem "|" sind m.E. nicht optimal, weil das regexe stört. Wenn du noch kannst, nimm was anderes (Vorschlag: "/", das ist der alternativ vorgeschlagene default in eventMap, wenn da das Leerzeichen stört.

CoolTux · 04 März 2019, 14:53:23

Ich habe als Trenner : genommen. Das sollte gehen.

Ausserdem habe ich in einer aktuellen Laborversion alle relevanten Attribute des ASC Devices umgestellt auf das neue Format und ein Fallback geschaffen für die User. Sofern die Werte in den alten Attributen drin hatten werden diese in das neue Attribut mit neuer Schreibweise übernommen.
Ausserdem gibt es eine eindeutige Warnung (vorerst wenn language deutsch) beim setzen der alten Attribute.
Es gibt nur ein einziges Problem. Beim setzen der neuen Attribute wird nachweislich kein Event aus gelöst und somit kann ich auch die NOTIFYDEV zusammen setzen. Momentane Lösung, einmalig nach dem einspielen des neuen Modules muss create NewNotifyDev ausgeführt werden.

Grüße

Beta-User · 04 März 2019, 15:34:45

Mit dem Hinweis auf den Trenner war eher die Frage gemeint, wie man das machen kann, wenn mehrere Device:Reading-Werte nacheinander kommen sollen (pah-Beitrag im Haupt-Thread), Device:Reading ist ansonsten ja genau so, wie vorgeschlagen, ich habe da keine neuen Erkenntnisse gehabt...

Zum notifydev: Vielleicht beim Initialisieren eine Variable definieren, die dann auf true gesetzt wird, wenn der Umsetzungsmechanismus was findet und dann nach dem Umstellungssuchdurchlauf die Neuerstell-Funktion automatisch aufrufen, wenn was geändert wurde (wäre in dem Fall eh' besser als eine notification, weil wir das ja im Prinzip als einmalige Ausführung ganz am Ende ja ausreichend sein sollte, oder?

Beta-User · 04 März 2019, 20:32:28

So, Testversion ist wieder eingespielt.

Eine Frage: Wird das Wind-Attribut in den einzelnen Rollläden weiter im alten defaultwert gefüllt? Vermutlich wird ein Anwender das nicht so toll finden, wenn alle Rollläden auf Wind reagieren, sobald ein Wind-Gerät festgelegt ist. Wäre m.E. besser, das auf einen Wert zu setzen, der erst mal nur in extremen Fällen reagiert (180:200?, wenn es schon weiter dieses Format sein soll, das ich immer noch nicht prickelnd finde...).

CoolTux · 04 März 2019, 21:13:27

Zitat von: Beta-User am 04 März 2019, 20:32:28
So, Testversion ist wieder eingespielt.

Eine Frage: Wird das Wind-Attribut in den einzelnen Rollläden weiter im alten defaultwert gefüllt? Vermutlich wird ein Anwender das nicht so toll finden, wenn alle Rollläden auf Wind reagieren, sobald ein Wind-Gerät festgelegt ist. Wäre m.E. besser, das auf einen Wert zu setzen, der erst mal nur in extremen Fällen reagiert (180:200?, wenn es schon weiter dieses Format sein soll, das ich immer noch nicht prickelnd finde...).

Stimmt. Da muss ich mir noch was überlegen.
ASC_Wind_speed' => '50:20',

ab größer 50 auf WindPos fahren ab kleiner 50-20 also 30 zurück auf vorherige Position fahren.
So besser?

Beta-User · 04 März 2019, 21:36:07

Ja, am besten die 20 optional....

CoolTux · 04 März 2019, 21:38:26

Ja dachte ich mir.
Ich werde mich morgen noch mal ran setzen

Beta-User · 04 März 2019, 22:22:33

Thx.

Vielleicht dazu noch was, was mir heute abend noch in den Sinn kam: Die default-Hysterese könnte man per zentralem Attribut (ist im ASC-Modul-Device ja nicht zwingend sichtbar) einstellbar machen. Dürfte kein besonders großer Aufwand sein, aber ein nettes Gimmik, wenn jemand doch lieber in m/s rechnet.

Als Stichwort ist mir noch Böe eingefallen, aber da ist es mir heute auch zu spät, dazu noch was zu sagen/zu überlegen. Vermutlich ist das "egal", dann nimmt man halt einen anderen Sensor oder bildet irgendwie einen gerechneten Wert und füllt damit das Haupt-Wind-Gerät...

CoolTux · 05 März 2019, 08:30:34

Beta-User · 05 März 2019, 09:28:10

Den Gedanken, das zusammenzufassen, finde ich grundsätzlich gut, aber:

1. BITTE dann aber unbedingt NICHT den "|" als Trenner; genau der hat bei pah's YAAHM breits für Irritationen gesorgt....

Wenn man was als Trennzeichen benötigt, entweder das Leerzeichen oder z.B. ein "/", also (die []-Angaben sind immer als Option gedacht):
"DEVICENAME[:READINGNAME] 50[:20] ...." ergäbe also "Windmesser:Boeengeschwindigkeit 45:10" oder "Meinwetter 70" (oder Kombinationen davon wie "Meinwetter 70:25").Alternativ (wie bei eventMap!): "/DEVICENAME[:READINGNAME]/50[:20]/...."

Im Moment würde ich das Leerzeichen am besten finden, das macht nur dann Probleme, wenn irgendeine der Angaben ein Leerzeichen enthalten kann (das ist bei eventMap das Problem, warum es überhaupt weitere Möglichkeiten gibt).

2. Das Problem dabei ist bei dieser Kombilösung allerdings, dass man dann tatsächlich entweder nur manuell jeden Rollladen einzeln bearbeiten kann oder wir wirklich ein eigenes UI brauchen. Wenn wir mittelfristig den Reading-Weg gehen sollten, wäre das zusammenfassen nicht mehr ganz so wichtig, im Moment würde ich noch für getrennte Orte für die Eingabe der Info stimmen, da dann erst mal noch noch der "einfache" Weg über die RG gegeben ist.

(Im Moment denke ich immer mehr, dass das mit den Readings eine gute Lösung wäre: Um die Konfiguration separat abzuspeichern, würde ein gekürztes list -r von allen Rollladen-Devices genügen; gekürzt bedeutet: nur das, was in den "ASC_.*"-Angaben steht.)

3. Weiteres Problem: die Angaben müssen in dieser Fassug in einer ganz bestimmten Reihenfolge kommen; evtl. würde es Sinn machen, eine Arr keyword voranzustellen, damit klar ist, was das jeweils ist ("WindDevice:DEVICENAME[:READINGNAME] WindThreshold:50[:20] ....").

4. Für Wind finde ich das unnötig kompliziert, wie gesagt: es dürfte eigentlich in einer FHEM-Instanz sinnvollerweise nur ein Wind-Gerät geben; das gibt man zentral an, und gut ist... Das jeweils in eine komplexere Form an den Rollladen "ranzucodieren", finde ich overdone.

5. In Erweiterung zu der default-Hysterese im Modul: Man könnte vermutlich recht einfach userseitig einen anderen default-Wert in ein eigenes Attribut am ASC-Device setzen lassen (oder in Anlehnung zur obigen Notation am zentralen Wind-Device).

6. Es würde evtl. Sinn machen, die Wind-Attribute an den Rollläden doch mit einem halbwegs sinnvollen Wert vozubelegen; damit aber die Automatik dann nicht direkt greift, ohne dass der user das will, müßte man ein entsprechendes "set" am ASC-Device vorsehen: "set <myASC-Device> windautomation on"

7. Was ganz anderes (noch nicht fertig überlegt, aber gestern abend noch in den Sinn gekommen, nachdem mir das Stichwort Boe eingefallen war): Da du dich ja mit dem Wetterbericht "etwas" auseinandergesetzt hast, wäre es gerade für Wind evtl. auch sinnvoll, dabei (optional) auch den forecast für die nächsten paar Stunden zu berücksichtigen, also konkret zu prüfen, ob z.B. innerhalb der nächsten 3 Stunden auch keine Windgeschwindigkeiten mehr zu erwarten sind, die oberhalb des unteren Wertes liegen.
Konkret stelle ich mir vor, für Wind eine lokale Wetterstation zu nutzen und dabei auch Boen zu analysieren usw.. Boen sind an sich schwierig, da diese spontan auftreten können, aber besonders verheerende Folgen haben. Dann kann es aber natürlich sein, dass das "normale" Windreading stark schwankt, gerade im Vorfeld von Gewittern.
Ergänzt man das mit einer Internet-Wettervorhersage, kann man das evtl. glätten... (Ich hoffe, das einigermaßen verständlich erklärt zu haben, sonst bitte nachfragen).

8. (Hat vermutlich nichts mit der Entwicklerversion zu tun:)
Bei uns sind grade Ferien, also WE=true. Trotzdem sind wir heute alle recht früh aufgestanden, und da draußen schon hell war, wurden auch manuell die Rollläden gefahren (nach der frühesten allg. Aufsteh-Zeit). Irgendwann sind sie wieder runter, zu einer Zeit, von der ich erst nicht wußte, wo die herkommt.
Meine Vermutung: Die Blocking-time war abgelaufen (wenn man's nicht verstellt hat eine Stunde, oder?)...

Mein Wunsch: Wenn eine manuelle Öffnen-Fahrt auf offen (oder weiter als offen) gemacht wird, und das morgens nach der frühesten Öffnen-Zeit stattfindet, nicht mehr schließen. (Wo ich das schreibe: Eigentlich geht es nicht um die Zeit des manuellen Öffnens, sondern um den Ablauf der blocking-Time: liegt die nach dem frühesten Öffnen => betrachte die morgendliche Fahrt als erledigt...)
Ob man den Gedanken auf Abends entsprechend übertragen kann, wäre noch zu überlegen, wollte erst mal deine Rückmeldung haben, ob das sinnvoll ist, einigermaßen ohne Unfall umzusetzen wäre usw....

Langer Beitrag, hoffe, das einigermaßen übersichtlich und verständlich dargestellt zu haben.

CoolTux · 05 März 2019, 10:16:17

Jup alles klar und verständlich.

Ich schwanke noch ob es dem User leichter fällt sich eine Reihenfolge zu merken
DEVICE:READING:MAX:...

oder wie Du schon andeutest name=DEVICE reading=state.
Bei Wind ist es ja noch einfach und übersichtlich, aber zum Beispiel bei Beschattung, wenn wir das alles so machen wie pah vorgeschlagen hat dann ist das schon ne große Hausnummer.
Mein Gedanke war ein Attribut wo alles rein kommt was für die Beschattung nötig ist aber für nichts anderes verwendet wird.
Da fällt dann Brightness zum Beispiel raus.

Drin bleibt

Code Auswählen


ASC_Shading_Angle_Left
ASC_Shading_Angle_Right
ASC_Shading_Direction
ASC_Shading_Min_Elevation
ASC_Shading_Min_OutsideTemperature
ASC_Shading_Mode
ASC_Shading_Pos
ASC_Shading_StateChange_Cloudy
ASC_Shading_StateChange_Sunny

Das alles in eine Zeile.

Beta-User · 05 März 2019, 10:27:05

Na ja, der user wird bei so einer komplexen Sache nicht umhin kommen, sich ggf. auch mit der Syntax in der Einrichtung zu befassen.

Daher ja auch mein Ansatz, das möglichst einfach zu halten, und vieles einfach mal zu "erraten" bzw. mit Werten vorzubelegen, die uns hier sinnvoll erscheinen, und (erst mal nur) diese optionalen Attribute einzusparen (und immer ähnliche Logiken zu nutzen, was Hysteresen usw. angeht).

Zu Beschattung würde ich folgende Struktur sehen:
ASC_Shading_Angles Direction[:left[:right]] (über die Benennung des Attributs sollten wir noch reden...)
ASC_Shading_Min_Elevation
ASC_Shading_Min_OutsideTemperature
ASC_Shading_Mode
ASC_Shading_Pos
ASC_Shading_StateChange Sunny[:Hysterese] => Hysterese wieder zentral am ASC vorbelegbar, Hysterese-Logik wie bei Wind (ich habe aber noch nicht intensiver an der Beschattung gearbeitet, da kann es sein, dass ich noch nicht alles durchschaut habe und auf dem Holzweg bin)

Ergibt 6 statt 9 Attribute (oä.), jedes, das der User ggf. (per RG) anfassen will als einzelne Angabe (Winkel ausgenommen, wenn man was spezielles will))

kjmEjfu · 05 März 2019, 10:32:38

Zitat von: CoolTux am 05 März 2019, 10:16:17
Das alles in eine Zeile.

Ist halt die Frage, was man möchte

Wird die Konfiguration zu schwierig (im Sinne von verständlich), dann gibt es jede Menge Nachfragen und angebliche Fehler, weil es einfach nicht verstanden wird. Kostet dann unnötig Zeit nur weil man sich eventuell ein Attribut gespart hat. Musst gerade du als Modulentwickler abwägen

Dazu kommt noch eine weitere Sache. Gerade beim Einrichten und Nachjustieren der Einstellungen, verändert man ja immer mal was.
Ich denke z.B. an die Werte:

Code Auswählen


ASC_Shading_Min_OutsideTemperature
ASC_Shading_StateChange_Cloudy
ASC_Shading_StateChange_Sunny

Wenn man jetzt nicht nur zwei Fenster hat, sondern z.B. irgendwas um die 15-20, so ist es recht praktisch wenn man die einzelnen Attribute einfach per Bulk updaten kann:

Code Auswählen

attr Rollo_.* ASC_Shading_StateChange_Sunny 40000

und schon habe ich den Wert für alle Fenster angepasst.
Findet sich alles in einem Attribut, so ist das nicht mehr ganz so trivial - jedenfalls für Ottonormalverbraucher.

Wenn ich die Werte einmal komplett eingestellt habe und nur noch mal minimal für einzelne Fenster nachjustieren muss, dann ist das natürlich wieder ganz was anderes.

Nur mal so als Einwurf.