Moin,
sh-ng gibt einem ja jede Freiheit die Items so zu benennen, wie man es möchte.
Ich denke, wir würden davon profitieren, etwas Freiheit aufzugeben.
Beispielsweise bei den Wetter-Plugins, beim AVR-Plugin, aber auch bei den RTR-Items würden mir Beispiele einfallen:
1) Wetter Plugin:
Wie schön wäre es, einfach das Plugin wechseln zu können, wenn mal wieder eine API abgeschaltet wird. Heute muss ich auch die Items anpassen. Wenn es ein Standard-sh.weather-Objekt gäbe mit Sub-Items, die immer da sind, wäre schon viel gewonnen. Plugins können dann zusätzliche Sub-Items implementieren, die aber optional sind und die *nicht* in einer *.yaml konfiguriert werden müssen.
2) AVR-Plugin:
Ich bin sicher, dass die allermeisten die Beispiel-Item.yaml kopieren. Warum nicht gleich das Plugin die Items erzeugen lassen. Das ist weniger fehleranfällig. Und wenn es ein neues Plugin gibt (bei mir der Übergang von Denon zu AVR) dann geht das nahtlos.
3) RTR-Items
Hier denke ich auch an die Schnittstelle zur SmartVisu, die erleichtert werden könnte (widget.RTR('id', 'meinRaum.RTR-Item')).
Darüber hinaus könnten wir langfristig auch "Logikbausteine" erzeugen, die dann Aufgaben übernehmen, die häufig vorkommen. Das geht natürlich heute schon. Aber häufig ist heute durch die unterschiedliche Item-Struktur noch viel Arbeit nötig, eine Logik auf die eigenen Belange umzustricken (das könnte man aber auch durch Geschick bei der Definition der Logik erledigen, indem man ganz oben die Items eigenen Objekten, die in der Logik vorkommen/verwendet werden zuweist. das geht aber nur solange, wie man nicht in der Logik die Struktur von Items verwendet (z.b. for mein_raum in [sh.Wohnzimmer, sh.Esszimmer]: mein_raum.rtr.soll=28).
Was denkt ihr?
Gruß,
Hendrik
sh-ng gibt einem ja jede Freiheit die Items so zu benennen, wie man es möchte.
Ich denke, wir würden davon profitieren, etwas Freiheit aufzugeben.
Beispielsweise bei den Wetter-Plugins, beim AVR-Plugin, aber auch bei den RTR-Items würden mir Beispiele einfallen:
1) Wetter Plugin:
Wie schön wäre es, einfach das Plugin wechseln zu können, wenn mal wieder eine API abgeschaltet wird. Heute muss ich auch die Items anpassen. Wenn es ein Standard-sh.weather-Objekt gäbe mit Sub-Items, die immer da sind, wäre schon viel gewonnen. Plugins können dann zusätzliche Sub-Items implementieren, die aber optional sind und die *nicht* in einer *.yaml konfiguriert werden müssen.
2) AVR-Plugin:
Ich bin sicher, dass die allermeisten die Beispiel-Item.yaml kopieren. Warum nicht gleich das Plugin die Items erzeugen lassen. Das ist weniger fehleranfällig. Und wenn es ein neues Plugin gibt (bei mir der Übergang von Denon zu AVR) dann geht das nahtlos.
3) RTR-Items
Hier denke ich auch an die Schnittstelle zur SmartVisu, die erleichtert werden könnte (widget.RTR('id', 'meinRaum.RTR-Item')).
Darüber hinaus könnten wir langfristig auch "Logikbausteine" erzeugen, die dann Aufgaben übernehmen, die häufig vorkommen. Das geht natürlich heute schon. Aber häufig ist heute durch die unterschiedliche Item-Struktur noch viel Arbeit nötig, eine Logik auf die eigenen Belange umzustricken (das könnte man aber auch durch Geschick bei der Definition der Logik erledigen, indem man ganz oben die Items eigenen Objekten, die in der Logik vorkommen/verwendet werden zuweist. das geht aber nur solange, wie man nicht in der Logik die Struktur von Items verwendet (z.b. for mein_raum in [sh.Wohnzimmer, sh.Esszimmer]: mein_raum.rtr.soll=28).
Was denkt ihr?
Gruß,
Hendrik
Kommentar