[Umfrage] Rolladenposition in % was ist logischer?

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

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