Basierend auf diesem Thread http://forum.fhem.de/index.php/topic,14753.msg95363.html#msg95363 (http://forum.fhem.de/index.php/topic,14753.msg95363.html#msg95363)
habe ich mich mal der Umsetzung des Knob Steuererlements angenommen.
Wer dies testen möchte muss die Dateien fhemweb_knob.js und jquery.knob.js
in das Verzeichnis /www/pgm2 kopieren und den 01_FHEMWEB.pm.patch anwenden, oder die angehängte 01_FHEMWEB.pm verwenden.
Nach einem FHEM neustart kann man sich einen dummy wie folgt erstellen
define knobdummy dummy
attr knobdummy alias Knob Test
attr knobdummy room KNOB
attr knobdummy setList state:knob
attr knobdummy webCmd state
die Darstellung des Steuerelements kann über diverse Parameter mitgegeben werden, diese werden mit Komma getrennt hinter knob eingegeben z. B.
attr knobdummy setList state:knob,step=5,width=150,thickness=.4,bgcolor=indigo,cursor=false,anglearc=180,angleoffset=270,linecap=round
Es gibt die folgenden Parameter, welche alle optional sind.
min für den minimalen Wert z.B. 10
max für den maximal Wert z.B. 150
step in welchen Schritten der Wert geändert wird z.B. 5
width Größe des Steuerelement z.B. 150
thickness Breite des angezeigten Rand z.B. .3
fgcolor Farbe des Rings z.B. red oder #121212
bgcolor Hintergrundfarbe des Rings z.B. blue oder #454545
anglearc Welchen Radius der Ring darstellt z.B. 120
angleoffset An welcher Stelle der Ring beginnt z.B. 270
linecap Darstellung des Anfangs/Ende des Ring rund oder eckig, erlaub ist butt oder round
displayinput Eingabe eines Werts in der Mitte des Rings, erlaubt ist true oder false
cursor Vergrößern des Rings durch die Maus oder bewegen einer Markierung auf dem Ring, erlaub ist true oder false
Die Beispiele im Screenshot sind wie folgt erstellt worden:
define knobdummy1 dummy
attr knobdummy1 alias Knob Test 1
attr knobdummy1 icon refresh
attr knobdummy1 room KNOB
attr knobdummy1 setList state:knob,min=50,max=500,step=50,width=100,thickness=.3,fgcolor=yellow
attr knobdummy1 webCmd state
define knobdummy2 dummy
attr knobdummy2 alias Knob Test 2
attr knobdummy2 icon refresh
attr knobdummy2 room KNOB
attr knobdummy2 setList state:knob,step=5,width=150,thickness=.2,fgcolor=greenyellow,cursor=false
attr knobdummy2 webCmd state
define knobdummy3 dummy
attr knobdummy3 alias Knob Test 3
attr knobdummy3 icon refresh
attr knobdummy3 room KNOB
attr knobdummy3 setList state:knob,step=5,width=150,thickness=.4,bgcolor=indigo,cursor=false,anglearc=180,angleoffset=270,linecap=round
attr knobdummy3 webCmd state
define knobdummy4 dummy
attr knobdummy4 alias Knob Test 4
attr knobdummy4 icon refresh
attr knobdummy4 room KNOB
attr knobdummy4 setList state:knob,step=5,width=50,thickness=.4,bgcolor=darksalmon,fgcolor=firebrick,cursor=false,anglearc=180,angleoffset=90
attr knobdummy4 webCmd state
Gruß Svenson
sehr geil :)
Werde ich uebernehmen, aber erst wenn es "autoload-modulfaehig" ist, und dazu muss vmtl. auch FHEMWEB angepasst werden.
Ich moechte dafuer die ganze Logik in Javascript haben, um hier den Engpass FHEMWEB (und damit mich) zu loesen. Vermutlich werden dafuer auch die anderen Widgets (slider & co) angepasst.
Hallo Rudi,
Zitataber erst wenn es "autoload-modulfaehig" ist
so ganz versteh ich das nicht, muss ich noch was ändern/ anpassen?
Mir selbst gefällt im Patch auch nicht das dort die jquery in FHEMWEB explizit angegeben werden muss. Lässt sich das evtl. entkoppeln, z.B. das alle .js Dateien in einem "Lib" Verzeichnis von FHEMWEB autom. geladen werden ohne das diese explizit angegeben werden müssen? Ähnliches ist auch mit fhemweb_*.js umgesetzt. Das "Verzeichnis" ist nur mal so in den Raum gestellt, da mir die Diskussion mit der Verzeichnisstruktur bekannt sind.
Gruß Svenson
Nein, du musst nichts aendern, aber leider warten.
Genau diese Fragen, die du stellst, muessen erst geklaert werden. Und ich will nicht alle .js laden, sondern nur bei Bedarf, genauso wie fhem.pl die FHEM-Module. Frag mich aber nicht, wie das gehen soll, ich weiss es noch nicht :)
Ok, warten ist ist nicht das Problem 8)
ZitatFrag mich aber nicht, wie das gehen soll, ich weiss es noch nicht
Die fhemweb_*.js werden geladen wenn diese da sind. Daher der erste Gedanke mit dem Verzeichnis. Unter der Annahme alles was da drin ist wir benötigt - was nicht die beste Lösung ist. Denn entweder dort ist alles drin was jemals in Frage kommt, oder der User muss gezielt benötigte Dateien dort rein kopiere - was dazu führt das einfach alles dort rein kopiert wird.
Mir fällt nur die Lösung über Abhängigkeiten aus der Praxis ein. z.B. würden in einem Modul dependencys definiert, die wiederum bestimmen welche .js geladen werden. Prinzipiell so wie das svg.js in 01_FHEMWEB geladen wird, eben nur bei bedarf. Im Bezug auf das Knob ist das jetzt nicht wirklich die Wahnsinsidee, selbst wenn du die Widgets ausgelagers und in diesen Abhängigkeiten definiert wären könntest du in FHEMWEB nicht wissen welches Widget wirklich benötigt wird ..... oder doch?
Zitatgenauso wie fhem.pl die FHEM-Module.
Die Module werden doch geladen wenn diese definiert sind. Ginge sowas auch mit den Widgets? Dann wäre nur die Frage wie die Widgets ausgelagert und geladen werden ... und damit versteh ich glaub ich dein erstes Post zu dem Thread ???
@rudi: wenn du dabei bist bei den widgets etwas umzustellen wäre es klasse die das backend und das frontend etwas mehr zu entkoppeln.
d.h. wenn ein modul ein set mit einen bestimmten wertebereich anbietet sollte der user in der lage sein zu entscheiden ob er einen slider oder die knobs möchte oder vielleicht sogar ein menü mit nur drei festen werten.
eine möglichkeit dazu wäre bei webCmd die modifier ebenfalls zu erlauben und so den modul default zu überschreiben.
in der readingsGroup erlaube ich so etwas schon und es ist sehr praktisch.
ich weiss das es von der syntax mit dem splitten nicht passt. aber vielleicht hast du dazu eine idee.
Zitat von: rudolfkoenig am 26 Februar 2014, 09:46:00Und ich will nicht alle .js laden, sondern nur bei Bedarf, genauso wie fhem.pl die FHEM-Module. Frag mich aber nicht, wie das gehen soll, ich weiss es noch nicht
vielleicht mit jQuery und getScript() ?
http://www.hackthenet.de/weblog/208/javascript-dateien-mit-jquery-dynamisch-nachladen
Ok, ich praezisiere :)
Ich hab nicht das Problem mit dem wie, sondern mit dem wann, und welche. Sowas wie ein "define" fehlt hier ja.
hm... ich hätte jetzt eher das "wie" als das größere Thema angesehen :)
Ok, zugegeben, ich bin jetzt nicht der javascript-Spezialist.
Könnte man nicht eine neue Klasse knob einführen, die ihre Eigenschaften von dummy erbt ? Dann könnte man mit
define knobdummy knob
einen neuen Knob definieren und erst dann das Modul und javascript Zeug laden. Analog könnte es eine Klasse Slider geben ebenso von Dummy abstammend
was soll das denn bewirken? zum einen funktionen das in fhem nicht so mit den klassen und zum anderen soll der knob und slider und die anderen widgets ja nicht nur in dummys und nicht nur einer pro device verwendet werden.
Idee war einen define hinzubekommen, der anzeigt, das wir die JavaScript Sachen für Knobs brauchen und die dann nach laden können .
@T.ihmann: da das Problem "in" der HTML-Seite (== Raum- bzw. Detailansicht) ist, muesste man diesen knobdummy auf jeder Seite, der ein Knob hat, zuordnen. Und dann noch ein calenderdummy, enhancededitordummy, usw. und das ist mAn fuer etwas groessere Installationen nicht handhabbar. Und dann gibt es noch FLOORPLAN. Und damit waere erstmal nur das .js geladen, der wuesste aber noch nicht genau, welche Elemente jetzt in Knob zu verwandeln sind.
Ich denke eher an folgendes: Widget-Typ in einem Attribut des betroffenen HTML-Elementes hinterlegen (FW_widget="knob"), fhemweb.js sucht nach Laden der Seite alle Elemente nach diesem Attribut durch, und laedt die benoetigten javascript Dateien. FHEMWEB muss anhand von ZZZ diese Elemente markieren. ZZZ koennte per default aus dem :modifier fuer Befehle aus "set X ?" bzw. "attr X ?" fuer Attribute kommen, wie bisher, aber der Benutzer muss in der Lage sein es zu aendern, vmtl. per Attribut fuer einzelne Geraete. Das passt aber nicht auf dem enhancededitor, und hinkt noch beim webCmd
Zitat von: rudolfkoenig am 05 März 2014, 09:45:59Das passt aber nicht auf dem enhancededitor,
Was bräuchtest Du beim enhancedEditor, um ihn (besser/überhaupt) in Dein Konzept integrieren zu können?
Zeit oder Ruhe :)
Das kommt schon noch, seid nicht so ungeduldig.
ich bin nicht ungeduldig (bei mir läuft der Editor derzeit ja prima), ich wollte nur Unterstützung anbieten und ggf. weiterhelfen...
hochinteressant und ich sehe das erst jetzt :)
folgender Vorschlag: der Knob (und alle seine Kameraden: wie slider, buttons, picker .... ) dürften doch eigenes fhem device werden ?
Das wäre nämlich in Bezug auf floorplan, webview control, mobile apps etc hochinteressant.
Aufgabe dieser Device wäre dann nur die generische (!) graphische Repräsentation von einzelnen oder Gruppen "echter" device. Damit wäre die die Frage des ladens geklärt. Ich erstelle ein device und positioniere das im Floorplan, in der app - whatever. Das device-Steuerelement im Browser (App) spricht nur auf einem longpoll mit fhem (dadurch werden websockets bzw virtual vpn per remote proxy möglich). Auf fhem seite spricht das device mit seinen physikalischen counterparts per event (wo geht) sonst per set/get.
Das laden des javascript mache im Augenblick mit injection über die webcmd function. Das ist sicher nicht der "traditionelle" Weg. Aus Sicht des Users macht das meiner Meinung nach aber ganz viel Sinn weil ich dann zum Beispiel mit nur einer pm Datei die Steuerelemente austauschen kann (wegen Skin). Habe so also Funktionalität und Design komplett in einer Datei gekapselt. Den Prozess der injection kann man aber sicher fhem seitig verbessern. Ob bestimmte benötigte js schon injected sind und solche Sachen.
vg
Jörg
Da ich den thread hier gestartet habe melde ich mich auch nochmal zu Wort.
Ich finde man soll Rudi an der Stelle vertrauen. Er hat da den besten durch und überblick und in der Angelegenheit sollte man ihm vielleicht auch mal die von ihm gewünschte Ruhe lassen und auch etwas Geduld beweisen.
Ich würde das steuerelement auch lieber heute als morgen nutzen, aber ich überlass das Rudi.
Mir ist eine überlegte und durchdachte, strukturierte Lösung lieber als etwas dahin geschustertes.
Ein eigenes Devise für knob halte ich nicht für den richtigen weg, und schließe mich Rudis Ausführung dazu an.
Geduld ist eine Tugend, und wenn es erst mit fhem 5.6 umgesetzt wird, dann ist das halt so. Mir wichtig ist nur zu Wissen das Rudi das auf dem schirm hat und nicht in der Versenkung unter geht.
Hallo zusammen,
KNOB scheint jetzt ja in FHEM integriert zu sein, jedenfalls gibt es fhemweb_knob.js und jquery.knob.min.js in www/pgm2/
Trotzdem reagiert KNOB nicht auf die Parameter nach state:knob, z.B.:
state:knob,step=5,width=150,thickness=.4,bgcolor=indigo,cursor=false,anglearc=180,angleoffset=270,linecap=round
Egal was man macht, es bleibt immer der Vollkreis von 0-100.
Kann mir jemand helfen?
Danke und Gruß!
: statt =state:knob,step:5,width:150,thickness:.4,bgcolor:indigo,cursor:false,anglearc:180,angleoffset:270,linecap:round
siehe auch commandref.
gruss
andre
Oder z.B so:
state:knob,min:12,max:25,step:0.5,fgColor:DarkOrange,anglearc:180,angleoffset:270,bgcolor:Blue,width:250,linecap:round,font:lcars,displayPrevious:true
Hier findest du auch noch ein paar Parameter:
https://github.com/aterrien/jQuery-Knob (https://github.com/aterrien/jQuery-Knob)
Gruß Volker
Vielen Dank!
Gäb's eigentlich auch ne Möglichkeit, den Knob Read-Only zu machen?
Wäre toll als reine Anzeige für gewisse Dinge :)
lg, Ici
Dazu konsultierst du am besten die Seite des Autors.
die angabe dort auf der seite ist falsch (data-readOnly) richtig ist:
readOnly=false bzw. in fhem readOnly:false
gruss
andre
Ich hatte bei mir ein kleines Problem mit dem Setzen der Farben des Knob:
attr helper_og_licht_wz_dim setList state:knob,min:10,max:100,step:5,fgColor:#bbbbbb,width:90,angleOffSet:-80,angleArc:160,displayInput:false,bgColor:#222222
Das funktioniert auch wenn ich das so über das Frontend eingebe, allerdings wird nach Schreiben der Konfiguration und anschließendem rereadcfg das Hash-Zeichen wohl als Kommentar interpretiert und alles folgende ignoriert. Dann steht im Frontend nur noch das hier:
attr helper_og_licht_wz_dim setList state:knob,min:10,max:100,step:5,fgColor:
Im Konfigfile steht das Attribut aber noch vollständig.
Ich kann das zwar umgehen indem ich statt der Zahlenwerte einfach Farbennamen verwende, aber für mich sieht das nach Bug aus, dass ich ein Attribut im Frontend eingeben kann und dieses vollständig interpretiert wird bis zum Schreiben und Neulesen der Konfig. Fehlt da ein Escaping beim Schreiben der Konfiguration?
Das Kommentarzeichen # sollte aehnlich wie in perl funktionieren.
Ich sehe es aber ein, dass es zunehmend Probleme bereitet, habs deswegen geaendert, dass es nur noch am Anfang der Zeile als Kommentarzeichen wahrgenommen wird..