[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.   

[Prof. Dr. Peter Henning]

"Cooles Konfigurations GUI", soso. Aus genau diesem Grund habe ich das schon bei den Modulen Alarm und YAAHM gemacht. Bei Alarm beispielsweise gibt es nur 2 Attribute, in dem einen stecken aber - durch "|" getrennt - diverse Konfigurationsparameter des Devices


Man könnte also für ASC setzen

ASC_Brighness <sensor>|<reading>|<minval>|<maxval>

ASC_Shading  <mode>|<pos>|<direction>[:<leftangle>:<rightangle>]|<elevation>|<temperature>|<cloudy>|<sunny>|<time>


und hätte somit immer alle zusammengehörigen Daten in einem Attribut (und damit mit nur einem Lesevorgang aus dem Hash zu holen)

LG

pah

Ich ergänze das mal. Wenn an der 3. Position nur ein Wert steht => direction, Annahme +- 45 Grad Wenn dort 2 Werte stehen: Linker und rechter Begrenzungswinkel. Und wenn dort 3 Werte stehen (durch : getrennt) => direction,delta-links und delta-rechts wie gehabt.


Und noch eine Ergänzung: Ich habe mein FHEM-Buch jetzt schon ziemlich fertig, im Mai ist deadline. Wenn das extra eingefügte Unterkapitel zu ASC aktuell sein soll, müsste ich vorher im Stande sein, das auf weniger Attribute umzuschreiben.

[Beta-User]

Gebe dir recht, vieles ist einfacher zu verstehen, wenn man kurz nachfragen kann und so direkt klären.

Andererseits: wie bereits erläutert, fehlt mir z.B. der IT-technische Background völlig, wie ASC zukünftig dann konfiguriert werden könnte, also ob dazu z.B. ein eigenes .js (wie z.B. bei YAAHM) benötigt werden würde oder ob alles "mit Bordmitteln" zu machen ist. Ich würde gerne vermeiden, dass wir in dieselbe Falle tappen wie mit den Attributen und jetzt Festlegungen treffen, die im Falle einer öffentlichen Disskussion anders ausgefallen wären.

(Siehe dazu nur den m.E. sehr konstruktiven Beitrag von pah eben!)

Wenn, sollte also genug Sachkompetenz vertreten sein; ich bin dabei und äußere auch meine Gedanken v.a. im Sinne der useability gerne, aber bei allem anderen muß ich erfahrungsgemäß oft erst intensiv nachdenken und manches ausprobieren; das ist nicht grade "einfach entscheiden" .

Aber im Prinzip stimme ich dir zu, wir sollten jedenfalls damit (Konferenz) starten und dann ggf. schauen, ob und wo wir da ggf. auch Unterstützung brauchen.

[justme1968]

mehrere zusammengehörige parameter  in ein attribut zu packen hat den nachteil das readingsGroup nicht mehr geht. wenn einem das egal ist: warum nicht.

aber ich würde vorschlagen eine andere syntax vorschlagen und device:reading bzw. parameter=wert zu verwenden. das ist spätestens bei mehr als 2 parametern besser lesbar, besser erweiterbar und man kann jederzeit nicht benötigte parameter weg lassen.

mit parseParams gibt es in fhem auch eine standard routine die das parsen übernimmt und dir werte in einen hash steckt.

[CoolTux]

mehrere zusammengehörige parameter  in ein attribut zu packen hat den nachteil das readingsGroup nicht mehr geht. wenn einem das egal ist: warum nicht.

aber ich würde vorschlagen eine andere syntax vorschlagen und device:reading bzw. parameter=wert zu verwenden. das ist spätestens bei mehr als 2 parametern besser lesbar, besser erweiterbar und man kann jederzeit nicht benötigte parameter weg lassen.

mit parseParams gibt es in fhem auch eine standard routine die das parsen übernimmt und dir werte in einen hash steckt.

Danke Andre, mit parseParams habe ich schon im Zuge der 59_Weather.pm Umstellung gearbeitet.

Meine zukünftige Vorstellung/Traum ist das wir die Rolläden Devices gar nicht mehr anfassen müssen. Alle Rolläden werden im ASC Device erfasst und dann über ein GUI entsprechend konfiguriert. Diese Konfig muss/wird dann "restart sicher" gespeichert. Man wächst als Entwickler ja auch mit der Herausforderung 

[justme1968]

das ist gut.

aber ich würde die device spezifischen parameter trozdem ins device stecken.

zur not mit einem . am anfang des reading oder attribut namen um sie zu verstecken.

dann hast du alles was zusammen gehört auch zusammen. löschen, umbenennen, kopieren, ... geht alles automatisch.

und es fängt nicht plötzlich jeder an alles selber zu machen so das wir am ende 100 eigene config files von 100 modulen haben.

und es gibt zumindest die chance das man auch ein alternatives frontend bauen/verwenden kann. es nutzt ja nicht jeder das frontend für das du dein gui schreibst.

[CoolTux]

das ist gut.

aber ich würde die device spezifischen parameter trozdem ins device stecken.

zur not mit einem . am anfang des reading oder attribut namen um sie zu verstecken.

dann hast du alles was zusammen gehört auch zusammen. löschen, umbenennen, kopieren, ... geht alles automatisch.

und es fängt nicht plötzlich jeder an alles selber zu machen so das wir am ende 100 eigene config files von 100 modulen haben.

und es gibt zumindest die chance das man auch ein alternatives frontend bauen/verwenden kann. es nutzt ja nicht jeder das frontend für das du dein gui schreibst.

Jetzt hast Du mich aber neugierig gemacht mein Lieber. Das man Readings verstecken kann wusste ich, aber das dies auch mit Attributen geht ist mir neu. Das wäre ja ein riesen Schritt und Knüller in meinen Überlegungen 

[justme1968]

klar geht das.

einzige einschränkung: der attribut name taucht halt in der attribut liste auf.

[CoolTux]

klar geht das.

einzige einschränkung: der attribut name taucht halt in der attribut liste auf.

Jepp eben getestet und auch mitbekommen. Aber ich denke damit kann man leben.

[Beta-User]

Wow, bin begeistert...

@CoolTux:
Vielleicht noch nicht zuende gedacht, aber ins unreine: Es wird zukünftig alles (?) als (verstecktes) Reading bei den Rollläden abgelegt. Damit ist es vor dem User verborgen, via ReadingsGroup hat man aber alle Freiheiten, das zu konfigurieren wie bisher.
Dann könnte (fast) alles bleiben, wie es ist, aber wir wären nicht an diese unselige Beschränkung gebunden, die sich aus der userattr-Vorgehensweise ergibt, insbesondere muß hoffentlich nicht alles direkt ausgerollt werden, sondern könnte dann angelegt werden, wenn man es braucht.
Auch die Auswerteroutinen müßten nur geringfügig angepaßt werden (es könnte aber trotzdem sinnvoll sein, dies ggf. zu überdenken).

Haken:
Es steckt dann alle Info in der state-file. Ist an sich nicht schlimm, solange die nicht entweder kaputt ist oder der user z.B. nur "minimalistisch" die cfg umzieht.
Benötigt würde dann vielleicht aber eine Im- und Exportfunktion, um ggf. die ASC-Konfiguration separat zu sichern? (in den MQTT2-attrTemplates gibt es auch Fälle, in denen ein deleteReading <device> .* ausgelöst wird; das wäre dann nicht mehr besonders lustig...).

Danke an alle für die konstrukitve Diskussion!

[CoolTux]

Wow, bin begeistert...

@CoolTux:
Vielleicht noch nicht zuende gedacht, aber ins unreine: Es wird zukünftig alles (?) als (verstecktes) Reading bei den Rollläden abgelegt. Damit ist es vor dem User verborgen, via ReadingsGroup hat man aber alle Freiheiten, das zu konfigurieren wie bisher.
Dann könnte (fast) alles bleiben, wie es ist, aber wir wären nicht an diese unselige Beschränkung gebunden, die sich aus der userattr-Vorgehensweise ergibt, insbesondere muß hoffentlich nicht alles direkt ausgerollt werden, sondern könnte dann angelegt werden, wenn man es braucht.
Auch die Auswerteroutinen müßten nur geringfügig angepaßt werden (es könnte aber trotzdem sinnvoll sein, dies ggf. zu überdenken).

Haken:
Es steckt dann alle Info in der state-file. Ist an sich nicht schlimm, solange die nicht entweder kaputt ist oder der user z.B. nur "minimalistisch" die cfg umzieht.
Benötigt würde dann vielleicht aber eine Im- und Exportfunktion, um ggf. die ASC-Konfiguration separat zu sichern? (in den MQTT2-attrTemplates gibt es auch Fälle, in denen ein deleteReading <device> .* ausgelöst wird; das wäre dann nicht mehr besonders lustig...).

Danke an alle für die konstrukitve Diskussion!

Irgendwie denkst Du immer weiter wie ich. Ich hätte jetzt die Attribute gelassen und einfach nur versteckt. Aber die gesamte Konfiguration für die Rolläden als versteckte Readings in den Rolläden zu setzen ist noch viel besser. Oder spricht da was dagegen die Konfiguration so zu speichern?

[Beta-User]

Irgendwie denkst Du immer weiter wie ich. Ich hätte jetzt die Attribute gelassen und einfach nur versteckt. Aber die gesamte Konfiguration für die Rolläden als versteckte Readings in den Rolläden zu setzen ist noch viel besser. Oder spricht da was dagegen die Konfiguration so zu speichern?

Wie gesagt, das ist nur eine spontane Überlegung. Ob es besser ist, sollte man abwägen, ich kenne definitiv nicht alle sinnvollen Optionen.
Zwar schwirrt mir das mit der Reading-Geschichte schon länger im Kopf rum (unversteckt ), aber das war es auch schon.
Bei meinen eigenen Sachen stelle ich manchmal auch fest, dass ich zu sehr "um's Eck" gedacht habe und muß dann nachsteuern. Z.B. ist mir nicht klar, ob man das Reading definiert haben muß, um es mit RG füllen zu können (oder ob es in der setList sein muß bei einem Dummy, was hier ja nicht ginge).

Daher ja vorhin der Hinweis: Leute fragen, die einen besseren Hintergrund haben ...

Und siehe da, wir sind mit einer hohen Wahrscheinlichkeit mit deutlich weniger Aufwand sehr viel weiter gekommen als gedacht .

[Prof. Dr. Peter Henning]

aber ich würde die device spezifischen parameter trozdem ins device stecken.

Ich auch.

IoT bedeutet: Geräte kennen ihre eigenen Attribute, die müssen nicht zentral abgelegt werden. Vor allem können auch andere Routinen dann auf diese Parameter zugreifen.

LG

pah

[dancatt]

Hallo,

wofür sind folgende Attribute am asc-Device?

Code Auswählen Erweitern


ASC_AutoAstroModeEvening
ASC_AutoAstroModeEveningHorizon
ASC_AutoAstroModeMorning
ASC_AutoAstroModeMorningHorizon


Diese gibt es ja auch schon am Rollladendevice.
Kann man diese nicht entfernen? Oder handelt es sich bei diesen Attbriuten um die Defaulteinstellung welche in den Rolllädendevices initial übernommen wird?

Gruß Daniel

[CoolTux]

im ASC Device gelten sie globa für alle und wenn man das in den Rolladen noch einstellt dann wird das verwendet.

[dancatt]

im ASC Device gelten sie globa für alle und wenn man das in den Rolladen noch einstellt dann wird das verwendet.

Ok. Habe ich mir fast gedacht. Vielleicht sollte man die cref etwas ausführlicher beschreiben. Soll kein Kritikpunkt sein. Und eine alphabetische Sortierung der Attribute in der cref sollte man auch noch bei Gelegenheit machen.

Vielen Dank.

[CoolTux]

Ok. Habe ich mir fast gedacht. Vielleicht sollte man die cref etwas ausführlicher beschreiben. Soll kein Kritikpunkt sein. Und eine alphabetische Sortierung der Attribute in der cref sollte man auch noch bei Gelegenheit machen.

Vielen Dank.

Würde mich sehr über Unterstützung freuen. Einfach machen und dann bei mir hier einreichen 

Grüße

[Beta-User]

Ähm, kurzer Zwischenruf:

Alphabetisch finde ich persönlich jetzt nicht soo prickelnd (die jetzige Reihenfolge ist aber tatsächlich verbesserungsfähig). Das wird zwar in vielen Fällen passen, weil die Benennung aufeinander Bezug nimmt, aber vielleicht wäre es eine Überlegung, das zum einen so zu gruppieren, dass zusammengehörige Dinge untereinander stehen (Beispiel: Erst der Temp-Sensor, dann das Reading, dann die freeze-Temp, da vielleicht dann noch die Beschattungs-Temp(?)) und zum anderen irgendwie eine Reihenfolge der Gruppe gewählt wird, die den User eher bei der Einrichtung "begleitet" (ist noch nicht "fertig überlegt").