UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Garfonso]

@Samson71
Keine Ahnung, was diese Angriffe und Unterstellungen immer sollen...

Wenn du die Weißheit so mit Löffeln gefressen hast, dann lös halt mal das Problem vor dem ich gerade mit Lovelace stehe:
Der type-detector erkennt anhand von Zuständen mit Rolle level.blind "Rolladen". Die will ich auf das Gerät "Rolladen" in Lovelace mappen, das zwingend 0%=zu/100%=offen hat. Woran kann Lovelace erkennen, ob dieser State nun genauso ist oder das ganze rumgedreht werden muss.
Klar, kann man den User da wieder zu zwingen alles von Hand zu konfigurieren... Abgesehen von dem extremen Aufwand (da aktuell alles sehr automatisch geht), ist man dann aber halt auch nicht "Smart", sondern eher in der Richtung: "Man sieht doch, was passiert, warum braucht man dann schon bidirektionale Kommunikation oder klare Definitionen, was passieren sollte"...

Ich finde jedenfalls einen "Zwangsunstandard" in dem jeder Adapter seinen Mist in die Datenbank rotzt, wie er ihn gerade kriegt, ziemlich doof... Gewachsene Strukturen kann man nicht einfach umstricken, das ist klar, daher auch schon einige gute Vorschläge in dem Thread, wie man das parallel laufen lassen könnte. Daher ist dieses Fabulieren von "Zwangsstandard" wirklich absurd... dann noch mit der Idee, dadurch Geld zu verdienen? Das musst du mir echt erklären... oder lieber nicht.

[dj.tifosi]

Verstehe nicht, was das Problem daran wäre, den Adapterentwicklern zusätzlich zum Datentyp level.blind noch 2 weitere Datentypen level.opened sowie level.closed zur Verfügung zu stellen.

Dann könnten sie den bestehenden Datenpunkt vom Typ level.blind, auf dem sie derzeit ihre Implementierung aufgebaut haben, in einer späteren Adapter-Version auf level.opened oder level.closed umziehen.

Man kann die Entwickler, die derzeit level.blind verwenden ja auch explizit darüber informieren, dass sich hier Schnittstellen ändern und sie ihre Implementierung bitte darauf anpassen sollen, um auch weiterhin kompatibel zu sein.

Das Vorgehen hätte folgende Vorteile:

• Die Semantik des Datenpunkts im Adapter bleibt dieselbe (bei Homematic entspricht ein Wert von 100 % immer noch offen und bei KNX entsprechend geschlossen), man muss sich nicht umgewöhnen, man hat keine Unterschiede des Wertes zwischen Iobroker und der SmartHome-Zentrale (z. B. CCU2) es müssen keine Scripte / Blocklys vom Anwender angepasst werden, Änderung ist für den Anwender schmerzfrei und völlig transparent
• Nach Umzug des Datenpunkts auf level.opened oder level.closed ist auch eine einheitliche Darstellung in der VIS sowie eine einheitliche Steuerung von Rolladensystemen verschiedener Hersteller durch übergeordnete Adapter wie Shuttercontrol möglich, ohne dort zusätzlich definieren zu müssen, wie der Prozentwert zu interpretieren ist, denn der Adapter weiß ja aufgrund des Datentyps, wie er mit diesem umzugehen hat oder was ein Wert von 100 % bedeutet
• Es ist keine Migration mit der Brechstange, der Datentyp level.blind kann ja noch bestehen bleiben, solange noch nicht alle umgezogen sind, er bekommt erstmal nur den Status deprecated und sollte nicht mehr für Neuentwicklungen verwendet werden, denn das Ziel ist ja, ihn irgendwann los zu werden

[Samson71]

@Garfonso sagte in [Umfrage] Rolladenposition in % was ist logischer?:

@Samson71
Keine Ahnung, was diese Angriffe und Unterstellungen immer sollen...

Lies einfach richtig. Ich greife niemanden an und unterstelle auch nichts. In der Abstimmung geht es aber um entweder oder, also um eine Entscheidung. Dort ist kein "dritter Weg" mit Wahlmöglichkeiten genannt. Darauf habe ich mich ganz klar bezogen und das halte ich nicht für zielführend. Daraus eine feste Vorgabe zu entwickeln erscheint mir nicht sinnvoll. Punkt. Nicht mehr und nicht weniger.

[braindead]

Ich halte es für problematisch, wenn Adapter Werte umwandeln und die Werte damit nicht mehr zu denen des Ursprungssystems passen. Der ioBroker spricht eine breite Masse von Usern an und ich denke gerade Anfänger werden hier Probleme haben, nicht verstehen (wollen) warum das so ist und massiv Supportanfragen stellen. Wenn ich alleine sehe welch simple Fragen bei Facebook aufpoppen, wird mir anders.

Ehrlich gesagt habe ich mir über die Rollen eines Datenpunktes bisher keine Gedanken gemacht und ich tippe darauf, dass es vielen Usern (der breiten Masse) so geht. Ich bin deshalb grundsätzlich bei @dj-tifosi, würde ihn aber etwas abwandeln:

Es sollte die Rollen value.blind.opened und value.blind.closed (bzw. level.blind.opened und level.blind.closed) geben. Im Falle von Homematic hat der DP die Rolle value.blind.opened und im Falle von KNX value.blind.closed.

Vorteil ist, dass die Werte im ioBroker zu denen des Ursprungssystems passen und sich kein User umgewöhnen muss. Andere Adapter, die mit diesen DPs arbeiten erkennen anhand der Rolle eindeutig was die DPs zeigen und alles ist smart.

[siggi85]

Vom Grundsatz her und auch langfristig gesehen würde ich einen Standard bevorzugen. Hier ist ioBroker aber vielleicht der falsche Ansatz; die Hersteller müssten sich hier auf ein einheitliches Vorgehen einigen und das wird so schnell wohl nicht passieren. Dann wäre die Diskussion in einem System wie ioBroker obsolet.
Und da die Ansicht der Leute ziemlich gleich verteilt ist (was man zu Beginn der Anfrage natürlich nicht wissen konnte, also noch die Idee bestand nur einen Wert als Standard zu schaffen), sollte es wohl auf mehrere Datenpunkte hinauslaufen:
level.blind.opened
level.blind.closed

Auch wenn ich finde, dass jemand der 100% als "Markise eingefahren" betrachtet, die Kontrolle über sein Leben verloren hat. :joy: (Nur Spaß um die Stimmung zu lockern ;) )

[Xyolyp]

Ich bin der Meinung, dass es egal ist wie herum es standardisiert wird. Das einzige was fehlt damit es wirklich egal ist wäre eine für jeden Anwender verständliche Oberfläche, um alias Datenpunkte zu erstellen und zu pflegen. Hierbei geht es insbesondere um die erweiterten Funktionen (invertieren/umrechnen von Werten) da sobald jeder Anwender dies tun kann keine Notwendigkeit besteht als Adapterentwickler alles genau so zu machen wie es der Anwender sich wünscht.

[Jey Cee]

@siggi85 sagte in [Umfrage] Rolladenposition in % was ist logischer?:

Und da die Ansicht der Leute ziemlich gleich verteilt ist

Das mag hier im Forum so sein, aber die selbe Umfrage auf Facebook Zeigt ein anderes Bild. Da sind fast 2/3 für Option 2. Die Beteiligung ist dort mit 336 Stimmen auch nicht ohne, hier sind es jetzt erst 65 Stimmen.

[ldittmar]

Also... Zum Glück gibt es Alias, denn da kann man die Werte entsprechend anpassen. Wenn ich jetzt 2 Rollos hätte und beide würde unterschiedlich sein... der eine offen bei 0% und der andere bei 100%, dann würde ich es beim Alias einfach anpassen, damit beide bei 100% offen sind... ganz einfach ;-)

[haus-automatisierung]

Wie wäre es denn, wenn man den Adapter-Entwicklern vorschlägt, für jeden Datenpunkt einen weiteren (invertierten) Datenpunkt anzulegen. Dann ist jeder glücklich und man kann für die Visualisierungen auch frei wählen, was man gerade braucht.

Macht es natürlich etwas komplexer für Anfänger, aber wäre zumindest nachvollziehbar und man lässt die originalen Zustände so, wie sie vom Hersteller des Systems gedacht sind.

[simatec]

@haus-automatisierung sagte in [Umfrage] Rolladenposition in % was ist logischer?:

Wie wäre es denn, wenn man den Adapter-Entwicklern vorschlägt, für jeden Datenpunkt einen weiteren (invertierten) Datenpunkt anzulegen. Dann ist jeder glücklich und man kann für die Visualisierungen auch frei wählen, was man gerade braucht.

So würde ich es jetzt bei shuttercontrol umsetzen. Shuttercontrol arbeitet mit 100% = offen und 0% = geschlossen.
Diese Werte kann man dann optionalen invertieren und genau umgekehrt an sein Aktoren senden

[AlCalzone]

@haus-automatisierung sagte in [Umfrage] Rolladenposition in % was ist logischer?:

Wie wäre es denn, wenn man den Adapter-Entwicklern vorschlägt, für jeden Datenpunkt einen weiteren (invertierten) Datenpunkt anzulegen.

Klingt gut.

Aber was, wenn der Adapter nicht weiß, ob es sich um einen Rolladen bzw. Beschattungsgerät handelt?
Beispiel: Z-Wave (Multilevel Switch). Dahinter kann sich eine Lampe oder ein Rolladen oder ganz was anderes verstecken.

[StrathCole]

@AlCalzone sagte in [Umfrage] Rolladenposition in % was ist logischer?:

Beispiel: Z-Wave (Multilevel Switch). Dahinter kann sich eine Lampe oder ein Rolladen oder ganz was anderes verstecken.

Dann darf der Datenpunkt ja auch kein level.blind haben. Sonst ist ja festgelegt, dass es ein Beschattungsgerät / Rollladen ist und keine Lampe.

Ich bin auch der Meinung, dass separate Roles, also level.opened.blind oder level.closed.blind sinnvoll wären wie oben vorgeschlagen, damit wäre die ganze Diskussion müßig und allen geholfen ;-)

[Knallochse]

@Jey-Cee sagte in [Umfrage] Rolladenposition in % was ist logischer?:

Das mag hier im Forum so sein, aber die selbe Umfrage auf Facebook Zeigt ein anderes Bild. Da sind fast 2/3 für Option 2. Die Beteiligung ist dort mit 336 Stimmen auch nicht ohne, hier sind es jetzt erst 65 Stimmen.

Wäre bestimmt sinnvoll, wenn man im Eröffungsthread darauf hinweisen würde das es mehrere Abstimmungen gibt.

[AlCalzone]

@StrathCole sagte in [Umfrage] Rolladenposition in % was ist logischer?:

Dann darf der Datenpunkt ja auch kein level.blind haben.

Stimmt... Ich brauch Kaffee :sweat_smile:

[StrathCole]

Konkret noch mal aus den Vorschlägen zusammengefasst mein aktueller Favorit:

• level.blind und value.blind als deprecated markieren und für neue Adapter im Stable nicht mehr zulassen.
• level.opened (oder level.open), level.closed (oder level.close) und die entsprechenden value. Roles einführen als übergeordnete Roles
• level.opened.blind usw. als Spezialroles für Rollladen und Markise etc. so wie es aktuell level.blind für level ist.

Damit müssten die Adapter-Ersteller und Adapter-User nicht alles umbauen, aber dennoch könnten Vis etc. anhand der Role alles automatisch festlegen.

[Garfonso]

@haus-automatisierung said in [Umfrage] Rolladenposition in % was ist logischer?:

Macht es natürlich etwas komplexer für Anfänger, aber wäre zumindest nachvollziehbar und man lässt die originalen Zustände so, wie sie vom Hersteller des Systems gedacht sind.

Welcher Hersteller "denkt" sich denn bei so etwas, was? Das wird hier irgendwie viel zu heilig gesprochen. Und die Geräte / das System des Herstellers kriegt ja eh die Werte, die es braucht. Das Argument verstehe ich nicht wirklich.

@haus-automatisierung said in [Umfrage] Rolladenposition in % was ist logischer?:

Wie wäre es denn, wenn man den Adapter-Entwicklern vorschlägt, für jeden Datenpunkt einen weiteren (invertierten) Datenpunkt anzulegen. Dann ist jeder glücklich und man kann für die Visualisierungen auch frei wählen, was man gerade braucht.

Der invertierte Datenpunkt macht auch nur dann Sinn, wenn man festlegt, was "nicht invertiert" ist. Um die Festlegung käme man auch da nicht. Wenn man eine anderes Kriterium (wie z.B. die Rolle) hat, mit der man klar machen kann, wierum der Datenpunkt ist, reicht das völlig.

Und den Punkt mit der Visualisierung: Mein Ziel wäre, dass genau das nicht mehr passiert. Also der User kann nach seiner Überlegung sagen 100% ist oben = offen oder 100% ist unten = zu und das in seiner Visualisierung so machen. Dann stellt er den Datenpunkt ein und die Visualisierung erkennt: "ok, ist so wie dargestellt" oder "ok, muss ich rumdrehen". Eine Entkopplung von Hardware und Visualisierung, wenn man so will. Das hilft dann auch, wenn man mal die Hardware wechseln sollte, da ist dann ein Punkt weniger, bei dem man beim Kaufen drauf achten muss. ;-)

[Garfonso]

@StrathCole said in [Umfrage] Rolladenposition in % was ist logischer?:

Konkret noch mal aus den Vorschlägen zusammengefasst mein aktueller Favorit:

• level.blind und value.blind als deprecated markieren und für neue Adapter im Stable nicht mehr zulassen.
• level.opened (oder level.open), level.closed (oder level.close) und die entsprechenden value. Roles einführen als übergeordnete Roles
• level.opened.blind usw. als Spezialroles für Rollladen und Markise etc. so wie es aktuell level.blind für level ist.

Damit müssten die Adapter-Ersteller und Adapter-User nicht alles umbauen, aber dennoch könnten Vis etc. anhand der Role alles automatisch festlegen.

Ja, die Lösung finde ich auch sehr gut.

[ldittmar]

@Garfonso sagte in [Umfrage] Rolladenposition in % was ist logischer?:

Eine Entkopplung von Hardware und Visualisierung, wenn man so will. Das hilft dann auch, wenn man mal die Hardware wechseln sollte, da ist dann ein Punkt weniger, bei dem man beim Kaufen drauf achten muss. ;-)

Alias nutzen.... Es müsste alles auf Alias aufgebaut werden, denn da kann man alles mit dem Werten machen... komplett entkoppelt von der Hardware. Da kann man "einfach" die Werte invertieren und würde es immer funktionieren, ohne die originale Werte der Hardware zu verändern. - Ich arbeite nur noch mit Alias und je mehr ich damit mache umso wichtiger finde ich es. (Meine Meinung)

[Garfonso]

@ldittmar
Da bin ich ganz deiner Meinung. Um mich selber dazu zu zwingen das auch konsequent zu nutzen, habe ich z.B. in Lovelace eine Option eingebaut, dass nur Geräte aus dem Alias Pfad genutzt werden. Sollte man m.E. bei jeder Vis als Option machen, (und irgendwann per default auf an) und ggf. auch bei Skripten. ;-)

[Garfonso]

@Jey-Cee said in [Umfrage] Rolladenposition in % was ist logischer?:

@siggi85 sagte in [Umfrage] Rolladenposition in % was ist logischer?:

Und da die Ansicht der Leute ziemlich gleich verteilt ist

Das mag hier im Forum so sein, aber die selbe Umfrage auf Facebook Zeigt ein anderes Bild. Da sind fast 2/3 für Option 2. Die Beteiligung ist dort mit 336 Stimmen auch nicht ohne, hier sind es jetzt erst 65 Stimmen.

Und das obwohl dort die "Rolladenöffnung" ebenfalls verwendet wurde und noch immer so steht.