Slider aktualisieren

[Frank6320]

Hallo,

ich habe ein Problem mit den Slidern. Ich benutze KNX Aktoren zum Verfahren der Rollos. So sieht ein device aus:

g1 ist Rolloposiiton Sollwert in %
g2 ist Rolloposition Istwert in %
g3 ist Auf/Ab
g4 ist Stopp

Code Auswählen Erweitern

define Arbeitszimmer.Rollo_rechts KNX 3/4/8:dpt5.001:set:nosuffix\
3/5/8:dpt5.001:listenonly:nosuffix\
3/1/8:dpt1.008:set:nosuffix\
3/2/8:dpt1.001:set:nosuffix
attr Arbeitszimmer.Rollo_rechts HomeBridge on
attr Arbeitszimmer.Rollo_rechts alias Rollo rechts
attr Arbeitszimmer.Rollo_rechts cmdIcon Auf:fts_shutter_up Ab:fts_shutter_down Stopp:rc_STOP
attr Arbeitszimmer.Rollo_rechts eventMap /g3 off:Auf/g3 on:Ab/g4 off:Stopp
attr Arbeitszimmer.Rollo_rechts genericDeviceType blind
attr Arbeitszimmer.Rollo_rechts group Rolladen
attr Arbeitszimmer.Rollo_rechts homebridgeMapping clear CurrentPosition=g2,minValue=0,maxValue=100,minStep=1,invert=1 TargetPosition=value::g1,minValue=0,maxValue=100,minStep=1,invert=1
attr Arbeitszimmer.Rollo_rechts room Arbeitszimmer
attr Arbeitszimmer.Rollo_rechts siriName Arbeitszimmer Rollo rechts
attr Arbeitszimmer.Rollo_rechts stateFormat g2
attr Arbeitszimmer.Rollo_rechts webCmd g1:Auf:Stopp:Ab
attr Arbeitszimmer.Rollo_rechts widgetOverride g1:slider,0,5,100
#   DEF        3/4/8:dpt5.001:set:nosuffix
#3/5/8:dpt5.001:listenonly:nosuffix
#3/1/8:dpt1.008:set:nosuffix
#3/2/8:dpt1.001:set:nosuffix
#   FUUID      5e2de3be-f33f-ba42-9c3c-23aa7ed4f340feb3
#   IODev      knxbridge
#   LASTInputDev knxbridge
#   MSGCNT     36
#   NAME       Arbeitszimmer.Rollo_rechts
#   NR         99
#   STATE      56 %
#   TYPE       KNX
#   eventCount 59
#   knxbridge_MSGCNT 36
#   knxbridge_RAWMSG C01107w035088e
#   knxbridge_TIME 2024-10-26 19:58:35
#   model      dpt5
#   GADDETAILS:
#     g1:
#       CODE       03408
#       MODEL      dpt5.001
#       NO         1
#       OPTION     set
#       RDNAMEGET  g1
#       RDNAMESET  g1
#       SETLIST    :slider,0,1,100
#     g2:
#       CODE       03508
#       MODEL      dpt5.001
#       NO         2
#       OPTION     listenonly
#       RDNAMEGET  g2
#       RDNAMESET  g2
#       SETLIST    :slider,0,1,100
#     g3:
#       CODE       03108
#       MODEL      dpt1.008
#       NO         3
#       OPTION     set
#       RDNAMEGET  g3
#       RDNAMESET  g3
#       SETLIST    :up,down
#     g4:
#       CODE       03208
#       MODEL      dpt1.001
#       NO         4
#       OPTION     set
#       RDNAMEGET  g4
#       RDNAMESET  g4
#       SETLIST    :on,off,toggle
#   GADTABLE:
#     03108      g3
#     03208      g4
#     03408      g1
#     03508      g2
#   OLDREADINGS:
#   READINGS:
#     2024-10-26 19:56:52   IODev           knxbridge
#     2024-10-26 19:58:20   g1              65 %
#     2024-10-26 19:58:35   g2              56 %
#     2024-10-26 19:58:34   g3              up
#     2024-10-26 19:58:35   g4              off
#     2024-10-26 19:58:35   last-sender     1.1.7
#     2024-10-26 19:58:35   state           56 %
#   hmccu:
#
setstate Arbeitszimmer.Rollo_rechts 56 %
setstate Arbeitszimmer.Rollo_rechts 2024-10-26 19:56:52 IODev knxbridge
setstate Arbeitszimmer.Rollo_rechts 2024-10-26 19:58:20 g1 65 %
setstate Arbeitszimmer.Rollo_rechts 2024-10-26 19:58:35 g2 56 %
setstate Arbeitszimmer.Rollo_rechts 2024-10-26 19:58:34 g3 up
setstate Arbeitszimmer.Rollo_rechts 2024-10-26 19:58:35 g4 off
setstate Arbeitszimmer.Rollo_rechts 2024-10-26 19:58:35 last-sender 1.1.7
setstate Arbeitszimmer.Rollo_rechts 2024-10-26 19:58:35 state 56 %

Wenn ich hergehe und das reading g1 lösche, wird der slider immer auf den aktuellen Rollowert gezogen, wenn man manuell der Taster den Rollo verfährt. Sobald man aber den Slider benutzt, entsteht das Reading g1 und der slider bleibt auf dem Wert g1 kleben.
Wie bekomme ich FHEM dazu, den Schieber immer mit g2 zu aktualisieren?

Hab jetzt noch mal weiter geforscht: Wenn ich den :nosuffix "Anhang" in der Def weglasse, kommen nur setG1... Readings. Es wird kein g1 erzeugt beim Benutzen des Schiebers dann funktionierts. Irgendwie unlogisch.

[Beta-User]

Das ist sehr KNX-spezifisch, bitte verschiebe den Thread in den entsprechenden Forenbereich, damit @erwin sich das ansieht (falls es im Wiki (zu KNX) nicht bereits was dazu gibt).

Was den "allgemeinen Baukasten" angeht, könntest du es mit einem (sauber nur durch g2 getriggerten) userReadings-g1 versuchen, dass dann g1 mit dem Wert aus g2 überschreibt. Könnte aber unerwünschte Nebenwirkungen haben...

[erwin]

Hi Frank,

ja das Problem ist, dass der slider immer jenen Wert annimmt, der im entsprechenden reading steht...das ist FHEM global so definiert und auch gut so.
Bei KNX sind Soll und Ist-Wert 2 unterschiedliche readings (weil unterschiedliche Gruppenadressen).
Lösung: jedesmal wenn ein event von g2 (=Istwert) kommt, diesen nach g1 kopieren:

Code Auswählen Erweitern

attr  Arbeitszimmer.Rollo_rechts stateCmd  { if ($gadName eq 'g2') {
  fhem("sleep 0.05 quiet; setreading $name g1 $state";);
  }
  return $state;
}... das sleep ist notwendig, weil sonst readingsupdate rekursiv aufgerufen würde (was fhem verhindert!!)
l.g. erwin
PS: siehe auch WIKI - slider mit Rückmeldung

[Beta-User]

Lösung: jedesmal wenn ein event von g2 (=Istwert) kommt, diesen nach g1 kopieren:

Das geht (ohne neue event-loop) dann auch per userReadings...

Ungetestet:

Code Auswählen Erweitern

attr  Arbeitszimmer.Rollo_rechts userReadings g1:g2.* {return ReadingsVal($name,'g2',0)}

[erwin]

Das geht (ohne neue event-loop) dann auch per userReadings...

Das ist keine neue eventloop, das passiert erst wenn ein event für g2 vom KNX-Bus kommt und zwar während des reading updates für DIESEN event. setreading generiert keine events, meines Wissens.

[Beta-User]

Das ist keine neue eventloop, das passiert erst wenn ein event für g2 vom KNX-Bus kommt und zwar während des reading updates für DIESEN event. setreading generiert keine events, meines Wissens.

commandref sagt:

Der Befehl setzt das Reading <reading> auf den Wert <value> ohne Signale an das betroffene Gerät zu senden, generiert aber Ereignisse und die übliche eventMap und stateFormat Umwandlung wird auch durchgeführt.

Ergo hast du mit deinem Vorschlag 2 loops, eine für die Aktualisierung von g2, eine für setreading...

Mit userReadings hast du eine loop mit 2 Einträgen in der Liste.

[erwin]

@Beta-User,
ja du hast recht mit den events,
allerdings ist mir nicht klar, falls das userreading auf das widgetoverride xxx:slider gemappt ist, brauchts dann wieder eine eventmap um das richtige "set <device> g1 yy" ,bei Betätigung des sliders, auzulösen. Das ist nicht einfacher - geht aber!
Es gibt noch weitere Varanten das zu lösen, alle haben Vor- und Nach-teile.

[Frank6320]

Hallo zusammen,

hab grad nochmal geschaut, ob es clever wäre die Rückmeldung als erste Adresse zu nehmen und :suffix wieder reinzunehmen (Sollwert des Slider geht also auf g2). Bringt leider auch nix. Sobald man den browser aktualisiert, gibt es das reading g2 und der slider aktualisiert nicht mehr (ohne aktualisieren funktioiniert es). Ich denke, dass ich :suffix weglasse, so spare ich mir zusätzliche Attribute bei meinen Rollos.

Vielen Dank für den Hinweis zum Wiki. Hab die ganze Zeit zu Slider Rückmeldung bei Rollo gesucht und den Wald vor Bäumen nicht gesehen.

Viele Grüße

Frank

[Beta-User]

Das sieht mir einmal mehr danach aus, als wäre das ganze Gemappe Voodoo-Kosmetik...

Eigentlich sollte nach meiner Auffassung ein Dimmer als setter und Reading "pct" kennen (= Wertebereich 0-100, alternativ gingen auch "dim" (0-99) oder "brightness" (0-254/255)). Und genau so würde ich auch das mapping bzw. die userReadings gestalten. Beispiele für sowas wären z.B. auch in der zwave.template als attrTemplate enthalten. Da ist es ähnlich, dass manchmal setter und Rückgabe nicht "sauber" zusammenpassen bzw. man wieder Teile der Rückmeldung vom Aktor extrahieren muss, dass das konsistent ist.
Wenn das nicht so ist, gibt es z.B. auch Probleme mit Themen wie Sprachsteuerung (oder MQTT-Abgleich mit HomeAssistant, wer sowas braucht).

[erwin]

Eigentlich sollte nach meiner Auffassung ein Dimmer als setter und Reading "pct" kennen

Eigentlich hat sich mein Link auf "slider mit Rückmeldung" bezogen, und das hat jetzt so gar nichts mit dim zu tun, aber man könnte auch "pct" bzw. "pct-desired" / "pct-actual" vewrwenden....
Das "vodoo" beim Beispiel Dimmer (ja da sollte man pct verwenden) hat damit zu tun, dass hier zwei Schaltflächen definiert sind, die relative dim +10% / -10% realisieren, und dazu brauchts nunmehr den aktuellen Ist-wert.
Die reading-namen sind im KNX (fast) völlig frei wählbar, daher kann jeder seine Vorlieben ausleben.
Auf die sinnvolle Wahl von reading-namen ist hier WIKI - Definition-Felder im Detail hingewiesen.

[Beta-User]

Auf die sinnvolle Wahl von reading-namen ist hier WIKI - Definition-Felder im Detail hingewiesen.

Hmmm, weiß nicht, ob die Beispiele für alle User so einleuchtend sind, und ich wäre der Auffassung, dass "EinAus" eigentlich "state" (das Reading) sein sollte - aber da gibt es anscheinend eine Doppelung mit "Status"...

Wie dem auch sei, mir persönlich ist da zu viel mapping drin, ich würde immer versuchen, im hiesigen Beispiel dafür zu sorgen, dass der Helligkeitswert in "pct" landet (und dafür dann auch direkt ein slider existiert) und der Basis-Schaltzustand in "state". Notfalls sollte man dafür eben ein paar userReadings-Überlegungen anstellen.

Der TE verwendet jedenfalls "irgendwas mit g2", und das ist imo alles andere als "im FHEM-Standard".

Just my2ct.

[erwin]

Der TE verwendet jedenfalls "irgendwas mit g2", und das ist imo alles andere als "im FHEM-Standard".

Ich sehe zwar nicht den FHEM-standard, der "irgendwas mit g2" verbietet,
aber das ist historisch/backward-kompatible (EIB-Modul, 2011) bedingter default wenn nichts anders definiert ist, allerdings hat der TE die Möglichkeit, ein "sprechendes reading"  (z.b. "pct") zu verwenden, muß er aber nicht, das ist die Flexibilität, die ich hier erlaube. Der Hinweis auf sinnvolle readings ist jedenfalls vorhanden.
Ich vergleiche das mit dem MQTT2-Device, dort werden die readings durch die attr readingList definiert, bei KNX aus einer Ableitung der definition.
Zusammenfassung: Beide gezeigte Lösungen funktionieren, beide erzeugen gleich viele events, mein Vorschlag mit 2 eventloops, deiner mit einer.
Der Rest der Diskussion ist genaugenommen OT. - bezogen auf das TE Problem.

[Beta-User]

Der Rest der Diskussion ist genaugenommen OT. - bezogen auf das TE Problem.

Ad OT: Habe auf den freundlichen Hinweis mal nachgeschaut, auch bei MQTT gibt es in der "Schritt für Schritt" (leider) keine wirkliche Hilfestellung für die User, was sich eher "gut" in den FHEM-Kontext einfügt und was nicht.

Nach wie vor finde ich eine Liste (und gute, event-vermeidende Beispiele) wichtig. Das vorläufige Ergebnis findet sich in https://forum.fhem.de/index.php?msg=1323764.

Ob die sonstige Diskussion OT ist (oder einfach nur die Hilfsanfrage etwas unglücklich formuliert) mag der TE entscheiden. Ich hätte die Frage so verstanden: 'Ich habe einen KNX-Dimmer und finde keine Anleitung, wie man das Ding wirklich "best practice" in FHEM konfiguriert. Kann mir jemand weiterhelfen?'.

Noch OT: Ich habe den TE in den KNX-Bereich verwiesen, weil du erfahrungsgemäß einen super Support für "deine" Module bietest. Es war und ist nicht beabsichtigt, das in irgendeiner Weise mit meinen kritischen Anmerkungen in Frage zu stellen. Wir lernen alle immer noch was dazu und müssen mit manchen alten Zöpfen leben, die "halt so na wora" sind (oder mit der Kreativität, die andernorts ausgelebt wird)...

[erwin]

Hi Beta-User,
never mind, Kritik ist gut und wichtig, regt zum Ausbrechen aus eingefahrenen Schemata an, mit meiner OT Bemerkung wollte ich nur verhindern, den TE noch mehr zu verwirren.
Deinen Ansatz im verlinkten thread find ich super, meine Kommentare/Anregungen findest du dort.
l.g. Erwin 

[Frank6320]

Hallo zusammen,

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

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

[Frank6320]

Hallo zusammen,

neues von der Sliderfront. Mit dem Workaround den ich oben beschrieben hatte, kommt man ja klar. Hab aber noch ein "Problem". Wenn man bei stehendem Rollo einen Stop Befehl in dem device schickt, geht der Slider auf Null. Wohl weil der state des device auf off steht? Aktualisiert man die website spring er auf den richtigen aktuellen Wert.

viele Grüße

Frank

[erwin]

Hi Frank,
Stimmt, das ist im Framework so vorgesehen....
Grundsätzlich: der slider ist-wert wird entweder von einem reading bestimmt, dass exakt denselben namen hat wie der command, ODER vom Wert im state reading.
Das Problem ist lösbar, siehe Jalousie / Rolladen
l.g. erwin