Probleme mit DV WRC6 und FROLL

[Matsch]

Ich verstehe nicht ganz, wo der "enorme" Mehraufwand liegen soll? Ok, beim Erstersteller der Scripte schon, und beim Anwender einmalig eine Anpassung.
Der legt einfach ein Unterprogramm an mit einem für sich angepaßten Script und kann es für alle möglichen vorhandenen Markisen und Rollläden einfach aufrufen - statt der direkten Ausgabe an den Aktor, keine Zeile mehr Code oder Programm.

Für rein zeitgesteuerte Verstellung ist das sicher nicht notwendig, aber ich habe ja bereits erklärt, dass es mir um situationsgesteuerte Rollläden geht (Beschattung mit genau festgelegter Schattengrenze).
Zwar betonen hier einige, für sie ist nur smart, wenn alles von alleine gesteuert wird, ohne händischen Eingriff.
Und wenn ich dann eine Steuerung einsetze, die es mir ermöglicht, zu jeder Zeit am PC zu sitzen und immer ist das Zimmer so hell wie möglich, ohne dass mich je die Sonne auf dem Monitor stören kann (Sommer wie Winter, eben ohne eigenes Zutun), dann paßt das nicht mehr in das Schema?

Und selbstverständlich geht der linearisierten Rollladensteuerung noch ein weiteres UP zur Berechnung der genauen tatsächlichen Rollladenhöhe voraus. Auch das ist ein UP und wird im Bedarfsfall per einfachem Aufruf ausgeführt, egal, aus welchem Programm heraus und für welches Fenster.

Inzwischen gehört aber dieses ganze Thema in einen eigenen Thread ...

[Xel66]

Zwar betonen hier einige, für sie ist nur smart, wenn alles von alleine gesteuert wird, ohne händischen Eingriff.

Da das mein Mantra ist, fühle ich mich mal angesprochen. Ja, Du hast ja auch recht. Auch in Deinem Anspruch, das so zu steuern. Aber für Anwender, die "nur" eine Anzeige in der CCU haben wollen, die die reale Überdeckung am Fenster darstellt, ist der Aufwand schon etwas höher. Diese Behanghöhe lässt sich ja mit einer zusätzlichen an den Kanal gebundenen Systemvariable jederzeit erreichen (natürlich mit einem kleinen Unterprogramm, welches das aus der WebUI-Höhe errechnet). Aber mit diesen Werten kann man wieder nicht ohne zusätzlichen Rechenschritt den Aktor ansteuern. Und auch Apps berücksichtigen diesen Wert in der Aktordarstellung out of the box eher nicht. Nur das wollte ich zu bedenken geben. Ich will keinesfalls Deine Lösung schlechtreden, sondern nur die möglichen Missverständnisse aufzeigen.

... dann paßt das nicht mehr in das Schema?

Passt schon.

Und selbstverständlich geht der linearisierten Rollladensteuerung noch ein weiteres UP zur Berechnung der genauen tatsächlichen Rollladenhöhe voraus.

Genau das wollte ich zu bedenken geben, dass dieser Zwischenschritt auch notwendig ist. Das meinte ich mit der Hin- und Herrechnerei. Vielleicht habe ich mich auch etwas undeutlich oder missverständlich ausgedrückt. Für viele kann Deine Beschreibung eben so rüberkommen, als ob das keine Seiteneffekte hat und nur die Anzeige in der WebUI "korrigiert" wird und man dann direkt damit arbeiten kann.

Gruß Xel66

[Matsch]

Für viele kann Deine Beschreibung eben so rüberkommen, als ob das keine Seiteneffekte hat und nur die Anzeige in der WebUI "korrigiert" wird und man dann direkt damit arbeiten kann.

Nein, um irgendeine Anzeige (wo auch immer) geht es überhaupt nicht, sondern um eine komfortable und recht präzise Beschattungssteuerung in der Realität. Die Anzeige ist mir dabei egal - wenngleich ich auch ein UP drin habe, das für die korrekte Anzeige in einer App zuständig ist. Aber das ist eher optionales Beiwerk.

[Xel66]

Nein, um irgendeine Anzeige (wo auch immer) geht es überhaupt nicht, sondern um eine komfortable und recht präzise Beschattungssteuerung in der Realität.

Auch das ist durchaus wahr, hat aber mit der linearen Umrechnung auf die prozentuale (reale) Behanghöhe wenig zu tun, denn gleiches ließe sich eben auch mit der nichtlinearisierten Behanghöhe erreichen. Ist nur die Integration der Umrechnung in die Steuerung. Und das habe ich gemeint und versucht, auszudrücken.

... korrekte Anzeige in einer App zuständig ist. Aber das ist eher optionales Beiwerk.

Und auch das hatte ich geschrieben, wobei ich das eher auch für verzichtbar halte. Aber manch Anwender möchte das eben so angezeigt haben. Warum auch immer.

Wenn das Icon meines Dimmers 50% anzeigt, kann ich damit auch etwas anfangen und dabei sind mir irgendwelche realen (und/oder maximalen) Beleuchtungswerte (in Lux, Lumen oder was auch immer) auch eher egal. Ich weiß, es ist ausreichend hell. Das gleiche Problem wie die Abweichung der mit irgendeinem anderen Gerät ermittelten Raumtemperatur zu der am Heizkörperthermostat angezeigten und/oder geregelten Temperatur. Manche Leute kleben einfach zu sehr an irgendwelchen angezeigten digitalen Werten und halten das für die Wahrheit, nur weil eventuell angezeigte Kommastellen eine Genauigkeit suggerieren, die in Realität nicht vorhanden ist. Grund ist die Erwartungshaltung des Anwenders.

Gruß Xel66

[Patt]

Und auch das hatte ich geschrieben, wobei ich das eher auch für verzichtbar halte. Aber manch Anwender möchte das eben so angezeigt haben. Warum auch immer.

Wenn das Icon meines Dimmers 50% anzeigt, kann ich damit auch etwas anfangen und dabei sind mir irgendwelche realen (und/oder maximalen) Beleuchtungswerte (in Lux, Lumen oder was auch immer) auch eher egal. Ich weiß, es ist ausreichend hell. Das gleiche Problem wie die Abweichung der mit irgendeinem anderen Gerät ermittelten Raumtemperatur zu der am Heizkörperthermostat angezeigten und/oder geregelten Temperatur. Manche Leute kleben einfach zu sehr an irgendwelchen angezeigten digitalen Werten und halten das für die Wahrheit, nur weil eventuell angezeigte Kommastellen eine Genauigkeit suggerieren, die in Realität nicht vorhanden ist. Grund ist die Erwartungshaltung des Anwenders.

Gruß Xel66

Hier muss ich widersprechen Bei Licht ist das Helligkeitsempfinden sicherlich bei vielen unterschiedlich und daher sind dann in diesen Bereich auch keine 100% richtigen Werte notwendig.
Wenn ich aber auf eine Markise schaue und möchte, dass diese zur Hälfte geschlossen wird, dann gibt es da kein Interpretationsspielraum, die Hälfte wird bis auf wenige cm Abweichung immer die Gleiche sein
Daher finde ich auch eine korrekte Anzeige in der App oder wo auch immer wichtig und mich stört es, wenn ich 40% angezeigt bekomme, die Markise aber nahezu geschlossen ist.

Ihr scheint es ja beide drauf zu haben, besteht die Chance diese UPs zu Gesicht zu bekommen ?

Danke.

[Xel66]

...dann gibt es da kein Interpretationsspielraum, die Hälfte wird bis auf wenige cm Abweichung immer die Gleiche sein

Eben doch. Es ist nur die etwas unglücklich gewählte Bezeichnung des Herstellers. Als Konfigurationsparameter wird von der CCU weder der Rollendurchmesser, noch die Panzerdicke des Behanges, die Umdrehungszahl des Motors oder die Länge des Behanges abgefragt, sondern einfach eine Laufzeit. Daher kann die Anzeige der Behanghöhe sich eben nur auf den einzigen Konfigurationsparameter beziehen, der im Rollladenaktor angegeben wird. Eben die Laufzeiten von oben nach unten und andersrum. Davon prozentuale Angaben werden eben in der CCU verwendet und angezeigt.

Daher finde ich auch eine korrekte Anzeige in der App oder wo auch immer wichtig und mich stört es, wenn ich 40% angezeigt bekomme, die Markise aber nahezu geschlossen ist.

Das ist das eigentliche Problem. Deine Erwartungshaltung ist eben nicht ganz korrekt. Bei der Helligkeit stört es Dich nicht, bei der zeitbasierten Darstellung einer Behanghöhe, ja. Die Anzeige des Aktors in der WebUI wird auch nach den Winkelzügen nicht korrekt die reale Behanghöhe anzeigen (auch wenn sie dort so bezeichnet wird). Du kannst Dir irgendwelche Hilfskrücken mit Unterprogrammen bauen, die Dir irgendeine Systemvariable als Ergebnis bringen. Intern und in den Programmierungen wirst Du immer noch mit den von der CCU verwalteten Werten abeiten müssen. Oder eben für eine Rückrechnung in CCU-Behanghöhe sorgen. Es ist nur Augenwischerei. Das gleiche Thema wie bei den Thermostaten. Früher hat am Dehnkörperthermostat eine Skalierung von fünf Einheiten/Strichen von Stern bis Sonne gereicht, um die Wohnräume mit Wunschtemperatur zu versorgen. Heutzutage muss es mit Kommastelle sein, obwohl das System allein aus physikalischen und technischen Gründen das gar nicht leisten kann.

Wenn Du unbedingt eine Anzeige in der WebUI haben willst, dann erstelle pro Rollladen einfach eine Sytemvariable, binde sie an den Kanal und dann erstellst Du ein Programm mit einem Script, welches aus der von der CCU verwalteten Behanghöhe bei Aktualisierung die reale errechnet und in diese Systemvariable schreibt. Ob dann eine von Dir verwendete App dieses in irgeneiner Weise berücksichtigt (eher nicht), steht auf einem anderen Blatt. Das Script kann ja Matsch beisteuern, wenn er will. Ich habe gerade mal nach den Formeln zur Berechnung einer Spirale geschaut. War mir zu kompliziert, das fehlerfrei in die gewöhnungsbedürftige Scriptsprache (Berechnung von rechts nach links und automatische Wandlung von Variablentyen an Hand des Inhaltes der Variable etc.) umzusetzen. Bei Markisen brauch man ja im Gegensatz zu Rolllade nicht mal Leerlaufzeiten zum Schließen und Öffnen der Lamellen beachten. Daher kann man das direkt ohne zusätzliche Parameter berechnen.

Gruß Xel66

[Patt]

Noch einfacher wäre es, wenn man in der CCU einfach 10 Zeiten eintragen könnte, die dann die 10% Schritte darstellen.

Mit Programmen erstellen habe ich es leider nicht so.

[Xel66]

Das kann ich jetzt nicht nachvollziehen. Was willst Du mit 10 Zeiten? Es gibt bestimmte Behanghöhen, die Du haben möchtest. Dann fährst Du den Rollladen/Markise or whatever dorthin, wo Du es hinhaben möchtest. Dann liest Du im WebUI die angezeigte Behanghöhe ab und verwendest diese in Deinen Programmen. So einfach kann das Leben sein. Man kann auch mit langem Tastendruck manuell jegliche Zwischenstellungen anfahren. Vielleicht solltest Du erst mal klar definieren, was Du eigentlich wirklich willst. Dann findet man ggf. auch eine funktionierende Lösung.

Wenn man keine Programme erstellen will, dann frage ich mich, warum man eine Hausautomationslösung kauft, die für sowas gebaut ist? Nur um ganz stylisch den Rollladen vom Smartphone aus fernbedienen zu können? Dann hätte es auch eine kastrierte Fernbedienlösung getan, die es ohne Konfigurationsstress direkt vom Hersteller gibt und die aber dafür eben alles andere als smart ist. Und nein, nur weil etwas per Smartphone steuerbar ist, ist es noch lange kein Smarthomelösung.

Gruß Xel66

[Patt]

Mit den Werten wollte ich einfach Referenzpunkte hinterlegen, damit ich bei weiteren Programmen nicht Werte eingeben muss, welche nichts mit der Realität zu tun haben.

Ach ja halb geöffnet bedeutet in meiner tollen Hausautomation 34%..... Super logisch bei späteren Programmen.

Auch wenn du mich als den Trottel hinstellst, der nur stylisch mit seinem Rollladen prahlen will, habe ich eben den Anspruch, dass es logisch und nachvollziehbar ist.

[Xel66]

Du verkennst mich. Es liegt mir fern, jemanden als Wasauchimmer hinzustellen. Es ist aber nun mal so wie es ist. Die Behanghöhe orientiert sich an dem einzigen Parameter, den die CCU zur Verfügung hat. Und das ist nun mal die konfigurierte Dauer von oben nach unten und andersherum. Und die ist so einheitlich zu handhaben, egal ob es ein dicker oder dünner Rollladenpanzer oder lediglich ein Markisenstoff ist. Bei allen Behangarten ergeben sich unterschiedliche Behanghöhen bei gleicher Fensterhöhe und gleichem Antrieb. Und auch bei gleicher Fensterhöhe ergäbe die Konfiguration trotz gleichen Motors (gleiche Drehzahl) unterschiedliche zu konfigurierende Laufzeiten. Bei mir haben die Kunststoffrollladen auch leicht andere Laufzeiten als die mit dünnerem Alupanzer, obwohl die gleiche Rohrmotorty verbaut ist.

Wenn Du weißt, welche der angezeigten Bahanghöhe entspricht, ist es auch kein Problem, dieses in den Programmen zu verwenden. Ich mache das lange genug, als dass ich mir durchaus ein Urteil erlauben kann. Man erstellt ein Programm, und wenn es das erwartete tut, was man beabsichtigt hat, dann schaut man es es äußerst selten an und irgendwelche Pararameter interessieren niemanden mehr. Du fokussiert Dich hier auf ein Problem, welches aber in der Realität keines ist.

Was sollen Anwender tun, deren verwendete "Lichtsensoren" in Bewegungsmeldern lediglich 255 Stufen haben, die in keinem Bezug zu irgendwelchen Messwerten haben. Sollten die auch den Hersteller zwingen, gefälligst standardisierte Einheiten zu verwenden? Letztendlich legt jeder in seiner Programmierung eigene Schwellwerte fest, die er vorher auf geeignetem Wege ermittelt hat (Jetzt ist es dunkel genug, dass das Licht eingeschaltet werden soll).

Gruß Xel66