[Umfrage] Rolladenposition in % was ist logischer?

[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

[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