Slider aktualisieren

[Beta-User]

Hallo zusammen,

wäre es nicht am konsequentesten, bei der slider Definition auch direkt ein istWert Device benennen zu können?

Wieso sollte man wegen einiger weniger Module, bei denen der Hin- und Rückweg "readingmäßig" auseinanderfallen (neben KNX fällt mir da nur was mit SPS ein (S7?)), und bei denen es eine einfache bestehende und effiziente Lösung für das Problem gibt (userReadings) was neues im Framework anbieten, das 98% aller user bestenfalls verwirrt und im schlechtesten Fall seltsame Seiteneffekte hat?

[erwin]

Wieso sollte man wegen einiger weniger Module, bei denen der Hin- und Rückweg "readingmäßig" auseinanderfallen ....

Deine Terminologie ist falsch, wir reden im konkreten Beispiel von Soll-Wert vs. Ist-Wert. Jedes beliebige Steuerungs- System muss das unterscheiden.
Wenn es hier um eine Heizung ginge, würdest du nicht so argumentieren...
Wenn du noch mehr Beispiele brauchst: EBUS

Aber: ich bin ebenfalls dagegen, hier am slider was zu ändern!
Dem TE gehts hier vmtl. ausschlieslich um die GUI / Bedienung, da finde ich die "vermischung" ok, wenn das Beispiel komplexer wird (Einfluss von WindAlarm,Beschattung,...), ist das sehr schnell kontra intuitiv. Die Frage ist m.M.: was will ich im device-Overview sehen bzw. bedienen können - und das ist sehr individuell!

ad: cmd-/reading-namen:
KNX ist hier unterschiedlich zu anderen Systemen, die dpt's definieren zwar genau erlaubte Werte-(range) und Einheiten, aber NICHT den Verwendungszweck. Bsp: ein dpt5.xxx (Werte 0-255) kann für alles was sich ,mit 0-100% darstellen lässt, aber auch Temperatur, Kompassrichtung(0-359°), Zähler Impulse/Zeiteinheit, Drehzahlsteller,... verwendet werden. Daher ist eine fixe Zuordnung dptxx -> cmd bzw. ->reading-name im Modul nicht sinnvoll.

[Beta-User]

Deine Terminologie ist falsch, wir reden im konkreten Beispiel von Soll-Wert vs. Ist-Wert. Jedes beliebige Steuerungs- System muss das unterscheiden.

Sorry für den lapsus ...

Im Ernst: Sobald wir es mit wirklichen Richtgrößen zu tun haben, bei denen eine (entfernte) Steuerung immer wieder nachregeln soll, unterscheiden praktisch alle Module (bzw. Hardwaresysteme) einen Soll- und Ist-Wert, und dementsprechend bildet man das dann auch dort sinnvollerweise in zwei getrennten Readings ab.
ABER: Wenn wir bei einem ZigBee-Heizungsthermostat den Soll-Wert ändern, dann wird die Antwort auf die Änderung des Sollwerts in dasselbe Reading ("desired-temp") geschrieben, und das ist auch richtig so. Hat mit dem Messwert null und gar nichts zu tun.

Hier geht es aber doch konkret um eine dimmbare Leuchte. Da gibt es nach dem Absenden des gewünschten Zielwerts nichts mehr zu tun als auf die einmalige Bestätigung zu warten, dass der Ist-Wert auch entsprechend angepaßt wurde. Der veraltete Zielwert interessiert ab da niemanden mehr, er wird ja auch nicht mehr für weitere Eingriffe benötigt... Da braucht es dann eben (eigentlich) keine zwei Readings, und das mit den 2 Readings ist eben eine Besonderheit dieses Moduls hier (und des S7 (?)-Moduls)... Mag ja technisch alles korrekt sein, um eben alle Fälle abbilden zu können, aber für einen Dimmer ist es halt "speziell" (aus der Perspektive praktisch aller anderen Module bei der Behandlung von Dimmern).

[erwin]

Hier geht es aber doch konkret um eine dimmbare Leuchte. Da gibt es nach dem Absenden des gewünschten Zielwerts nichts mehr zu tun als auf die einmalige Bestätigung zu warten, dass der Ist-Wert auch entsprechend angepaßt wurde. Der veraltete Zielwert interessiert ab da niemanden mehr, er wird ja auch nicht mehr für weitere Eingriffe benötigt..

Das ist nur teilweise richtig:
Es geht konkret um eine Rollo, und es geht um den aktuellen Sollwert und die Rückmeldung vom Ist-Wert.
Dazu kommt, dass der Sollwert auch von extern - einem KNX-Drehregler verstellt werden könnte, das wird auch im FHEM-KNX-Modul ins Sollwert reading gesetzt, der Istwert wird (nach Verzögerung) hoffentlich sich dem Sollwert annähern... - daher 2 readings.
Ad: "veralteter Zielwert intessiert niemand mehr": Oft richtig, ausser, wie schon beschrieben, es kommen externe Faktoren hinzu, z.b: WindAlarm od. Beschattung - die Rollo fährt selbsständig in eine vordefinierte Position - und nach Ende Windalarm wieder in die vorherige Pos zurück. Was ist jetzt der "richtige" Sollwert ? - ich denke das sollte man dem User überlassen. Im KNX-Modul ist die Möglichkeit dazu gegeben. 
Bei dimmbaren Leuchten sehe ich das ähnlich wie du, weil hier das Feedback das menschliche Empfinden ist (Ist es hell/dunkel genug?).

[Beta-User]

Ok, bei einem Rollo hat man in der Tat einen zeitlichen Versatz, für sowas würde ich aber trotzdem nicht (aus diesem Grund) unbedingt dauerhaft 2 Readings sehen - CUL_HM löst das nach meiner Erinnerung dadurch, dass der Zielwert solange in "state" bleibt, wie das Rollo fährt und erst bei einem "stop" angefasst wird.

Ad: "veralteter Zielwert intessiert niemand mehr": Oft richtig, ausser, wie schon beschrieben, es kommen externe Faktoren hinzu, z.b: WindAlarm od. Beschattung - die Rollo fährt selbsständig in eine vordefinierte Position - und nach Ende Windalarm wieder in die vorherige Pos zurück. Was ist jetzt der "richtige" Sollwert ? - ich denke das sollte man dem User überlassen.

Na ja, kann man so sehen. Für den FHEM-Kontext gehe ich davon aus, dass "man" sich "alte" Soll-Werte ggf. anderswo wegschreiben kann, weil die eigentliche Steuerung für "Sondersituationen" dann halt FHEM machen wird (oder zumindest berücksichtigt, wenn das HW-System das autonom kann). Dafür braucht man imo eigentlich keinen (dauerhaften) Sollwert (ausgenommen echte "Regelsysteme" wie Heizungsthermostate u.ä.).

Jedenfalls ist das Merken von Sollwerten in diesem Sinne eben die Ausnahme, und man kann m.E. nicht beides haben - ein Slider in FHEM gibt eben zwar den Soll-Wert vor, anzuzeigen ist aber imo der (erreichte) Ist-Wert.
So jedenfalls meine aktuelle Auffassung dazu.