[73_AutoShuttersControl.pm] - Diskussion um Attributsänderungen

[CoolTux]

Ich stimme den Usern zu welche sagen das ASC zu viele Attribute hat und diese einen erschlagen. Daher stelle ich zur Diskussion einige davon zusammen zu fügen.
Nicht desto trotz wird es auf jeden Fall noch eine gänzlich andere Art der Konfiguration geben, aber bis dahin wäre ein zusammen fügen sicherlich nützlich. Dies soll natürlich sofern entschieden einen sanften Übergang nehmen.

Folgende Idee. Ich habe bereits Angefangen bei Wind die Min und Max Werte in einem Attribut zusammen zu nehmen, getrennt durch ein :
Das klappt sehr gut und ich würde dies für folgende Attribute fortführen wollen

• ASC_BrightnessMinVal und ASC_BrightnessMaxVal
• ASC_brightnessMinVal und ASC_brightnessMaxVal das selbe wie oben, im ASC Device
• ASC_Shading_Angle_Left und ASC_Shading_Angle_Right, wobei ich hier denke das auch ein einziges reichen sollte da man wahrscheinlich eh selbige Werte nimmt.
• ASC_Shading_StateChange_Cloudy und ASC_Shading_StateChange_Sunny - hier sollte man einen kürzeren Namen versuchen zu finden

Sieht erstmal nicht viel aus, wäre aber immer hin ein Anfang bis das coole Konfigurations Gui kommt 

[kjmEjfu]

• ASC_Shading_Angle_Left und ASC_Shading_Angle_Right, wobei ich hier denke das auch ein einziges reichen sollte da man wahrscheinlich eh selbige Werte nimmt.

Nee, ein Wert reicht da nicht unbedingt. Ich habe ein Fenster im Anbau, dass durch einen Mauervorsprung nur kurzen "Vorlauf" hat, aber einen längeren "Nachlauf". Es würde natürlich nicht weh tun, wenn es jetzt schon früher abschatten würde, aber sinnvoller ist die jetzige Regelung mit zwei Werten.

Ansonsten finde ich den Ansatz Attribute zusammenzulegen sehr gut.

[stefanpf]

Aber aus ASC_Shading_Angle_Left, ASC_Shading_Angle_Right und ASC_Shading_Pos könnte man

zwei Attribute ASC_Shading_From_Pos und ASC_Shading_To_Pos machen.
Oder diese beiden Werte in einem Attribut zusammenführen.

[CoolTux]

Na ich habe das schon verstanden.
Daraus wird dann
ASC_Shading_Angle_LeftRight: 85:70
oder vielleicht sogar bisschen kürzer. Mal schauen. 

[Beta-User]

 
Danke für's Aufgreifen!
Ist auch sehr gut, das getrennt zu diskutieren.

Mei, hier ist ja was los, zwei neue Beträge während des Tippens...

In der Sache:
- Solange das ganze über Attribute läuft, würde ich anregen, erst mal nur zusammenzufassen, was mehr oder weniger unveränderlich ist, der Einrichtende also in der Regel nur einmal anfassen muß. Das paßt auf die Winkelangaben, aber vermutlich nicht auf Brightness-Grenzen (das muß man erst austestten. Besser eignen sich m.E. auch die ganzen "Input-" Geräte (Temperatursensoren usw.), also alles, wo derzeit das Reading extra angegeben wird.
Alles andere führt m.E. nur zu unnützen Diskussionen.

- Konkret für das Winkelthema würde ich vorschlagen, alle drei Werte (Ausrichtung, Abweichung links, Abweichung rechts) in _ein einziges_ Attribut zu packen. Auswerte-Logik: Ausrichtung ist ein "Muß", Abweichungen sind optional, default: 85. Ist nur eine Abweichung links angegeben, gilt das auch für rechts.
Also:
-- "180" = Südausrichtung, Beschattungsbeginn ab 180-85=95, Beschattungsende ab 180+85=265.
-- "155:60" = ca. SSO, Beschattungsbeginn ab 155-60=95, Beschattungsende ab 155+60=215.
-- "155:60:35" = ca. SSO, Beschattungsbeginn ab 155-60=95, Beschattungsende ab 155+35=190.
Anmerkungen:
--- Wir könnten die Logik gleich so drehen, dass die effektiven Winkel anzugeben sind, also im letzten Beispiel 155:95:190.
--- Fehlende Angaben nach rechts mit den 85° default bewerten? Das ergäbe in der Notation "155:60" ein Beschattungsende ab 155+85=265. Wäre evtl. logischer, weil in der Regel ja nur eine Seite später bzw. früher verschattet werden wird.

- Für die Sensoren:
-- Tempsensor:Reading = wie bisher, nur zusammengefaßt
-- Tempsensor (ohne Readingangabe: Tempsensor, es wird erst geschaut, ob es ein "typisches" Reading gibt (hier: "temperature"), wenn nicht, wird "state" verwendet.
Das ganze dann entsprechend für Brightness und was es sonst noch so alles gibt.

Soviel mal als erster Wurf, mir fällt bestimmt noch was ein .

Gruß, Beta-User

[CoolTux]

Danke für's Aufgreifen!
Ist auch sehr gut, das getrennt zu diskutieren.

Mei, hier ist ja was los, zwei neue Beträge während des Tippens...

In der Sache:
- Solange das ganze über Attribute läuft, würde ich anregen, erst mal nur zusammenzufassen, was mehr oder weniger unveränderlich ist, der Einrichtende also in der Regel nur einmal anfassen muß. Das paßt auf die Winkelangaben, aber vermutlich nicht auf Brightness-Grenzen (das muß man erst austestten. Besser eignen sich m.E. auch die ganzen "Input-" Geräte (Temperatursensoren usw.), also alles, wo derzeit das Reading extra angegeben wird.
Alles andere führt m.E. nur zu unnützen Diskussionen.

- Konkret für das Winkelthema würde ich vorschlagen, alle drei Werte (Ausrichtung, Abweichung links, Abweichung rechts) in _ein einziges_ Attribut zu packen. Auswerte-Logik: Ausrichtung ist ein "Muß", Abweichungen sind optional, default: 85. Ist nur eine Abweichung links angegeben, gilt das auch für rechts.
Also:
-- "180" = Südausrichtung, Beschattungsbeginn ab 180-85=95, Beschattungsende ab 180+85=265.
-- "155:60" = ca. SSO, Beschattungsbeginn ab 155-60=95, Beschattungsende ab 155+60=215.
-- "155:60:35" = ca. SSO, Beschattungsbeginn ab 155-60=95, Beschattungsende ab 155+35=190.
Anmerkungen:
--- Wir könnten die Logik gleich so drehen, dass die effektiven Winkel anzugeben sind, also im letzten Beispiel 155:95:190.
--- Fehlende Angaben nach rechts mit den 85° default bewerten? Das ergäbe in der Notation "155:60" ein Beschattungsende ab 155+85=265. Wäre evtl. logischer, weil in der Regel ja nur eine Seite später bzw. früher verschattet werden wird.

- Für die Sensoren:
-- Tempsensor:Reading = wie bisher, nur zusammengefaßt
-- Tempsensor (ohne Readingangabe: Tempsensor, es wird erst geschaut, ob es ein "typisches" Reading gibt (hier: "temperature"), wenn nicht, wird "state" verwendet.
Das ganze dann entsprechend für Brightness und was es sonst noch so alles gibt.

Soviel mal als erster Wurf, mir fällt bestimmt noch was ein .

Gruß, Beta-User

Ich musste Dein Beschattungsbeispiel dreimal lesen. Kann an mir liegen aber wenn wir das so dem User noch erklären müssen wird es schwierig. Bei einfachen Dingen geht sowas. Aber Dein Beispiel ist glaube wieder zu viel des guten.
Ob man nun Brightnessgrenzen austesten muß oder nicht ist denke ich egal, das machste eine Woche mit einem oder 2 Werte am Tag ändern und dann passt das. Ich sehe da jetzt kein konkretes großes Änderungsintervall.

An das Thema Sensor:Reading denke ich. Und ich glaube auch eine einfache Lösung gefunden zu haben. ABER
Wir müssen an die User denken und kleine Schritte gehen. Uns und vor allem den Usern ist nicht geholfen wenn wir mit der aktuellen Version große Sprünge machen. Ich will versuchen das fließend ein zu bringen. Neue Attribute dazu, wenn das eine Weile läuft die alten entfernen. Stück für Stück. Auf die Weise können die neuen Attribute Ihre Werte aus den alten lesen und so muss der User nichts an der bestehenden Konfig an fassen.

[kjmEjfu]

Ich musste Dein Beschattungsbeispiel dreimal lesen. Kann an mir liegen aber wenn wir das so dem User noch erklären müssen wird es schwierig. Bei einfachen Dingen geht sowas. Aber Dein Beispiel ist glaube wieder zu viel des guten.

Wobei grundsätzlich finde ich den Gedanken gar nicht schlecht. Wieso muss man eigentlich die Ausrichtung des Fensters angeben und zusätzlich einen Winkel rechts und links. Die Ausrichtung alleine wird doch (vermute ich) nirgendwo benötigt. Wieso nicht einfach nur den Abschattungswinkel angeben? Dann spart man sich schon ein Attribut und die beiden anderen kann man als einen Winkel zusammenfassen.

[CoolTux]

Der Ausrichtungswinkel ist entscheidend. Auf Basis dieser Angabe wird der eigentliche Beginn und das eigentliche Ende einer Beschattung berechnet.

[kjmEjfu]

Der Ausrichtungswinkel ist entscheidend. Auf Basis dieser Angabe wird der eigentliche Beginn und das eigentliche Ende einer Beschattung berechnet.

Aber doch nur, weil das im Moment so angelegt ist, oder?
Wenn du weißt, ein Fenster hat den Abschattungswinkel 60 bis 180, dann hast du doch direkt Anfang und Ende und musst gar nicht mehr rechnen. Oder habe ich mal wieder einen Denkfehler?

[CoolTux]

Aber doch nur, weil das im Moment so angelegt ist, oder?
Wenn du weißt, ein Fenster hat den Abschattungswinkel 60 bis 180, dann hast du doch direkt Anfang und Ende und musst gar nicht mehr rechnen. Oder habe ich mal wieder einen Denkfehler?

Ah so meinst Du das. Da hast Du dann Recht. Wenn man den Ein und Austrittwinkel direkt an gibt dann geht das auch. Ich hatte damals alles erstmal so von Bernd übernommen um Kompatibel zu seinem Script zu bleiben.

[Beta-User]

Ob es mit den drei Angaben zu kompliziert ist, weiß ich nicht, deswegen diskutieren wir ja.

Aber ich finde die Angabe der Ausrichtung ist einfacher zu erläutern und wird häufig ja schon reichen, wenn es nichts gibt, was beschattet. Und für die "Feinheiten" wird sich erst der user "erwärmen", der ein "Problem" hat... Daher denke ich eigentlich nicht, dass es zu kompliziert ist, weil eben in der Regel eine einzige Angabe ausreichend ist .

[FunkOdyssey]

Natürlich fände ich weniger Attribute ganz nett.
Aber verlieren wir dann nicht die Möglichkeit, mit readingsGroups die Werte zu verändern?

Nachtrag: Ah, ich habe jetzt erst den Hauptthread zu Ende gelesen. Das Thema ist euch natürlich bekannt. 😄

[CoolTux]

Natürlich fände ich weniger Attribute ganz nett.
Aber verlieren wir dann nicht die Möglichkeit, mit readingsGroups die Werte zu verändern?

Ein ziemlich starkes Argument.
@Beta-User wie siehst Du das? Du hattest ja die readingsGroups gemacht gehabt.

[Beta-User]

Natürlich fände ich weniger Attribute ganz nett.
Aber verlieren wir dann nicht die Möglichkeit, mit readingsGroups die Werte zu verändern?

Nachtrag: Ah, ich habe jetzt erst den Hauptthread zu Ende gelesen. Das Thema ist euch natürlich bekannt. 😄

Korrekt.
Deswegen die Begrenzung auf Dinge, die man nur einmal eingibt.

Ist übrigens auch ein Pro für die 3-er-Winkel-Notation: Wer nur mal schnell die eine Ausrichtung eingeben will, der könnte das weiterhin tun wie bisher . Nur die optionalen Dinge würden wegfallen bzw. ggf. auch gelöscht, wenn man sie mit der rG nochmal anfaßt (aber auch nur dann).

[CoolTux]

Ich merke schon. Wir müssen da mal ganz dringend eine Konferenz mit einem gewissen Kern machen und dann einfach entscheiden.