Wenn ich einen Dimmer mit einem Slider auf der Weboberfläche bediene, also zB von 0 % auf 80 % ziehe, dann ist es ja so, dass der Slider nach dem Loslassen erstmal wieder zurück springt auf die Ausgangsposition (nahezu). Es dauert dann ca. 4 Sekunden bis der Slider dann wieder zurück auf die Zielposition springt.
Das Verhalten erkläre ich mir so, dass der Dimmer ja zum einen einige Zeit braucht, um zur Zielposition zu dimmen und andererseits nochmal etwas Zeit braucht, um seine aktuelle Position zu senden. Oder?
Dieses Verhalten finde ich auf der Weboberfläche etwas unschön (gerade nun im Zusammenspiel mit dem sehr schicken SmartVISU :)). Auch wenn ich zB die Zieltemperatur des Thermostats um 3°C verstelle, indem ich 6mal auf den "+"-Button drücke (in 0,5°C-Schritten), dann springt die angezeigte Zieltemperatur nach ein paar Sekunden auf Zwischenwerte zurück.
Gibt es dagegen irgendwie Abhilfe? Wäre klasse, danke!
Posten sollte man dort nicht mehr, sagt mir das Board, aber hier ein ähnlicher Thread: http://forum.fhem.de/index.php?topic=23198.0
Inhaltlich und technisch ist das Verhalten bzw. die Anzeige im Web ja völlig korrekt, aber das Verhalten kommt für einen naiven Benutzer trotzdem überraschend und ist ihm nur schwer zu vermitteln, mMn. Wäre es nicht möglich, dass man tatsächlich per Attribut eine Zeit konfigurieren kann (default 0s), in der weiterhin der gewünschte Soll-Wert angezeigt wird? Also ich ziehe den Slider auf 80% und für bspw. 5 Sekunden bleibt der Slider bzw. "pct" auf 80. Erst danach wird wieder der echte gemeldete Wert gezeigt. Ich weiß, ist alles andere als schön, aber damit könnte man das Problem evtl. einigermaßen gut "workarounden". :(
Vielleicht gibt es ja auch noch bessere Ideen?
Hi,
aus dem verlinkten thread:
Zitat
Gibt es eine Möglichkeit, den slider des Dimmers direkt mit einem aufbereiteten dim Reading zu steuern, statt mit dem pct Reading ?
Aufbereitet deshalb, weil man ja noch den Zahlenwert aus dem dim:stop XXX extrahieren muss und ausserdem noch das "off" und "on" in Zahlenwert für den slider umwandeln muss.
Ich tu mich nur gerade schwer das gedanklich zu sortieren da ich keine HM dimmer habe.
Verstehe ich richtig: man kann via "pct" den Wert setzen, vmtl 0..100, und in "dim" steht entweder "off" oder "on" oder eine Zahl (während des dimmens) und wenn die Endposition erreicht ist steht da stop: und eine Zahl ?
Richtig wäre dann das der slider so aktualisiert wird: "off" -> 0, "on" -> 100 , nur eine Zahl -> mach nix und stop xxx -> xxx ? Wenn ja ist es für sv schnell lösbar
vg
jörg
edith and add
btw: hm-tc habe ich, da kann ich kein springen bestätigen und wüsste da auch nicht wo es da herkommen kann.
Ja, ich denke, man könnte das zumindest in SmartVISU mit einem sehr angepassten Widget oder Converter hinbekommen. Aber ich denke, sauberer (aber immer noch unsauber) könnte man das im HM-Modul lösen. Würde dann eben auch für alle Oberflächen funktionieren und wäre nicht auf SV beschränkt.
Und mit dem HM-TC hast du recht: das scheint wirklich ein anderes Problem zu sein (sieht nur ähnlich aus). Wenn ich mehrfach den "+"-Button gedrückt habe, dann kommen die einzelnen Stufen (18.5 -> 19.0 -> 19.5 ...) ganz langsam im Abstand von jeweils 2-3 Sekunden in FHEM an (laut Event-Monitor). Sehr seltsam...
probier mal die fhconverter bitte, da ist ein HMDimmer drin der sich so verhält wie oben. ggf bei Fehlfunktionen kru console und events vom dimmer reinstellen - kann das mangels hw nicht testen.
read ist "dim", set ist "pct"
vg
jörg
Vielen Dank, hab ich ausprobiert! Also das Dimmen über den Slider klappt damit super, kein Springen mehr. Leider reagiert der Slider jetzt aber nicht mehr auf Änderungen, die von FHEM initiiert werden. Also wenn ich den FHEMWEB-Slider bewege, kommt davon nichts in SV an.
Aber keine Panik, sobald ich dazu komme, kann ich mir das aber gerne auch nochmal selbst ansehen im Detail... Ist wahrscheinlich schwierig zu debuggen für dich ohne die HW.
ZitatIst wahrscheinlich schwierig zu debuggen für dich ohne die HW.
so schlimm ist es nicht, ich brauch ja nur die events. HM dimmer sind ja keine exotische Hardware und der Aufwand ist gering - daher sehr gern. Außerdem "schulde" ich Bernd eine vergleichbare Lösung für die blinds. Da wollte ich über timer gehen, so ist das aber viel besser. Vielleicht skaliert das. Wenn Du magst stell mal bitte kurze die events aus dem eventmonitor rein während der HM dimmt (ramp)
vg
jörg
Na gern doch :)
So sieht es aus, wenn der Dimmer auf 15% steht und ich auf 75% dimme. Das sind alle Events (ungefiltert).
2015-04-08 21:09:37 CUL_HM wz_lightDesk level: set_75
2015-04-08 21:09:37 CUL_HM wz_lightDesk set_75
2015-04-08 21:09:38 CUL_HM wz_lightDesk deviceMsg: 15.5 (to VCCU)
2015-04-08 21:09:38 CUL_HM wz_lightDesk dim: up:15.5
2015-04-08 21:09:38 CUL_HM wz_lightDesk level: 15.5
2015-04-08 21:09:38 CUL_HM wz_lightDesk overheat: off
2015-04-08 21:09:38 CUL_HM wz_lightDesk overload: off
2015-04-08 21:09:38 CUL_HM wz_lightDesk pct: 15.5
2015-04-08 21:09:38 CUL_HM wz_lightDesk reduced: off
2015-04-08 21:09:38 CUL_HM wz_lightDesk 15.5
2015-04-08 21:09:38 CUL_HM wz_lightDesk timedOn: off
2015-04-08 21:09:42 CUL_HM wz_lightDesk deviceMsg: 75 (to VCCU)
2015-04-08 21:09:42 CUL_HM wz_lightDesk dim: stop:75
2015-04-08 21:09:42 CUL_HM wz_lightDesk level: 75
2015-04-08 21:09:42 CUL_HM wz_lightDesk overheat: off
2015-04-08 21:09:42 CUL_HM wz_lightDesk overload: off
2015-04-08 21:09:42 CUL_HM wz_lightDesk pct: 75
2015-04-08 21:09:42 CUL_HM wz_lightDesk reduced: off
2015-04-08 21:09:42 CUL_HM wz_lightDesk 75
Großen Dank schonmal! Ich könnte ja im Gegenzug mal versuchen herauszufinden, was bei dem HM-TC passiert...
Gibts hier schon Neuigkeiten Jörg? Ich würde das Thema sonst übernehmen, wenn du magst? Ich denke aber leider, dass da keine saubere Lösung möglich sein wird. Mir schwebt da nur so ein Hack vor a la "zeig noch 10 Sekunden den Soll-Wert". Bin da natürlich für Ideen offen...
Läuft,. Muss aber nochmal debuggen weil Du sagtest der läuft nicht.
Ich hab das so umgesetzt: fhem meldet nur wenn der Wert in "dim" mit "stop" beginnt. Weil keine Zwischenwerte übertragen werden springt dann auch nichts - der Endwert (stop:.*) entspicht dem vorher am slider gesetzten. Worüber ich noch gestolpert bin: Du sprachst noch von "on" und "off", die habe ich auf 100 und 0 umgesetzt. Stehen die dann wirklich so im "dim" ? ("dim: off" / "dim: on")
vg
jörg
Zu #2:
Ja, wenn Dimmer aus, dann steht "stop:off" in "dim".
Zu #1:
Hm, willst du das Übertragen von Zwischenwerten komplett rausnehmen? :-\
Hi,
ZitatHm, willst du das Übertragen von Zwischenwerten komplett rausnehmen? :-\
Ja, das ist doch Sinn und Zweck der Geschicht - die Zwischenwerte verursachen doch das Springen der Slider.
Beides zusammen geht nicht: der slider setzt einen SOLL Wert - der Dimmer meldet davon abweichend für einen bestimmten Zeitraum andere IST Werte.
Erst wenn der Dimmer die STOP Position erreicht stimmen ja SOLL und IST wieder überein.
Andere Quelle ("at", "notify" anderer SV client stellt Werte ein): hier wird erst aktualisiert wenn der STOP Wert erreicht wird. Evtl solltest Du mit einer Kombination aus shifter und slider arbeiten. Der shifter könnte dann den IST Wert anzeigen und mitr dem Slider gibst Du den Sollwert an. ?
vg
Jörg
Ja das Problem ist die Kombination aus Ist- und Soll-Wert. Aber deswegen die Zwischenstufen komplett rauszunehmen, halte ich fuer keinen guten Weg. Da wuerde einfach zu viel Funktionalitaet verloren gehen.
Da finde ich den vorgeschlagenen Weg mit der "Totzeit" besser: Also wenn man den Slider im Web bewegt, dann wird fuer 5 (?) Sekunden der Soll-Wert angezeigt. Danach werden wieder alles Ist-Stufen angezeigt.
Der SV-Basic-Slider hat dafuer sogar schon einen aehnlichen Mechanismus eingebaut, jedoch nur fuer 400 ms. Ich denke, man koennte das leicht auf unsere Beduerfnisse anpassen.
ZitatDa finde ich den vorgeschlagenen Weg mit der "Totzeit" besser: Also wenn man den Slider im Web bewegt, dann wird fuer 5 (?) Sekunden der Soll-Wert angezeigt. Danach werden wieder alles Ist-Stufen angezeigt.
anstatt mit einer totzeit zu arbeiten, könnte man ja auch auf das
zweite event (besser eventgruppe) reagieren. das erste event (gruppe) ist wohl immer ein statusAck als antwort auf den gesendeten befehl (sollwert) mit dem status zum zeitpunkt des eintreffens des befehls. somit wäre die "totzeit" automatisch auf ein minimum reduziert. eventuell noch während dieser zeit die farbe des sliders verändern, damit man sofort erkennt, dass hier der sollwert angezeigt wird.
die antwortzeiten kannst du ja auch noch minimieren mit den registern R-statusInfoMinDly und R-statusInfoRandom.
Zitat von: vbs am 13 April 2015, 10:19:24
Ja das Problem ist die Kombination aus Ist- und Soll-Wert. Aber deswegen die Zwischenstufen komplett rauszunehmen, halte ich fuer keinen guten Weg. Da wuerde einfach zu viel Funktionalitaet verloren gehen.
Da finde ich den vorgeschlagenen Weg mit der "Totzeit" besser: Also wenn man den Slider im Web bewegt, dann wird fuer 5 (?) Sekunden der Soll-Wert angezeigt. Danach werden wieder alles Ist-Stufen angezeigt.
Der SV-Basic-Slider hat dafuer sogar schon einen aehnlichen Mechanismus eingebaut, jedoch nur fuer 400 ms. Ich denke, man koennte das leicht auf unsere Beduerfnisse anpassen.
Die Verzögerung finde ich uncool weil ja keine Ramp definiert sein muss. Dann würde das event mglw komplett untergehen. Also, so interpretier ich das jetzt. Schau: was sonst noch gehen würde: ich könnte das auf den aulösenden slider begrenzen. Also: die auslösende sv Instanz läßt den slider stehen bis der dimmer STOP meldet (danach ist IST gleich SOLL), Andere Instanzen bewegen sich mit den zwischenwerten.
Besser ? Wenn Du das ansonsten per delay machen möchtest (kannste ja durchaus) würde ich das ad acta legen - das würde ja in sv passieren.
vg
jörg
Zitatdie auslösende sv Instanz läßt den slider stehen bis der dimmer STOP meldet (danach ist IST gleich SOLL), Andere Instanzen bewegen sich mit den zwischenwerten.
Wäre meine wahl z.b. für Slider die beleuchtungen dimmen - die Dimm geschwindigkeit wird ja von HM oder einer anderen Lösung vorgegeben.
Bei Heizungsregelungen würde ich eher auf die Totzeit variante setzen, und mit +und - Tasten bedienen, so wie es ein readingsgroup beispiel im Wiki macht.
Letztendlich denke ich aber hier haben viele leute viele verschiedene meinungen...
Zitat von: herrmannj am 13 April 2015, 14:08:26
Die Verzögerung finde ich uncool weil ja keine Ramp definiert sein muss. Dann würde das event mglw komplett untergehen. Also, so interpretier ich das jetzt.
Da doch aber der User den Slider gerade auf den Soll-Wert gezogen hat und der Dimmer ohne Ramp-Time sofort diesen Zielwert angesprungen hat, bräuchte man doch auch keine weitere Rückmeldung vom Dimmer, oder? Der GUI-Slider würde ja ohnehin noch auf der richtigen Position stehen.
Zitat von: herrmannj am 13 April 2015, 14:08:26
Schau: was sonst noch gehen würde: ich könnte das auf den aulösenden slider begrenzen. Also: die auslösende sv Instanz läßt den slider stehen bis der dimmer STOP meldet (danach ist IST gleich SOLL), Andere Instanzen bewegen sich mit den zwischenwerten.
Das klingt sehr gut für mich. Wenn im Converter die dafür nötigen Infos vorliegen und man das daher dort entscheiden kann, wäre das klasse, denk ich. Am Slider farblich kenntlich zu machen, ob es sich noch um Sollwert oder schon um Istwert handelt, finde ich auch nett. Schau ich vielleicht mal rein...
Ich hab jetzt mal eine Variante gebaut, die sich eingehende Set-Befehle merkt und dann denjenigen Geräte, die noch ausstehende Befehle haben, nur dann den Wert zuschicken, wenn der Befehl mit "stop" anfängt. Sprich: Es werden weiterhin allen Geräten auch Zwischenbefehle geschickt. Wenn man jedoch in SV bei einem Gerät den Slider bewegt, dann bekommt er erst ab dem nächsten "stop" wieder Updates, bleibt also erstmal auf dem hingeschobenen Wert.
Ich hab da jetzt einfach einen globalen Hash genommen, um zu speichern, für welche Geräte noch ACKs ausstehen. Hat jemand eine bessere Idee, wo man diese Infos sauberer ablegen könnte?
https://github.com/verybadsoldier/fronthem/commit/c93bc4e6f8550a7d52b6ae57aa71fc7154c367df