Problem mit Volume Widget und min/max Werten

Begonnen von Sheep, 11 März 2020, 16:26:48

Vorheriges Thema - Nächstes Thema

Sheep

Hallo zusammen,

ich habe ein Problem mit dem Volume-Widget und den einstellbaren min/max-Werten. Es geht um die Steuerung der Farbtemperatur einer WLAN-Lampe. Im "normalen" FHEM funktioniert alles, und ich kann dort den Wert passend ändern. Der Bereich geht hier von 153 bis 500 für Kalt- bis Warmweiss. Das hätte ich jetzt gerne im FTUI per Volume-Widget mit data-min und data-max gelöst:



        <div data-type="volume"
            data-min="153" data-max="500"

            data-device="par-device"
            data-get="RESULT_CT" data-set="CT"

            class="dim-tick dim-front small top-space-2x tap">
        </div>



Das hat aber nicht ganz den von mir gewünschten/erwarteten Effekt. Es gibt in der widget_volume.js eine Begrenzung des max-Wertes auf 360:


elem.data('max', (maxval > 360) ? 360 : maxval);


So entsteht aber ein recht inkonsistentes Verhalten bezüglich max und min. Zum einen geht in der Anzeige des FTUI der Wertebereich in dem Fall von 153 bis 360, der an FHEM gesendete Wert aber von 213 bis 500  :o Per FTUI kann ich so also den niedrigsten Wert zwar einstellen, gesendet wird aber ein höherer Wert (153 vs 213) Beim max-Wert, wird zwar der richtige Wert gesendet, aber der falsche Wert angezeigt.

Es wird also der Maximalwert in der FTUI Anzeige auf 360 begrenzt, aber für das egt Senden korrekt umgerechnet. Der Minimal-Wert wird aber für die Anzeige (und somit linkes Anschlag des Dreh-Knopfes) verwendet, aber für das egt Senden müsste man bis auf Null drehen können  :'(

Und hier hab ich mich dann gefragt, was der Gedanke hinter der Begrenzung von data-max auf 360 ist. Testweise hab ich die Zeile durch


elem.data('max', maxval);


ersetzt, und schon funktioniert das Widget, wie ich gedacht hätte. Sowohl der Anzeige-Wert, als auch der gesendete Wert geht von 153 bis 500... Bei einer Begrenzung auf 360 kam mir dann auch erstmal hue-tick in den Sinn, aber auch, wenn ich die Formatierung darauf umstell, funktioniert meiner Meinung nach alles korrekt, ohne diese Begrenzung auf 360.

Ich hab mir dann auch mal noch die Mühe gemacht, die Git-Historie der Datei anzuschauen, ob da der Gedanke dahinter erklärt wird, aber die betreffende Zeile ist leider einfach von Anfang an drin...

Für mich hab ich das Problem also egt schon gelöst, aber falls es keinen Grund für die Begrenzung (mehr) gibt, könnte man das Problem ja auch an der "Wurzel" korrigieren...

Evtl kann mir da jemand der tiefer drin steckt weiter helfen  :)




SputnikElf

#1
Hallo Sheep,

ich habe mir das widget_volume.js nach widget_tradfri.js kopiert.
Diese Abfrage ist eigentlich nicht wirklich angebracht, vielleicht konnte sich keine Vorstellen, dass es Werte größer 360 geben wird.
Zusätzlich habe ich den Mode 7 eingebaut für "ct-tick" (ColorTemp).
function init:

           elem.data('max', maxval);

            if (elem.hasClass('ct-tick')) {
                mode = mode | 1 << 7;
                hdDefaultColor = '#bbbbbb'; // Zeigerfarbe
            }

function drawDial :
              else if ((this.o.mode >> 7) % 2 !== 0) {
                c.strokeStyle = ftui.getGradientColor('#ff8800', 'fff3ef', (this.endAngle - tick) / this.angleArc);
            }

Nun sieht es gut aus.
Michael
FHEM Pi3, Tasmota OMV, HarmonyHub, HyperionNG

Stonemuc

Oh..gut dass es so einfach ist und danke dafür.
Ich hatte vor einigen Wochen hier genau das gleiche Problem festgestellt und nach einer Lösung gefragt.
Vermutlich ist wirklich das gescheiteste, dass man sich eine eigene widget-Version baut, da die andere beim Update ja immer wieder überschrieben wird.
FHEM aus Raspberry PI 3 B+, Haussteuerung auf EnOcean Basis, Tecalor THZ 404eco Wärmepumpe