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?