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

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