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

[StrathCole]

@AlCalzone Ich meinte, dass es in der Alexa App den Typ Rollladen gibt, der wohl in der v3 Api mit RangeController implementiert wird und dann auch öffnen und schließen unterstützt. https://developer.amazon.com/de-DE/docs/alexa/alexa-voice-service/alexa-rangecontroller.html

[Homoran]

Ich sehe die Logik genau anders herum als einige User.

Man muss immer das Licht betrachten 100% ist ganz hell, egal ob es elektrisch oder solarbetriebenes Licht ist.

Also bitte so lassen!

[StrathCole]

@Homoran Aber du stellst doch eine Klimaanlage auch nicht auf 100%, wenn du es wärmer haben willst ;-)

[paul53]

@Homoran sagte:

Man muss immer das Licht betrachten

Hast Du eine elektr. Markise ?

[Homoran]

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

@Homoran sagte:

Man muss immer das Licht betrachten

Hast Du eine elektr. Markise ?

Ja!
auch da wird es dunkler wenn sie rausfährt.
Außerdem ist sie (wenn man die Schräge etwas übertrieben darstellt) wie ein Rolladen unten (=0=dunkel) und oben (=100=hell)

EDIT:

Habe sie gerade zum Test eingefahren

[Garfonso]

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

@StrathCole Wirklich? Das ist dann neu. Mein letzter Stand war, dass Rolläden in den USA nicht verbreitet sind, weshalb es (damals) keine spezielle Rolle dafür gab.
Hast du ggf. nen Link dazu?

Für Rolladen hat der Alexa Newsletter bei mir auch schonmal Werbung gemacht, explizit mit Nennung von Homatic (IP?).

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

Also bitte so lassen!

Es gibt keine feste Definition aktuell, daher kann man es auch nicht "so lassen" :-)
Meine ganzen KNX Rolladenaktoren sind munter in ioBroker und da ist 100% = zu. Die HQ Widgets sehen es z.B. auch so.
Es sollen ja auch nicht alle Adapter über den Haufe geworfen werden, besonders nicht von jetzt auf gleich.

Aber der Versuch in ioBroker etwas "Ordnung" zu bekommen existiert ja und ist sehr vielverpsrechend mit type-detector und devices Adapter. Aber da ist level.blind halt eine "Lück", die mir aufgefallen ist und weshalb ich die (doch sehr emotionale ;-) ) Diskussion angestoßen habe: Selbst, wenn ein Gerät "Rollade" erkannt wurde, weiß man noch nicht (auf Seiten des Anwenders, Vis, irgendeiner anderen "Intelligenz") wierum denn nun Rolladen zu fahren sind.
Ehrlich gesagt finde ich überall den "invertieren" Haken eher suboptimal, da damit die Arbeit auf den Nutzer abgeladen wird (und der Haken muss ja im Grunde auch pro Gerät immer da sein, da man ja verschiedene Systeme haben könnte).

Ich finde, wenn sich, wie es aktuell aussieht (sehe gerade 50/50%), keine wirklich mehrheitliche Antwort herauskristalisiert, sollte man über andere Lösungen nachdenken. Eine Möglichkeit könnte sein, die Rolle level.blind abzuschaffen und dafür andere Rollen zu definieren, z.B. level.blind.open / level.blind.closed (also % geöffnet / geschlossen), die dann halt Eindeutig sind. Dann kann wiederum der "Verwender" (User, Vis, Inetlligenz) an der Rolle erkennen, was er da nun reinschreiben muss.

Dann käme man ggf. auch dem "Broker" Gedanken (was ich aber nicht für sooo wichtig halte) wieder etwas näher, die Daten dürfen so in die DB gehen, wie sie kommen, müssen aber vom Adapter korrekt bezeichnet werden.

[StrathCole]

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

z.B. level.blind.open / level.blind.closed (also % geöffnet / geschlossen),

Vielleicht könnte man das sogar allgemeiner halten, also level.open (oder level.opened) und level.closed und dann wie bisher mit Unterdefinitionen wie level.open.blind etc.
Gibt ja vielleicht noch andere Dinge, auf die das passen würde (Garagentor z. B.).

Ein Garagentor wäre z. B. ein gutes Beispiel. Ein Rolltor ist ja fast wie ein Rollladen ;-) und bei 0% ganz sicher nicht geschlossen, weil man es dunkel haben will *g (ja, ich weiß, da würde man nicht level.blind nehmen).

[Homoran]

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

Die HQ Widgets sehen es z.B. auch so.

Bei mir nicht ;-) Da geht es mit Homematic vollkommen richtig: 100% ist auf.

Na gut, da kann man invertieren

[paul53]

@Homoran sagte:

Habe sie gerade zum Test eingefahren

Bei Dir ist voll eingefahren = 100%. Dann hast Du Deine Philosophie "Man muss immer das Licht betrachten" konsequent umgesetzt.
Meine Philosophie wäre: Wann erfüllt eine Sache seine Funktion zu 100 % ?

[Homoran]

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

Mein Philosophie wäre: Wann erfüllt eine Sache seine Funktion zu 100 %

Dann muss der Rollladen bei 100% natürlich auch zu sein.
Aber wenn ich das jetzt ändere springt mir jemand der mit in meinem Haus wohnt mit dem ... ins Gesicht!

Wäre es denn möglich, dem Beispiel HQ-Widgets zu folgen und das "irgendwo" konfigurierbar zu machen?

[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 ;)