Aktualisierung von GUI-Elementen

Begonnen von olwaldi, 01 Februar 2026, 14:47:17

Vorheriges Thema - Nächstes Thema

olwaldi

Wieder in DENON_AVR aufgefallen ...

Wenn man in der WebGUI über den set-Button z.B. die Aktion volumeUp (kein zugehöriges Reading) ändert, um die Lautstärke (volumeStraight) um einen wählbaren Betrag zu erhöhen, wird der damit verbundene slider volumeStraight in webCmd nicht aktualisiert. Konkret wird zwar die Lautstärke um den gewählten Betrag vergrößert (auch das Reading volumeStraight wird aktualisiert), aber der Slider volumeStraight verharrt auf dem vorigen Wert. Wenn man nur im Web-Browser die WebGUI neu lädt, stimmt volumeStraight wieder. Noch merkwürdiger: In dem Moment, wenn man den set-Button drückt, wechselt das Auswahlmenü überraschenderweise auf volumeStraight mit richtigem Wert. Anbei ein Screenshot mit dem "Widerspruch" der gleichen zwei Slider.

Im Supportforum für DENON_AVR habe ich quasi dieselbe Frage auch gestellt, ist aber m.E. eher eine "Entwicklerfrage". Ich selber versuche gerade, in dem Modul den ein oder anderen Bug zu fixen.

Grüßle, Michael


rudolfkoenig

Ich habe kein Denon, und ein Versuch im FHEM eine Instanz zu definieren hat nicht wirklich geholfen.

Mit folgender dummy Definition sehe ich kein Problem:
define da dummy
attr da setList    volumeStraight:slider,0,1,100
attr da readingList volumeStraight
attr da webCmd      volumeStraight

Generell: der Wert ders Widgets wird aus einem Reading mit dem gleichen Namen ausgelesen.

olwaldi

Zitat von: rudolfkoenig am 01 Februar 2026, 18:15:55Generell: der Wert ders Widgets wird aus einem Reading mit dem gleichen Namen ausgelesen.

Genau so hatte ich's auch verstanden. Aber im Modul DENON_AVR ist's nunmal vom ursprünglichen Autor anders implementiert worden (hab's ohne wirklichen Erfolg mal testweise geändert).

Meine Erwartung wäre, daß OHNE existierendes Reading ein Eingabefeld in der set-Zeile aufgebaut wird (funktioniert). Aber warum "springt" die set-Zeile auf einen ANDEREN Eintrag, wenn man den set-Knopf drückt? Erwartet hätte ich keine Änderung (aber klar, fhem kann ja kein Reading auslesen). Und warum immer auf denselben Eintrag volumeStraight? Ist alphabetisch weder das erste noch das letzte.

Ich habe eine Vermutung - könnte es mit dem return-String der DENON_AVR_Set-Routine zu tun haben (obwohl der meistens undef ist)?

Die Änderung in der set-Zeile ist ja auch nur ein Symptom. Das eigentliche Problem ist, das die zwei GLEICHEN Slider (mit dem Reading volumeStraight verbunden) UNTERSCHIEDLICHE Werte anzeigen. Genauer, der in webCmd ist genau ein Event "hinterher". Und als "Fix" reicht ein reload der fhem-Seite im Browser.


Grüßle, Michael

rudolfkoenig

Ich helfe gerne, aber ich brauche was zum Nachstellen.
Zum Beispiel eine Variante des Moduls, was ohne Hardware auskommt.
Oder eine passende Konfiguration mit dummy.

olwaldi

#4
Das ist mir schon klar. Daher habe ich mal versucht, das DENON_AVR-Modul so abzuändern, daß man es direkt nutzen kann. Dazu habe ich das Modul in das neue Modul DENON_DUMMY umkopiert und dort alle DevIo-Aufrufe in DevIoDummy-Aufrufe ohne Effekt umgebogen. Erstaunlicherweise funktioniert das DENON_DUMMY-Modul:-)
define denondummy DENON_DUMMY 1.2.3.4
Meine GUI-Probleme kann man damit nachvollziehen. Insbesondere kann man die beiden gleichen slider volume/volumestraight unabhängig voneinander (in webCmd bzw. bei set) bewegen. Das sollte m.E. eigentlich nicht so sein, da dasselbe Reading volume bzw. volumeStraight verwendet wird. Auch das Springen in der Auswahlliste auf den Eintrag volumeStraight z.B. von volumeUp tritt damit auf.

Das gefakete Modul habe ich hier angehängt.

Danke schonmal vorab für's Angucken, Michael

Nachtrag: Vermutlich funktioniert mein DENON_DUMMY doch etwas anders, da das DENON_AVR_Set die Lautstärke im Receiver ändert, nicht aber das Reading. Das funktioniert erst als Reaktion auf die Bestätigung durch den Receiver in DENON_AVR_Read - zeitlich etwas versetzt. Das erklärt, warum die zwei slider verschiedene Werte anzeigen können.
Ich habe DENON_AVR so angepaßt, daß die zwei zugehörigen Readings direkt in DENON_AVR_Set mit geändert werden, statt auf die Antwort des Receivers im DENON_AVR_Read zu warten. Trotzdem sollte doch eigentlich der (fehlerhafte) Wert automatich beim Read aktualisiert werden. D.h. ich habe eigentlich "nur" einen Workaround gefunden.

Habe gerade das Attribute longpoll an FHEMWEB entdeckt - habe mal 1 oder websocket ohne Verbesserung ausprobiert. Ist "mein" Problem ggf. hiermi verwandt https://forum.fhem.de/index.php?topic=141435.0 ?

Zusatzfrage zum Slider: Im Code ist manchmal im Reading eine Einheit dB oder % (zusätzlich zur Zahl) enthalten. Ist das OK?

rudolfkoenig

DENON_DUMMY will mir nicht helfen: nach der obigen Definition bewirkt weder der webcmd slider etwas, noch das mit dem set.
Will sagen: es gibt kein Event, und damit natuerlich auch keine Reaktion auf dem Bildschirm.

longpoll ist aus der Zeit, wo websocket noch nicht von jedem Browser unterstuetzt wurde.
Websocket benoetigt aber extra Konfiguration, wenn man ein Proxy verwendet (longpoll nicht).
Weiterhin schickt apple bei websocket das Passwort (Authentication: Basic) nicht mit, bei longpoll schon.
Strenggenommen ist longpoll aber ein Hack.

Wg. der Zusatzfrage: das ist eine Glaubensfrage, es gab schon deswegen lange Diskussionen.
Ich bin immer noch der Ansicht, dass es ok ist, wenn die Einheit durch ein Leerzeichen vom Wert getrennt ist.

olwaldi

Danke für die Rückmeldungen. Daß mein DENON_DUMMY nicht hilft, ist mir gestern auch noch klar geworden.

Ich lebe dann erstmal mit dem GUI-Problem - mein usecase funktioniert ja perfekt. Und ich habe viel gelernt bzgl. perl & fhem - das hat sich für mich sehr gelohnt.

Grüßle, Michael

olwaldi

#7
Doch noch eine Nachfrage: Merkwürdigerweise wird auch das Internal STATE von DENON_AVR nicht aktualisiert und bleibt stoisch auf off. Im Event-Monitor sehe ich aber
2026-02-08 07:11:18 DENON_AVR Denon power: on
2026-02-08 07:11:18 DENON_AVR Denon on
2026-02-08 07:11:18 DENON_AVR Denon stateAV: mainOff
2026-02-08 07:11:18 DENON_AVR Denon zoneMain: on
2026-02-08 07:11:18 DENON_AVR Denon stateAV: on
stateFormat steht auf stateAV.
Value("Denon") (aka STATE) oder ReadingsVal("Denon", "state", "?") liefern erwartungsgemäß beide on.
Ein F5 bzw. Browser-Refresh liefert sofort das erwartete on auch in der Browser-Ansicht von FHEMWEB.

FHEMWEB longpoll steht auf websocket (default scheint aber 0 zu sein laut erstem GUI-Vorschlag). Sicherheitshalber habe ich auch fhem neu gestartet.

Das Internal STATE selber wird nicht aktiv von DENON_AVR geändert, es wird allerdings DevIo_Open aufgerufen, sollte das Denon-Device nicht geöffnet sein (ist aber normalerweise 24/7 geöffnet).

Noch ein Hinweis: Ich nutze zwei FHEMWEB Devices.

Nicht nur STATE wird nicht aktualisiert, auch "gefühlt" rund 10% der Readings werden nicht aktualisiert. Manche schon - erkennbar am roten Zeitstempel. Nach einem F5 werden alle Readings richtig angezeigt UND die roten Zeitstempel sind alle schwarz, obwohl sich ja "nix" geändert hat. Könnte das ein "Mengenproblem" sein? DENON_AVR hat recht viele Readings.


Grüßle, Michael

rudolfkoenig

Oeffne bitte die JavaScript Console des Browsers, und schau da nach, was angezeigt wird.
Falls ein FHEM-Event die aktuelle FHEM-Seite betrifft, dann sollte was in der Console erscheinen.

Welchen Browser verwendest Du?
Gehst Du ueber Proxy?

ZitatFHEMWEB longpoll steht auf websocket (default scheint aber 0 zu sein laut erstem GUI-Vorschlag).
Voreinstellung fuer longpoll ist websocket mit Chrome, sonst 1 (d.h. "echtes" longpoll).
Was verwendet wird, steht beim Aufruf der Seite in der JS Console (Inform channel opened...)
Vorschlag ist 0, weil per Voreinstellung bereits aktiviert.

olwaldi

#9
Ich nutze Firefox unter tumbleweed-Linux. Aber Chrome verhält sich unter Android 14 genauso.
Für mich sieht es so aus, als wenn alle fhem-Events als Rcvd-events in der java-Konsole ankommen - hier mal auf state gefiltert:
15:33:23.908 Rcvd: ["Denon-state","on","on"] fhemweb.js:613:13
15:33:23.909 Rcvd: ["Denon-state-ts","2026-02-08 15:33:23","2026-02-08 15:33:23"] fhemweb.js:613:13
15:33:23.909 Rcvd: ["Denon-stateAV","on","on"] fhemweb.js:613:13
15:33:23.910 Rcvd: ["Denon-stateAV-ts","2026-02-08 15:33:23","2026-02-08 15:33:23"] fhemweb.js:613:13
Im Beispiel habe ich den Receiver im Tuner-Betrieb eingeschaltet. Das Internal STATE bleibt dabei auf off.

Beim Refresh/F5 im Browser sehe ich
15:40:51.930 FW_queryValue:{ReadingsVal("Denon","volumeStraight","")} fhemweb.js:613:13
15:40:51.938 FW_queryValue:{AttrVal("Denon","room","")} fhemweb.js:613:13
15:40:52.021 Inform-channel opened (websocket) with filter Denon fhemweb.js:613:13
15:40:52.082 Rcvd: fhemweb.js:613:13
Und danach steht STATE auf on. Aber da fällt mal wieder volumeStraight auf...

Ich habe dann auch noch gecheckt, was bzgl. Readings passiert. In DENON_AVR kann man die Anzeige von units ein/ausschalten. Dann wird z.B. hinter Lautstärken dB angezeigt, d.h. alle Lautstärke-Readings sollten dann aktualisiert werden. In den fhem-Events sehe ich die auch alle, aber in der java-Konsole fehlen manche. Und die werden in der GUI nicht aktualisiert.
Aber nach einem F5 werden die Werte aller Readings richtig angezeigt. Und in der java-Konsole gibts dieselbe Meldung wie oben bei F5.

Sieht ja fast so aus, als wenn das Reading volumeStraight irgendwie fehlerhaft im Modul verarbeitet wird. Ich habe im ursprünglichen Modul-Code die Aufrufe readingsBegin/EndUpdate korrigiert, um sicherzustellen, daß die Begin/End-Struktur nicht "gebrochen" wird. War m.E. ursprünglich so.

Noch eine sehr seltsame Merkwürdigkeit: Die Zeitstempel bei (manchen) Readings ändern sich bei F5/Refresh auf die aktuelle Zeit, ohne daß irgendein fhem-Event aufgetreten ist oder sich das Reading geändert hat (event-on-changed-reading steht auf .*). Aber das passiert nur, wenn sich die aktuelle Uhrzeit bzgl. Minuten geändert hat. Gesehen in Chrome@Android 14.


Grüßle, Michael