[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

[CoolTux]

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 Erweitern

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.

Sehr gutes Argument. Danke

[CoolTux]

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))

Finde ich gut. Allerdings bin ich mittlerweile soweit das ich ein argument=value nehmen möchte.
device=windsensor [reading=state]

Ich finde das irgendwie logischer und für mich einfacher

[Beta-User]

Finde ich gut. Allerdings bin ich mittlerweile soweit das ich ein argument=value nehmen möchte.
device=windsensor [reading=state]

Ich finde das irgendwie logischer und für mich einfacher

Du bist der Entwickler .

Ich gebe nur zu bedenken, dass "Device:Reading" eine in FHEM bereits ziemlich verbreitete Notation ist, auch notify verwendet das, und einige andere Module mehr. Die Notation mit "=" und Einzelangaben ist mir dagegen bisher so nicht über den Weg gelaufen (wenn, dann eher noch als verschachtelte Arrays in einer JSON-Notation ).

Immer da, wo es um Sensor und Reading geht, gibt es m.E. keinen (aus Usersicht) nachvollziehbaren Grund, warum man da eine lange Form braucht; den Sensor muß man logischerweise immer angeben, das ist die wichtigste Angabe, daher kommt das zuerst und ohne "Verpackung", und häufig ist dann direkt klar, wie das Reading heißen muß.

Aber zur Klarstellung: wenn wir mehrere Infos, die nicht unmittelbar was miteinander zu tun haben, in ein Element reinschieben wollen, ist das toll!
Dann würde ich aber Mischungen vorschlagen wie "device=windsensor:reading maxspeed=50:20" (oder gleich JSON, dann müssen wir aber über die "Zugänglichkeit für die User" reden).

Im Moment sehe ich dafür nur noch keinen wirklichen Anwendungsfall, siehe das Argument von @kjmEjfu, der das wohl verständlicher rübergebracht hat wie ich mit meinen ReadingsGroups (was aber auf dasselbe rausläuft).

[CoolTux]

Ok ich mache es jetzt mit : alt trenner. Aber ich werde nur paare zulassen. Also key:value. Es könne aber in einem Attribut mehrer key:value Paare geben.

Man ist das Anstrengend über sowas nach zu grübeln. Lach

[Beta-User]

Man ist das Anstrengend über sowas nach zu grübeln. Lach

Da hast du mal sowas von recht!
Geht mir genauso, ...

Ok ich mache es jetzt mit : alt trenner. Aber ich werde nur paare zulassen. Also key:value. Es könne aber in einem Attribut mehrer key:value Paare geben.

Kannst du das noch kurz erläutern?
Bei Device[:Reading] wäre es klar, und auch kein Beinbruch, wenn zwingend auch das Reading mit angegeben werden muß; das wäre ein reiner Komfortverlust gegenüber dem "Erraten" des zum Sensor passenden Readings.

Für Werte (Grenzgeschwindigkeit[:Hysterese]) finde ich es definitiv _nicht_ gut, wenn zwingend beides anzugeben ist: dann sind zwar Massenänderungen via Regex möglich, aber keine einfache Werteeingabe via ReadingsGroup.

[CoolTux]

wenn der zweite Wert vom Pärchen fehlt wird einfach ein default genommen. Es geht also DEVICENAME:READING oder auch nur DEVICENAME

[Beta-User]

...dann ist alles gut

[FunkOdyssey]

Ganz kurz am Rande bzgl. der Schreibweise:
Das statistics-Modul nutzt auch die Doppelpunkte als Trenner und scheinbar RegEx bei den Parametern. Getrennt wird mit der Pipe. Eigentlich ist das ganz nett. Habe ich zuvor aber auch noch nie genutzt.

[CoolTux]

So ich denke mal ich habe eine für mich akzeptable Möglichkeit gefunden.

Und weil wir immer noch beim Wind testen sind. Wie nenne ich nun ein Attribut das alles relevante für das Wind steuern beinhaltet

ASC_WindMaxHystPos

Maximaler Wert ab den die Automatik greift (größer 50km/h), Hysterese ab dem das wieder aufgehoben wird (maxWert minus Hysterese) und die Position welche der Rollladen anfahren soll wenn max Wert erreicht wird.

Vorschläge?

[Beta-User]

  .

Interpretiere ich das richtig: (obere) Windgeschwindigkeit ist ein "Muß", der Rest optional?!? Sehr cool!!!!
Wo kommt dann der default für den Ziellevel her? Open-position, Installationsweit ggf. als Absolut-Wert oder mit open bzw. close festzulegen (ASC-Geräte-Attribut)?
Gefällt mir....

Was den Namen angeht, finde ich den Vorschlag ok, der ist sprechend, kann aber auch zu Fragen führen, in die Richtung, ob denn jetzt alles anzugeben ist.
Werfe mal (eher als spontane Idee)

Code Auswählen Erweitern

"ASC_Wind_Param" oder "ASC_WindParameters"

in den Raum. Das ist allgemeiner (für den Fall, dass uns noch was einfällt), und wird den user eher motivieren, die Erläuterung dazu mal anzusehen. Die mehrzahlige Form impliziert dann aber wieder, dass es mehrere Parameter sind, was zu derselben Überlegung führt wie bei deinem Ausgangsvorschlag.



Zu der Pipe noch: Dass es Module gibt, die das verwenden, mag sein. Trotzdem finde ich "spezielle" Zeichen aus der Perl-Welt ganz allgemein schwierig, leider finde ich den Threadabschnitt nicht mehr, in dem es um das Pipe-Thema (ich meine bei YAAHM) ging...



Ich bin nicht sicher und konnte das auch bisher nicht näher prüfen, aber mit der github-devel-Version scheinen manche Rollläden (am WE?) gar nicht zu fahren. Vielleicht hast du eine spontane Idee, ob es da einen Zusammenhang gibt?

[CoolTux]

.

Interpretiere ich das richtig: (obere) Windgeschwindigkeit ist ein "Muß", der Rest optional?!? Sehr cool!!!!
Wo kommt dann der default für den Ziellevel her? Open-position, Installationsweit ggf. als Absolut-Wert oder mit open bzw. close festzulegen (ASC-Geräte-Attribut)?
Gefällt mir....

Was den Namen angeht, finde ich den Vorschlag ok, der ist sprechend, kann aber auch zu Fragen führen, in die Richtung, ob denn jetzt alles anzugeben ist.
Werfe mal (eher als spontane Idee)

Code Auswählen Erweitern

"ASC_Wind_Param" oder "ASC_WindParameters"

in den Raum. Das ist allgemeiner (für den Fall, dass uns noch was einfällt), und wird den user eher motivieren, die Erläuterung dazu mal anzusehen. Die mehrzahlige Form impliziert dann aber wieder, dass es mehrere Parameter sind, was zu derselben Überlegung führt wie bei deinem Ausgangsvorschlag.

ASC_WindParameters - finde ich super. So machen wir das. Na ja das mit den Rest optional ist so eine Sache. Also ja ich werde es so umsetzen, aber!! Wenn der User beim max Wert 0.2 ein gibt und die Hysterese weg lässt wird per default aktuell 20 genommen. 0.2 -20 ist bisschen am Ziel vorbei geschossen 


Grüße

[nils_]

Wenn der User beim max Wert 0.2 ein gibt und die Hysterese weg lässt wird per default aktuell 20 genommen. 0.2 -20 ist bisschen am Ziel vorbei geschossen 

da hast doch zwei möglichkeiten:
1. du prüfst die werte ab und schreibst was ins log oder verweigerst die annahme solcher werte (userfreundlicher)
2. du lässt den user leiden, wenn er sowas eingibt, hat er pech gehabt 

[CoolTux]

da hast doch zwei möglichkeiten:
1. du prüfst die werte ab und schreibst was ins log oder verweigerst die annahme solcher werte (userfreundlicher)
2. du lässt den user leiden, wenn er sowas eingibt, hat er pech gehabt 

Abprüfen sollte in der Tat gehen, zu mindestens prüfen ob die Hysterese kleiner ist wie der max Wert. Verweigern geht leider nicht. Aber wir schauen mal.

Ich bin nicht sicher und konnte das auch bisher nicht näher prüfen, aber mit der github-devel-Version scheinen manche Rollläden (am WE?) gar nicht zu fahren. Vielleicht hast du eine spontane Idee, ob es da einen Zusammenhang gibt?

Das muss ich mir wenn dann gesondert anschauen. Hoffe der Bug ist nicht zu komplex.

[Beta-User]

ASC_WindParameters - finde ich super. So machen wir das. Na ja das mit den Rest optional ist so eine Sache. Also ja ich werde es so umsetzen, aber!! Wenn der User beim max Wert 0.2 ein gibt und die Hysterese weg lässt wird per default aktuell 20 genommen. 0.2 -20 ist bisschen am Ziel vorbei geschossen 

Kingt gut!

Das mit den -19.8 finde ich jetzt nicht tragisch. Was passiert denn: der obere Level wird irgendwann überschritten. Rollläden gehen nach oben. Soweit ok.
Sie gehen aber nie mehr nach unten (wenn man nicht grade händisch einen passenden Wert in das Windreading schreibt oder die API mal wieder kaputt ist ). So what... Dann hat der User Gelegenheit, die Sinnhaftigkeit seiner Angaben zu prüfen. Aber weh' tut das nicht (wenn prominent sichtbar ist, dass wegen Wind geblockt ist). Bezgl. Sichtbarkeit: eventuell würde es Sinn machen, wenn man sich die internen (Effektiv-) Werte ähnlich anzeigen lassen könnte wie bei den timern?

IMO sollten die defaults 80+% der Fälle sinnvoll abdecken. Dann ist alles gut, wenn die Trefferquote noch besser ist, ist da an sich auch erfreulich, führt dann aber wieder dazu, dass zu wenig über die Konfigurationsmöglichkeiten in Sonderfällen bekannt ist (ganz allgemein, hat nicht speziell was mit ASC zu tun...)

[CoolTux]

ASC_WindParameters - TRIGGERMAX[:HYSTERESE] [DRIVEPOSITION] / Angabe von Max Wert ab dem für Wind getriggert werden soll, Hytsrese Wert ab dem der Windschutz aufgehoben werden soll TRIGGERMAX - HYSTERESE / Ist es bei einigen Rollläden nicht gewünscht das gefahren werden soll, so ist der TRIGGERMAX Wert mit -1 an zu geben.

Ich habe fertig. Hoffe ich. Ich teste das jetzt noch ein paar mal und dann schupse ich es ins Git.