Hallo,
ich habe am Thermostat-Device folgendes Attribut:
widgetOverride desired-temp@set:knob,min:5,max:30,angleArc:180,width:40,height:40,fgColor:#FF9900,bgColor:#CCCCCC,step:0.5,lineCap:round,angleOffset:225
Die Temperatureinstellung geht von 5 bis 30 °C.
Da die Drehung des Knopfes mit der Maus fummelig ist, will ich die Zahleneingabe in das Eingabefeld mitten im Knopf benutzen. Allerdings greift bei der Eingabe von Ziffern die Prüfung auf den erlaubten Wertebereich so schnell, dass es nicht möglich ist, den Wert 20 einzugeben.
Ich tippe 2, das ist nicht erlaubt, der Wert im Feld wird zurückgesetzt, bevor ich 21 eingegeben habe.
Kennt jemand dieses Problem und weiß, wie man es behebt?
Grüße
Boris
Hmmm, ich glaube mich zu entsinnen, dass diese Hakeligkeit damals der Grund dafür war, warum das Widget "nur" per widgetOverride in den Thermostat-attrTemplates vercodet ist...
Danke für die Rückmeldung!
Das Widget ist ja an sich schön, und ich wollte es gerne nutzen und daher habe ich nachgefragt, bevor ich auf slider umstelle.
Bevor ich jetzt anfange, im FHEMWEB zu graben, vielleicht weißt du das aus dem Kopf: Ist das Widget aus jquery importiert oder wird der Code dazu von den FHEM-Entwicklern in unserem Repo gepflegt?
Grüße
Boris
Soweit ich mich entsinne, kommt das js mit fhem, man könnte es also anpassen...
Es handelt sich um
www/pgm2/jquery.knob.min.jsIch habe die Datei durch einen Beautifier geschickt.
Das Problem mit diesem Kode ist, dass nach jedem KeyUp der eingegebene Wert gegen min und max validiert wird. Das funktioniert wohl, wenn min 0 ist, aber nicht, wenn er, wie bei Thermostaten, 5 ist.
Es ist nicht damit getan, die Stelle zu ändern.
}).bind("keyup", function(e) {
if (isNaN(u)) {
if (a) {
window.clearTimeout(a);
a = null;
f = 1;
t.val(t.$.val())
}
} else {
t.$.val() > t.o.max && t.$.val(t.o.max) || t.$.val() < t.o.min && t.$.val(t.o.min)
}
});
Das Widget dürfte erst validieren, wenn das Texteingabefeld den Fokus verliert oder man Enter drückt. Das überschreitet meine Javascript-Fähigkeiten.
Ich nutze noch nirgends widgetOverride, habe aber heute mal mit den Beispiel rumgespielt. Mit der Maus kann ich es ganz gut bedienen, wenn ich erst rein klicke, den Mauszeiger dann nach außen ziehe und erst dann zum Einstellen bewege. Da ist der Radius dann größer. Auf einen Tablet wäre das aber nichts.
Was auch funktioniert, in das Eingabefeld klicken und dann Cursor rauf oder runter. Allerdings wir da immer gleich ein Set ausgeführt, nicht erst wenn man auf dem gewünschten Wert ist.
Leider kann ich auch kein Javascript.
Sowas wie eine kurze Wartezeit wäre gut, oder?
Als Crossreferenz noch: https://forum.fhem.de/index.php?topic=97584.0
Lang ist es her ..
ZitatAllerdings greift bei der Eingabe von Ziffern die Prüfung auf den erlaubten Wertebereich so schnell, dass es nicht möglich ist, den Wert 20 einzugeben.
Das geht schon, man muss nur die 0 druecken, bevor man die 2 loslaesst. :)
Ich habe jetzt eine modifizierte Version von jquery.knob.min.js eingecheckt, was eine Sekunde Zeit zwischen den Tastendruecken zulaesst.
Zitat von: rudolfkoenig am 14 März 2026, 12:36:57Ich habe jetzt eine modifizierte Version von jquery.knob.min.js eingecheckt, was eine Sekunde Zeit zwischen den Tastendruecken zulaesst.
Danke!
Fühlt sich deutlich besser an!!!
Zitat von: Beta-User am 13 März 2026, 08:36:18Hmmm, ich glaube mich zu entsinnen, dass diese Hakeligkeit damals der Grund dafür war, warum das Widget "nur" per widgetOverride in den Thermostat-attrTemplates vercodet ist...
Nach etwas längerem Nachdenken: Es gab zwei Gründe...
Der zweite war das mit der Farbgebung ::) . Im Moment dürfte die "darkstyle"-Variante verteilt werden...
Aber js ist leider auch nicht mein Ding.
OT:
Falls jemand mit js-Kenntnissen hier mitliest, ich hätte da noch was auf meinem "für irgendwann mal"-Stapel rumliegen;
Zitat von: Beta-User am 26 November 2025, 21:31:14Von daher die dringliche Bitte: Falls hier jemand mitliest, der irgendeine Idee hat, wie man ein per touch aktivierbares Mikrofon-Overlay (per javascript) bastelt, das den STT-Teil übernimmt und an FHEM übermittelt (und optimalerweise auch von FHEM aus aktiviert werden kann) - jeder Code-Schnippsel ist willkommen!!!
ZitatVon daher die dringliche Bitte: Falls hier jemand mitliest, der irgendeine Idee hat, wie man ein per touch aktivierbares Mikrofon-Overlay (per javascript) bastelt, das den STT-Teil übernimmt und an FHEM übermittelt (und optimalerweise auch von FHEM aus aktiviert werden kann) - jeder Code-Schnippsel ist willkommen!!!
Wie stellst Du dir das vor?
Zitat von: rudolfkoenig am 14 März 2026, 16:13:04ZitatVon daher die dringliche Bitte: Falls hier jemand mitliest, der irgendeine Idee hat, wie man ein per touch aktivierbares Mikrofon-Overlay (per javascript) bastelt, das den STT-Teil übernimmt und an FHEM übermittelt (und optimalerweise auch von FHEM aus aktiviert werden kann) - jeder Code-Schnippsel ist willkommen!!!
Wie stellst Du dir das vor?
Das ist hier ziemlich OT, also @Boris, falls du was dagegen hast - bitte melden!
In dem verlinkten Thread von oben ist ein wenig mehr zum Hintergrund zu lesen, was mich (ad interim) "motiviert hat", die Pflege des FULLY-Moduls (kann mit dem Fullscreen-Browser "fully" für Android interagieren) zu übernehmen. Leider kann ich das Endergebnis von den technischen Abläufen her auch noch nicht so exakt beschreiben, wie ich mir das selbst wünschen würde.
Als Einstieg - es gab mal WebViewControl (https://wiki.fhem.de/wiki/WebViewControl#Installation), über das ich über einen anderen, im FULLY-Thread verlinkten Beitrag "gestolpert" bin (habe das nie benutzt, und diese neue App auch nur kurz angetestet, die zumindest bewiesen hat, dass "sowas" auch heute noch geht). Jedenfalls gehörte zur Installation von WebViewControl:
Zitat95_WebViewControl.pm - kommt in den Ordner FHEM (als Kopie oder als Symlink)
webviewcontrol.css und webviewcontrol.js - kommen in den Ordner /www/pgm2
WebViewControl.apk - das ist die APP und muss auf dem Android Gerät installiert werden.
Die Phonegap JS-Library wurden von der WebViewControl-JS-Datei entkoppelt. Daher muss cordova-2.3.0.js in www/pgm2.
mic_sprite.png muss in den Images-Ordner.
Meine Gedanken dazu:
Die .pm und .apk könnten durch FULLY/fully ersetzt werden (eventuell mit AMADBridge ergänzt), um den erkannten Text nach FHEM zu bringen.
Bleiben webviewcontrol.css, webviewcontrol.js und cordova-2.3.0.js übrig...
"cordova" scheint es immer noch zu geben, eventuell in einer aktuelleren Version, eventuell gäbe es auch eine Alternative, deren Namen ich allerdings zwischenzeitlich wieder vergessen habe.
Zwischenziel wäre es jedenfalls, einfach "erst mal" ein klickbares Symbol über eine Webseite zu bekommen, das dann die Spracheingabe ermöglicht (und das Ergebnis dann optimalerweise direkt "irgendwohin" an ein FHEM-Device schreibt). fully/FULLY kennt dafür z.B. ein Reading "deviceid", das unique sein sollte (analog zu APP-ID@WebViewControl).
Ist es jetzt etwas verständlicher?
Ich hätte da was. Ich mache dazu mal einen neuen Thread auf.
Gruß schwatter
@Beta-User: nix dagegen, ich verfolge mal den anderen Thread.
@Rudi: vielen Dank für den neuen Knopp. Schaue ich mir an, sobald er per Update verfügbar und ich wieder zuhause bin.
Zitat von: Dr. Boris Neubert am 14 März 2026, 19:16:48@Beta-User: nix dagegen, ich verfolge mal den anderen Thread.
Thx, aber so oder so geht es hier weiter: https://forum.fhem.de/index.php?topic=144147.0
DANKE!!!
Zitat von: rudolfkoenig am 14 März 2026, 12:36:57ZitatAllerdings greift bei der Eingabe von Ziffern die Prüfung auf den erlaubten Wertebereich so schnell, dass es nicht möglich ist, den Wert 20 einzugeben.
Ich habe jetzt eine modifizierte Version von jquery.knob.min.js eingecheckt, was eine Sekunde Zeit zwischen den Tastendruecken zulaesst.
Ich habe das heute morgen testen können. Die Eingabe ist jetzt bedienbar. Danke dafür.
Es gibt eine neue und eine alte Auffälligkeit bei Knob:
- Ich nutze f18. Alle Thermostate haben Knob als widgetOverride. In einer Raumübersicht und in einer Detailsicht eines Thermostats kann ich im Eingabefeld ENTER drücken, ohne dass der Cursor das Eingabefeld verlässt - es sieht so aus, als ob der Wert nicht bei ENTER sondern nach dem Timeout übernommen wird und das Eingabefeld dann den Fokus verliert. In einer Raumansicht, wo auch andere Widgets sind, führt ENTER im Eingabefeld dazu, dass der Raum Home aufgerufen wird, also die Startseite von FHEM.
- Wenn bei Übernahme des Wertes das Setzen initiiert wird, erscheint erst kurz die 5 (Mininalwert) im Knob, bis dann das Gerät die neu eingestellte Temperatur zurückmeldet, und die eingestellte Temperatur im Knob angezeigt wird.
Auszug aus dem List des Thermostats:
define zigbee_0x54ef441000e7e6fa MQTT2_DEVICE zigbee_0x54ef441000e7e6fa
attr zigbee_0x54ef441000e7e6fa devStateIcon LOCKED:secur_lock:btnLock+UNLOCK UNLOCKED:secur_open:btnLock+LOCK
attr zigbee_0x54ef441000e7e6fa genericDeviceType thermostat
attr zigbee_0x54ef441000e7e6fa getList desired-temp:noArg desired-temp $DEVICETOPIC/get {"occupied_heating_setpoint": ""}\
temperature:noArg temperature $DEVICETOPIC/get {"local_temperature": ""}\
btnLock:noArg btnLock $DEVICETOPIC/get {"child_lock": ""}\
preset:noArg preset $DEVICETOPIC/get {"preset": ""}
attr zigbee_0x54ef441000e7e6fa jsonMap occupied_heating_setpoint:desired-temp local_temperature:temperature system_mode:mode battery:batteryPercent voltage:batterymV child_lock:btnLock
attr zigbee_0x54ef441000e7e6fa model Aqara SRTS-A01
attr zigbee_0x54ef441000e7e6fa periodicCmd temperature:55
attr zigbee_0x54ef441000e7e6fa readingList $DEVICETOPIC:.* { my %h;; my $temp = $EVENT;; $temp =~ s/,?("(holidays|workdays)":.([^]]+))./$h{$2}=$3/ge;; $EVENT =~ s/,?("(holidays|workdays)":.([^]]+)).//g;; my $h2 = json2nameValue($EVENT,'',$JSONMAP);; %h = (%h,%$h2);; \%h }\
zigbee2mqtt/0x54ef441000e7e6fa/availability:.* { json2nameValue($EVENT, 'availability_', $JSONMAP) }
attr zigbee_0x54ef441000e7e6fa room Gewerke->Thermostat,Räume->3->1 Schlafzimmer,Systeme->Zigbee
attr zigbee_0x54ef441000e7e6fa setList desired-temp:slider,5.0,0.5,30.0,1 $DEVICETOPIC/set {"occupied_heating_setpoint": $EVTPART1 }\
btnLock:LOCK,UNLOCK $DEVICETOPIC/set {"child_lock": "$EVTPART1"}\
preset:manual,away,auto $DEVICETOPIC/set {"preset": "$EVTPART1"}\
mode:off,heat $DEVICETOPIC/set {"system_mode": "$EVTPART1"}\
x_send_set_payload:textField { my $payload = $EVENT;;$payload =~ s/$EVTPART0 //;; qq($DEVICETOPIC/set $payload)}
attr zigbee_0x54ef441000e7e6fa setStateList on off
attr zigbee_0x54ef441000e7e6fa webCmd desired-temp
attr zigbee_0x54ef441000e7e6fa widgetOverride desired-temp@set:knob,min:5,max:30,angleArc:180,width:40,height:40,fgColor:#FF9900,bgColor:#CCCCCC,step:0.5,lineCap:round,angleOffset:225
Zitat von: Dr. Boris Neubert am 15 März 2026, 09:01:05Wenn bei Übernahme des Wertes das Setzen initiiert wird, erscheint erst kurz die 5 (Mininalwert) im Knob, bis dann das Gerät die neu eingestellte Temperatur zurückmeldet, und die eingestellte Temperatur im Knob angezeigt wird.
Das kommt vermutlich wegen setStateList: Wenn das gesetzt wird, wird in den (davon nicht damit erfassten) Reading-Wert desired-temp z.B. "set_22.5" geschrieben, was vom widget dann korrekterweise erst mal als nicht numerischer input gewertet wird.
Zitat von: Beta-User am 15 März 2026, 09:40:05Zitat von: Dr. Boris Neubert am 15 März 2026, 09:01:05Wenn bei Übernahme des Wertes das Setzen initiiert wird, erscheint erst kurz die 5 (Mininalwert) im Knob, bis dann das Gerät die neu eingestellte Temperatur zurückmeldet, und die eingestellte Temperatur im Knob angezeigt wird.
Das kommt vermutlich wegen setStateList: Wenn das gesetzt wird, wird in den (davon nicht damit erfassten) Reading-Wert desired-temp z.B. "set_22.5" geschrieben, was vom widget dann korrekterweise erst mal als nicht numerischer input gewertet wird.
Gut bemerkt. Ich habe das Attribut setStateList gelöscht und das Verhalten ist weg. Wozu ist das setStateList überhaupt im AttrTemplate und wieso mit on und off bei einem Thermostat?
Zitat von: Dr. Boris Neubert am 16 März 2026, 19:49:59Wozu ist das setStateList überhaupt im AttrTemplate und wieso mit on und off bei einem Thermostat?
"setStateList" (bzw. die Funktionalität) hat Rudi damals "für mich" in MQTT2_DEVICE eingebaut, damit man ein Verhalten erhalten kann, das nahe an dem liegt, was CUL_HM zeigt: Anweisungen werden auch im (zugehörigen) Reading-Inhalt als "vorläufig" gekennzeichnet, solange die Hardware keine Rückmeldung gegeben hat. Im MQTT2_DEVICE-default läuft alles über "state".
Was man genau in setStateList schreibt, ist eigentlich egal, wir hatten auch schon "none" ;D .
Wem das nicht gefällt, kann das Attribut ja löschen ;) .
In Verbindung mit dem Widget, das ja im Standard im Attribute-Template eingeführt wird, ist das aber nur bedingt sinnvoll, oder? Sollte man nicht das setStateList lieber aus den Templates löschen?
Zitat von: Dr. Boris Neubert am 24 März 2026, 19:11:56In Verbindung mit dem Widget, das ja im Standard im Attribute-Template eingeführt wird, ist das aber nur bedingt sinnvoll, oder? Sollte man nicht das setStateList lieber aus den Templates löschen?
Weiß nicht recht. Im Prinzip finde ich es auch nicht falsch, wenn man eine optische Irritation hat, solange ein Befehl nicht bestätigt beim Gerät angekommen ist. Das ist für mich v.a. der Sinn hinter "setStateList" (bzw. der Kennzeichnung der Reading-Inhalte als "set_").
Auch hier gilt: was per attrTemplate verteilt wird, ist ein Vorschlag, den jeder nach seinem Belieben anpassen kann, hier z.B. durch das Löschen des Attributs.