[Umfrage] Rolladenposition in % was ist logischer?
-
@Jey-Cee sagte:
Neue Adapter kommen nicht ins Stable repo wenn sie das nicht machen.
Das kann aber nur neue Adapter betreffen, weil sonst viele bestehenden Skripte und Visualisierungen nicht mehr funktionieren.
Diese Definition sollte dann auch bei Alias-Datenpunkten berücksichtigt werden, denn hier kann man leicht die Richtung invertieren. -
@StrathCole stellt sich immer die Frage, was man eigentlich ausdrücken will:
-
Rolladenöffnung / Behanghöhe: klare Bedeutung, je größer dieser Wert desto offener / weiter oben ist der Rolladen oder die Jalousie
-
Rolladenposition: keine klare Bedeutung, denn hier muss man definieren wo der Nullpunkt liegt, oben oder unten
-
Rolladenverschluss / Verschattungsgrad: klare Bedeutung, denn diese Begriffe sind das genaue Gegenteil von Rolladenöffnung / Behanghöhe, also je größer dieser Wert ist, desto geschlossener / weiter unten ist der Rolladen / die Jalousie
Ich wäre dafür, statt des unklaren / umstrittenen Begriffs "Rolladenposition" im Zuge einer Vereinheitlichung lieber einen klaren Begriff wie "Rolladenöffnung" zu nehmen. Versteht jeder und führt nicht zur Verwirrung.
Allerdings bin ich dafür, bei den Adaptern sowohl den nativen, als auch den Iobroker spezifischen Wert als eigenen Datenpunkt zu haben, denn wenn man jetzt die Vorgaben an eine Vielzahl von Adaptern ändert, müssen auch viele Skripte / Blocklys wieder angepasst werden.
-
-
@dj-tifosi Das ist klar, darum sagte ich ja, das mit der Umfrage ist unglücklich formuliert. Es geht ja um die Position
level.blindodervalue.blind, also nicht um Öffnung oder Verschluss. In der API von Somfy (Tahomalink) heißt der Datenpunkt zum BeispielClosureStatebzw.DeploymentState. Den könnte man also nicht auf 0% = geschlossen abbilden, sondern müsste einen eigenen Datenpunkt im Adapter nutzen. Fände ich persönlich etwas unglücklich. Aber genauso wird es Situationen geben, wo es umgekehrt unglücklich ist. -
@StrathCole und meine Idee wäre, dass dieser Datenpunkt im Somfy-Adapter eben genauso bleibt wie er ist, denn dann bricht man auch nicht die Logik bestehender Scripte / Blocklys.
Zusätzlich kann es aber in jedem Adapter Herstellerübergreifend einen Datenpunkt mit einheitlichem Namen und einheitlicher Bedeutung geben, über den man optional den Rolladen steuern kann oder den andere Adapter wie Shuttercontrol, die eine einheitliche Bedeutung von offen und geschlossen erfordern, zur Steuerung nutzen können.
Wäre aus meiner Sicht die eleganteste Lösung eine klare Trennung von Hersteller spezifischen Datenpunkten und vereinheitlichten / Iobroker spezifischen Datenpunkten.
-
-
Falls es hier darum geht, für alle Adapter eine einheitliche Lösung zu finden wie das abgebildet werden soll, wäre ich persönlich dagegen. Der ioBroker ist (wie der Name sagt) nur ein Broker / Vermittler zu dem jeweiligen System. Dort sollten die Werte 1:1 durchgereicht werden - ohne umgerechnet oder manipuliert zu werden.
Wie verwirrend wäre es für jemanden aus der HomeMatic-Welt, wenn 0% auf einmal ganz oben ist, wo derjenige das in den CCU-Programmen immer anders gemacht hat?
Das gleiche würde für jemanden aus der KNX- oder Loxone-Welt gelten. Nur eben andersrum.
Adapter zur übergreifenden Steuerung sollten einfach eine Einstellungsmöglichkeit bekommen, ob 100% = ganz auf, oder ganz zu. So wie Tasmota das auch löst. Denn da weiß man ja noch nicht, welches System man steuern wird.
-
@haus-automatisierung sagte in [Umfrage] Rolladenposition in % was ist logischer?:
Adapter zur übergreifenden Steuerung sollten einfach eine Einstellungsmöglichkeit bekommen, ob 100% = ganz auf, oder ganz zu. So wie Tasmota das auch löst. Denn da weiß man ja noch nicht, welches System man steuern wird.
Sehe ich auch so Matthias ...
shuttercontrol wird das zukünftig auch unterstützen, dass man für Systeme die entgengesetzt arbeiten, automatisch den Wert konvertiert.
Wobei shuttercontrol auch standardmäßig so arbeitet, das 0% = geschlossen und 100% = geöffnet ist.Das werde ich auch nicht ändern, da dies im Code sehr verwurzelt ist.
Aber ich werde die Möglichkeit mit einbauen, dass man seine Rollladen-Level entgegengesetzt ansteuern kann, sprich dass der tatsächliche Sollwert für die Rollläden konvertiert ausgegeben werden kann. -
@haus-automatisierung das Thema ist etwas Komplexer als du es jetzt siehst. Es geht hier um die Rollen Definition und wie damit Systemweit umgegangen wird. Da ist Logik nur ein Teil, es gibt aber auch noch die Visualisierung und die Tatsache das man Möglicherweise verschiedene Systeme verwendet die Rolladenaktoren zur Verfügung stellen.
Aus meiner sicht ist es unlogisch das bei einem 100% auf ist und beim anderen Geschlossen, als Anwender ist mir das auch egal. Ich will Rolladen in % Steuern und da muss 100% immer das gleiche sein.Das ist auch etwas was ioBroker von anderen Lösungen abheben kann, wenn so etwas klar definiert ist. Bei anderen ist das nämlich auch nicht klar definiert.
Stellt euch mal die Frage wie Smart ist der Aktuelle Stand?
Wir Entwickeln und verwenden hier Software um unser Zuhause Smart zu machen, aber ioBroker selbst ist in meinen Augen noch immer weit davon entfernt Smart zu sein.
Das bedeutet nicht das wir uns der Flexibilität berauben sollten die ioBroker bietet, jedoch sollte man das bereits vorhandene benutzen und versuchen 100% des Potentials davon aus zu nutzen.
Aktuell sind die Rollen Definitionen noch immer eine Baustelle, aber gleichzeitig ein Wichtiges Werkzeug vor allem für die Visualisierung.@haus-automatisierung sagte in [Umfrage] Rolladenposition in % was ist logischer?:
Dort sollten die Werte 1:1 durchgereicht werden - ohne umgerechnet oder manipuliert zu werden.
Auf gar keinen Fall sollten Werte 1:1 durchgereicht werden. Das ganze sollte schon logisch Dargestellt werden und auch Eingaben so angenommen werden wie man das so erwartet.
deConz erwartet für dein Eingabe von Temperatur für ein Thermostat eine 4-Stellige Zahl, als 2200, aber damit rechnet kein Benutzer, logisch ist doch 22°C oder 22,00°C.Es gibt immer den Joker state/value wenn man nicht weis wie man mit den gelieferten Werten umgehen soll oder das dem Benutzer überlassen möchte.
Das wird dann aber von allen Automatischen Erkennungen ignoriert, so lange sie nach bestimmten Rollen suchen.
Ist für mich jedoch nur eine Notlösung. -
@darkiop sagte in [Umfrage] Rolladenposition in % was ist logischer?:
Für mich ist gedanklich die %-Zahl immer die gewünschte Wirkung des auslösenden Objektes:
- Licht: 100% = Hell
- Rollläden/Markisen: 100% = Dunkel <-- da aber HomeMatic das genau anders herum macht, komme ich immer wieder mal durcheinander
Also wenn es um eine Definition des Standards geht, würde ich das so machen (100% = Hell / 100% = Dunkel) und eine Invertier-Funktion anbieten.
Ich finde die Definition von @darkiop sehr treffend.
Zum Standard an sich: Ich würde auch für eine systemweite Lösung plädieren. Wenn ein neuer Standard geschaffen wird, ist immer Bedarf zu Migrationen vorhanden. Solange der neue Standard sinnvoll ist, sollte das kein Grund dagegen sein. Auf lange Sicht pofitieren alle von einer einheitlichen Herangehensweise, auch die, die jetzt viele Skripte anpassen müssen.
Und egal wie die Lösung ausfällt, wer unbedingt seine invertieren Werte haben will, kann das ja per Alias oder Skript in einem neuen Datenpunkt regeln. Für meine Markise werde ich das definitiv tun müssen, wenn 100% irgendwann als "Markise eingefahren" interpretiert wird.
Bin schon gespannt was am Ende raus kommt.
Vielen Dank auf jeden Fall für die Bemühungen ioBroker noch besser zu machen! 
-
@Jey-Cee
Ich erinnere mich an der ersten Begegnung mit der HomeMatic Definition und wie ich irritiert war, dass "100% = offen" sein soll.Meine (innere?/eigene?) Logik sagte sich:
Es ist doch die Rede von Rolalden(aktoren).
Und wenn ich den Rolladen 0% sehen kann, wie kann das Ergebnis dann 100% sein?
Kann ich im Gegenzug den Rolladen zu 100% sehen, wieso soll das dann angeblich 0% abbilden? -
@haus-automatisierung sagte in [Umfrage] Rolladenposition in % was ist logischer?:
Spannendes Thema, zumal es dazu ja immer wieder verschiedene Interpretationen gibt.
Ich würde mal ergänzen:
100% = unten (geschlossen), 0% = oben (offen):- IKEA (wobei der Tradfri-Adapter das umkehrt)
0% = unten (geschlossen), 100% = oben (offen):
- Z-Wave (Multilevel Switch), wobei das von der Definition des Geräte-Herstellers abhängt
- Alexa bei Darstellung als LIGHT (kennt keine Rolläden)
- FHEM (Tradfri-Integration), baut auf meiner Tradfri-Lib auf und definiert es daher gleich. Wunsch für das Umkehren kam ursprünglich hier her
@darkiop sagte in [Umfrage] Rolladenposition in % was ist logischer?:
Für mich ist gedanklich die %-Zahl immer die gewünschte Wirkung des auslösenden Objektes:
Licht: 100% = Hell
Rollläden/Markisen: 100% = DunkelKlingt logisch, für mich ist es aber anders herum intuitiv. Ich fahre morgens meine Rollos hoch, um 100% hell zu machen
-
@siggi85 sagte in [Umfrage] Rolladenposition in % was ist logischer?:
@darkiop sagte in [Umfrage] Rolladenposition in % was ist logischer?:
Für mich ist gedanklich die %-Zahl immer die gewünschte Wirkung des auslösenden Objektes:
- Licht: 100% = Hell
- Rollläden/Markisen: 100% = Dunkel <-- da aber HomeMatic das genau anders herum macht, komme ich immer wieder mal durcheinander
Also wenn es um eine Definition des Standards geht, würde ich das so machen (100% = Hell / 100% = Dunkel) und eine Invertier-Funktion anbieten.
Ich finde die Definition von @darkiop sehr treffend.
Zum Standard an sich: Ich würde auch für eine systemweite Lösung plädieren. Wenn ein neuer Standard geschaffen wird, ist immer Bedarf zu Migrationen vorhanden. Solange der neue Standard sinnvoll ist, sollte das kein Grund dagegen sein. Auf lange Sicht pofitieren alle von einer einheitlichen Herangehensweise, auch die, die jetzt viele Skripte anpassen müssen.
Und egal wie die Lösung ausfällt, wer unbedingt seine invertieren Werte haben will, kann das ja per Alias oder Skript in einem neuen Datenpunkt regeln. Für meine Markise werde ich das definitiv tun müssen, wenn 100% irgendwann als "Markise eingefahren" interpretiert wird.
Bin schon gespannt was am Ende raus kommt. Vielen Dank auf jeden Fall für die Bemühungen ioBroker noch besser zu machen! Man könnte das aber auch anders herum sehen ...
Licht 100% = hell
Licht 0% = dunkel
Rolladen 100% = hell
Rollladen 0% = dunkelAm Ende denke ich, ist es eine reine Betrachtungssache und eine Art Gewohnheit ... Ich glaube aktuell agieren die meisten Rollladenlevel Unterstützungen in VIS, iqontrol und Co genau nach diesem Prinzip.
100% = geöffnet
0% = geschlossen -
@simatec sagte in [Umfrage] Rolladenposition in % was ist logischer?:
Man könnte das aber auch anders herum sehen ...
Licht 100% = hell
Licht 0% = dunkel
Rolladen 100% = hell
Rollladen 0% = dunkelTut mir leid, aber die Sichtweise finde ich sehr "an den Haaren herbeigezogen". Dann müsste man ja auch sagen:
Thermostat Heizung: höherer Wert = wärmer, Kühlung: höherer Wert auch = wärmer (in Prozent ausgedrückt natürlich, und klar ist das Äpfel und Birnen, aber vom Prinzip her ist es ja so).Rollläden und Licht sind nun mal zwei komplett gegensätzliche Dinge. Einmal für die Helligkeit, einmal für die Dunkelheit.
-
@AlCalzone sagte in [Umfrage] Rolladenposition in % was ist logischer?:
Alexa bei Darstellung als LIGHT (kennt keine Rolläden)
Stimmt so nicht. Wenn man sie direkt via Somfy Tahoma einbindet, kennt Alexa auch Rollläden mit öffnen und schließen. ioBroker iot nutzt hier nur eine etwas ältere Anbindung, soweit ich weiß.
Aber: Alexa definiert den Zustand explizit als
Öffnungsgrad, nicht als Position. -
Ich sehe aber von der Kommunikation generell ein Problem, wie das wirklich verständlich kommuniziert werden sollte. Selbst wenn man sagt
level.blinddefiniert den "Öffnungsgrad" und 100% sind offen – bei einer Markise würde man hier schon wieder ins Schleudern kommen, was genau "offen" nun heißen soll. -
@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? -
@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
-
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!
-
@Homoran Aber du stellst doch eine Klimaanlage auch nicht auf 100%, wenn du es wärmer haben willst
-
