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

[paul53]

@Homoran sagte:

wenn ich das jetzt ändere

Das erwartet niemand. Es geht um neue Adapter, nicht um bestehende Adapter mit ihren (künftigen) Updates.

[StrathCole]

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

Es geht um neue Adapter, nicht um bestehende Adapter mit ihren (künftigen) Updates.

Das würde aber nicht viel Einheit schaffen, denn die großen sind ja eigtl. schon fast alle da.

[paul53]

@StrathCole sagte:

Das würde aber nicht viel Einheit schaffen

Das ist nach Jahren der Nutzung in vielen Skripten und Visualisierungen auch nicht zumutbar.

[Homoran]

@paul53
Bliebe nur die Möglichkeit zu jedem State einen "inverted state" hinzuzubasteln

[paul53]

@Homoran sagte:

zu jedem State einen "inverted state" hinzuzubasteln

Alias.

[Homoran]

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

@Homoran sagte:

zu jedem State einen "inverted state" hinzuzubasteln

Alias.

zum Beispiel - ich meinte allerdings in den Adapter-objects

[paul53]

@Homoran sagte:

ich meinte allerdings in den Adapter-objects

Das wird sicherlich der ein oder andere Adapter-Entwickler berücksichtigen.

[StrathCole]

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

@StrathCole sagte:

Das würde aber nicht viel Einheit schaffen

Das ist nach Jahren der Nutzung in vielen Skripten und Visualisierungen auch nicht zumutbar.

Ich denke, sollte es hier eine strikte Vorgabe geben, werden die Adapter irgendwann in einer neuen Major-Version erscheinen müssen, die ja schon per Definition "Breaking Changes" enthalten. Wer dann aktualisieren will, muss Skripte und Vis anpassen. Zumindest gehe ich davon aus, dass es so laufen müsste.

[Samson71]

Sollte es hier durch eine (in meinen Augen) "sinnfreie" Umfrage zu einer Zwangsvorgabe kommen, wird das vermutlich viele arg treffen. Ich wäre auch nicht bereit meine Steuerung umzustellen, bzw. womöglich entgegen der Logik der eingesetzten Komponenten auszurichten. Die beiden zur Wahl stehenden Varianten dürften ziemlich ausgewogen vertreten sein.

In meinem Fall einer zu 100% aus HM bestehenden Installation würde ich Steuerung und Logik dann in der CCU belassen wenn 100% = zu und 0% = auf als Vorgabe kommt.

Hier wird immer mit Hell und Dunkel (Licht und Schatten) argumentiert. Ich habe mich an die HM-Logik mit der Orientierung an der Sicht gewöhnt.
0% = Null Sicht.
Das gilt sowohl für einen heruntergelassen Rollladen, als auch für eine ausgefahrene Markise.

[AlCalzone]

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

0% = Null Sicht.
Das gilt sowohl für einen heruntergelassen Rollladen, als auch für eine ausgefahrene Markise.

als auch Licht aus ;)

[haus-automatisierung]

Nehmt mal bitte einen Rollladen mit Gurtwickler und bittet Leute ohne Smart Home Bezug, den Rollladen auf 20% zu stellen. Niemand würde 20% Luft nach unten lassen?!

Rollladen = Beschattung. 100% = volle Beschattung.

Nehmt mal eine Markise. Da würde niemand sagen, dass eingefahren 100% ist, oder? Macht ja auch irgendwie keinen Sinn. Am Ende bekomme ich viele Mails von Leuten die verwirrt sind, dass bei Homekit und HomeMatic die 0% zu sind. Auch auf Facebook in den Kommentaren steht nur, dass das komisch ist und man sich dran gewöhnt hat.

[cash]

Dem schließe ich mich an. Der normale Anwender sagt mach die Rollade 60% runter und nicht las 40% Sonne rein.

Ikea hat die Logik auch. Homematic denkt halt komisch und da ist es anders. Nach meiner Meinung sollte es keine Vereinheitlichung geben sondern jeder Adapter sollte eine Option haben wo der Anwender das für sich passende selber Festlegen kann. Nur das macht Sinn.

Wenn die Mehrheit entscheidet muss die Minderheit selbst wenn es 49% sind an etwas gewöhnen was aus deren Sicht keinen Sinn ergibt. Mit einer Option kann es jeder für sich passend einstellen...

[Samson71]

@haus-automatisierung
Das hat bisher m.W.n. auch niemand bestritten. Trotzdem gibt es Hardware, bzw. Systeme die nunmal so ist/sind. Siehe das erwähnte Homematic. Ich halte daher die ganze Diskussion über eine "Vereinheitlichung" für überflüssig. Hier einen "Zwangsstandard" einzuführen ist auch m.M.n nicht zumutbar. Da bin ich ganz bei @paul53. Mag ja sein, dass man das anders sieht, wen man damit Geld verdient oder verdienen will.

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