colorpicker für fhemweb

[justme1968]

guten morgen,

ich bin gerade dabei einen colorpicker ins fhemweb einzubauen. eine erste test version geht schon und ich kann die farbwerte für meine hue birnen interaktiv einstellen. jetzt habe ich aber ein paar fragen zum allgemeinen vorgehen.

der colorpicker ist zur zeit dieser hier http://jscolor.com. es war der erste den ich gefunden habe und mir scheint die lizenz ok.
- gibt es prinzipielle richtlinien um ein zusätzliches javascript element in fhemweb einzubinden?
- gibt es einen vorschlag für einen anderen colorpicker?
- gibt es sonstige prinzipielle vorschläge?

- da ich keinerlei ahnung von javascript habe läuft er zur zeit nur in der raumübersicht. in der detailansicht bekomm ich ihn noch nicht zum funktionieren. ich vermute das das click event abgefangen wird. wer kennt sich aus und hat lust hier mal mit hin zuschauen?

anbei noch ein zwei screenshots wie das ganze ausschaut:
(siehe Anhang / see attachement)
(siehe Anhang / see attachement)

gruss
  andre

[rudolfkoenig]

Die Aufgabe hat mehrere Aspekte:
- jscolor.js ist mit 35k nicht gross, und mit LGPL auch FHEM vertraeglich, es koennte also unter fhem/www/jscolor eingecheckt werden. Bei dieser Groesse wuerde ich es sogar automatisch mit dem standard update ausliefern, und dafuer nicht ein extra Paket bauen, letzteres ist mit update dank Martin aber auch moeglich.
- in der Detailansicht will ich sowieso eine Schnittstelle fuer Module anbieten, ich sehe ein, dass das auch fuer den Uebersicht sinnvoll waere. Das kann aber noch etwas dauern.

[justme1968]

anbei zwei kleine patches die den colorpicker in der raumübersicht benutzen und in der detail ansicht zumindest die manuelle eingabe der farbwerte erlauben. zusätzlich ist nur jscolor wie vorgeschlagen unter fhem/www/jscolor nötig.

die idee ist analog zur slider definition in der set liste ein rgb:colorpicker,RGB verwenden zu können.

vielleicht hat der colorpicker ja schon eine chance bevor du die beiden schnittstellen baust.

gruss
  andre

[justme1968]

noch eine idee...

wie wäre es wenn man devStateIcon analog zu stateFormat so erweitert das perl code erlaubt ist um dynamisch anhand von farben oder dimstufen zu bestimmen was als icon in der web seite eingebettet wird. das muß dann auch nicht mehr unbedingt ein wirkliches icon sein sondern z.b. einfach ein html element dessen füllfarbe farbe/helligkeit was auch immer durch readings gesteuert wird.

z.b. etwas in der art:

Code Auswählen Erweitern

attr devStateIcon {'<div style="width:32;height:32;background-color:'. ReadingsVal($name,...) .'#F00;"></div>'}

gruss
  andre

[rudolfkoenig]

> attr devStateIcon {'<div

Habs genauso eingebaut und dokumentiert.
Achtung: im Detailansicht kann man ; direkt eingeben, im fhem.cfg muss man dasselbe als ;; schreiben. Und 32 sollte 32px heissen.

[rudolfkoenig]

> anbei zwei kleine patches

gefaellt mir nicht sehr gut, weil es immer versucht jscolor.js zu laden.

Ich schlage vor auf die generische Methode zu warten, oder es mit dem o.g. devStateIcon Feature zu loesen :)

[justme1968]

klasse. das mit dem devStateIcon variante werde ich probieren. das löst aber nur ein teil des problems. ich kann den aktuellen status anzeigen.
ich kann aber nicht etwas einstellen ohne das jscolor.js geladen ist. und es ermöglicht mir nur einen parameter einzustellen.

die andere möglichkeit würde ich gerne trozdem weiter verfolgen. zumal es damit möglich ist mehr als einen parameter zu editieren (zumindest sobald die beschränkung das es nur ein spezial element und nur am anfang der webCmd liste geben darf aufgehoben ist) und es zum anderen unschön ist die status anzeige im icon und das setzen eines paramters zu mischen.

wenn das einzige was dich stört ist das jscolor.js immer geladen wird lass uns einen weg finden jscolor.js nur zu laden wenn es benötigt wird. wie wäre es mit etwas in der art in fhemweb.js:

Code Auswählen Erweitern

function loadjsfile(filename){
  var script=document.createElement('script');
  script.setAttribute("type","text/javascript");
  script.setAttribute("src", filename);
  document.getElementsByTagName("head")[0].appendChild(script);
 } und im patch muß nur an der stelle wo der colorpicker verwendet wird das jscolor dynmisch geladen werden.

Code Auswählen Erweitern

<script type="text/javascript">
loadScript("jscolor/jscolor.js");
</script>

das ist jetzt auf dem trockenen hingeschrieben. ich werde es mal testen. ist das dynamisch laden eine alternative für dich?

gruss
  andre

[justme1968]

den status mit dem neuen devStateIcon anzuzeigen funktioniert sehr gut.

aber natürlich sind mir noch ein paar dinge aufgefallen:

- ich komme anders als beim stateFormat nicht mit $name an den namen des devices. das wäre aber schön um eine generische version zu verwenden die dann auch gegen rename geschützt ist.

- was muss ich tun damit der perl code neu ausgeführt wird wenn sich am device etwas ändert? also analog zur icon änderung per longpoll.

- beim reload 01_FHEMWEB sind  hinterher keine icons da. die müßen extra mit rereadicons geladen werden.

gruss
  andre

[justme1968]

das mit dem loadscript war viel zu kompliziert gedacht.

ich kann es ja auch einfach an der stelle laden wo das text feld für den colorpicker dargestellt wird. anbei eine neue version des patches die ohne das globale laden auskommt.

spricht etwas dagegen die sonderbehandlung für den slider und auch für den colorpicker nicht nur dann zu machen wenn sie an erster stelle im webCmd stehen? ich denke die bedienbarkeit würde stark gewinnen wenn man an erster stelle noch ein toggle setzen könnte. dann würde der klick auf die icons immer vernünftig funktionieren und nicht nur wenn webCmd nicht gesetzt ist.

gruss
  andre

[justme1968]

noch eine idee...

wenn du nicht magst das fhemweb für so eine spezielle sache gepatcht wird waere vielleicht eine alternative wie bei devStateIcon die attribut definition zu erweitern. entweder in dem code erlaubt wird oder in dem ein kommando mit der :-syntax wie in der set set list erlaubt wird und dann eine HTML-Fn im modul aufgerufen wird. also so

Code Auswählen Erweitern

attr webCmd toggle:{getHTML($name,"colorpicker")}:on:off oder  

Code Auswählen Erweitern

attr webCmd toggle:(rgb:colorpicker:RGB):on:off:(pct:slider:0:1:100) die syntax für letzteres ist noch nicht so schön aber vielleicht hast du ja eine bessere idee was mit den : auf zweiter ebene zu tun ist.

vielleicht ist dieser vorschlag auch einfach und generell genug als  allgemeine lösung wie sie die dir vorschwebt.

gruss
  andre

ps: mit der neuen devStateIcon version habe ich gestern noch ein dynamiches rolladen icon gebastelt. das funktioniert sehr gut.

[rudolfkoenig]

Ich fürchte diese Idee ist noch nicht ausgereift.

Aus jedem Element der webCmd Liste wird ein Link (<a>) generiert, mit dem Element als Name und mit "cmd=set $d Element" als Link. Ich kann weder Name noch Befehl aus deinen Beispielen ableiten.

[justme1968]

das kommt darauf an was du automtisch generieren möchtest und was im code gemacht wird.

in dem beispiel  hätte ich alles inklusive dem cmd generiert weil ich die flexibilität beim colorpicker brauche weil hier nicht bei onClick sondern onChange reagieren muss. d.h. ich würde gerne den kompletten div erzeugen können wie ich es in meinem patch für den colorpicker eingebaut habe. ich muss also so etwas einfügen können und:

Code Auswählen Erweitern

<td colspan='2'>
  <script type='text/javascript' src='$FW_ME/jscolor/jscolor.js'></script>
  <input class='color {pickerMode:'$mode'}' value='#$cv' onchange='setColor(this,\"$mode\",$c)'\"/>
</td>
stell dir mal vor wie es aussehen müsste wenn du den slider nicht per sonderbehandlung im 01_FHEMWEB.pl erzeugst sondern komlett per webCmd code.

das könnte man unterstützen in dem man funktionen bereit stellt um bestimmte einfache szenarien zu unterstützen.
den punkt "ich komme anders als beim stateFormat nicht mit $name an den namen des devices. das wäre aber schön um eine generische version zu verwenden die dann auch gegen rename geschützt ist." von weiter oben aus dem devStateIcon sollte man hier natürlich auch unterstützen.

wenn du ein paar minuten zeit hast schau dir doch mal an wie ich in 31_HUEDevide.pl im 'get devStateIcon' gemacht habe.  da erzeuge ich z.b. für manche zustände genau das was normalerweise als icon generiert wird und für andere meine farbige markierung.



gruss
  andre

[justme1968]

ich habe eben bemerkt das das neue devStateIcon feature in der smallscreen version noch nicht geht.

muss ich beim verwenden noch etwas berücksichtigen oder du beim zusammenbauen der seite?

[rudolfkoenig]

>  ich habe eben bemerkt das das neue devStateIcon feature in der smallscreen version noch nicht geht.

Stimmt nicht, bei mir tut es. Oder anders: ab wannn werden endlich meine bitten erhoert, und man liefert mir eine genaue Fehlermeldung samt fhem.cfg & genaue Beschreibung?

[justme1968]

die frage war nicht mit dem gedanken verbunden das du einen fehler reproduzieren oder suchen sollst sondern damit das ich mich selber auf die suche mache wenn du sagst es geht. ich hab das problem inzwischen gefunden und behoben.

[justme1968]

aber um auf das eigentliche thema zurueck zu kommen: den colorpicker und die möglichkeit webCmd zu erweitern.

die flexibilität mit dem neuen devStateIcon feature gefällt mir so gut das es mir inzwischen viel lieber wäre webCmd in der gleichen art zu erweitern statt mit dem colorpicker patch einen neuen sonderfall wie analog zum slider einzubauen. mit einer allgemeinen lösung kann ich z.b. auch farbige presets in der cmd liste anzeigen oder icons für die rolladen zustände statt nur text zum anklicken oder, oder, ....

das ziel ist z.b. etwas in dieser art darstellen zu können:(siehe Anhang / see attachement)
wobei ein klick auf das grosse farbige textfeld den colorpicker startet, ein klick auf die kleinen farbigen felder direkt die farbe setzt.

ich weiss nicht welches vorgehen du bevorzugst um das thema weiter zu besprechen. also hier nochmal zusammengefasst aus den bisherigen posts als grundlage zum weiterdiskutieren:

• es wäre schön wenn die einschränkung das ein interaktives element nur einmal und nur am anfang der liste sein darf weg fällt
• die syntax könnte so aussehen:

Code Auswählen Erweitern

attr webCmd toggle:on:off:pct:{...}:{...}:{...}

bei interaktiven elementen (also nicht nur ein bildchen zu anklicken) muß auch die aktion im code erzeugt werden können und nicht durch den default im fhemweb vorgegeben werden. ich brauche z.b. ein onchange. etwas wie das hier:

Code Auswählen Erweitern

<td colspan='2'>
  <script type='text/javascript' src='$FW_ME/jscolor/jscolor.js'></script>
  <input class='color {pickerMode:'$mode'}' value='#$cv' onchange='setColor(this,\"$mode\",$c)'\"/>
</td> soll also im web interface als ein element in der liste der anklickbaren kommandos erscheinen können.

es wäre schön wenn die einfachen fälle durch ein paar perl hilfsfunktionen unterstützt werden kann:

• eine funktion die aus einem text und gewünschem kommando den default html text für ein element zusammenbaut (textCmd($text,$cmd))
• das gleiche mit einem icon statt text. (iconCmd($icon_name, $cmd)). mit beidem könte man dann so etwas machen:

Code Auswählen Erweitern

attr webCmd {iconCmd("shutterOpen","up")}:{iconCmd("shutterHalfOpen","50")}:{iconCmd("shutterClosed","down")} das wäre die version bei der du den befehl ableiten und automatisch erzeugen kannst.

dynamisch laden von javascript. das geht zwar direkt im code. mit einer hilfsfunktion könnte man aber verhindern das bei mehreren gleichen devices im raum der gleiche code immer wieder bei jedem device geladen wird. z.b. mit einem loadScript(...) das den nötigen html text zurückliefert um das script zu laden oder nichts wenn genau dieses script auf der seite schon geladen ist.[/list]

es sollte möglich sein im code zumindetst den device namen abzufragen (bei devStateIcon und bei webCmd) um den code nicht für jedes device anpassen zu müssen und keine probleme beim rename zu bekommen.

gibt es eigentlich ausser CommandGet eine funktion um direkt aus perl ein get auf ein device zu machen? analog zu Value bzw ReadingsVal und AttrVal?

können wie eine möglichkeit schaffen das kommando bei click das devStateIcon zu konfigurieren ohne es in der liste auftauchen zu lassen?
bei lampen ist es fast immer ein toggle. in der liste ist es aber redundant. vielleicht optional mit '#' als suffix bei devStateIcon angehängt und bei jedem eintrag aus der webCmd liste. bei nicht vorhanden alles wie bisher per default, bei vorhanden und leer wird nichts automatisch erzeugt und der code ist selber dafür verantwortlich.[/list]
alternativ und kurzfristig steht die letzte version meins colorpicker patches natürlich immer noch als einfache option zur verfügung :)

das ist länger geworden als beabsichtig und ich hoffe du fühlst dich nicht überfahren.

gruss
  andre

[rudolfkoenig]

- devStateIcon/webCmd ist nur(!) fuer den Benutzer gedacht, nicht fuer den Modul-Autor. Das colorpicker fuer den HUE sollte nicht ueber devStateIcon/webCmd geloest werden, sondern ueber eine FHEMWEB->Modul Schnittstelle. Ich hoffe dass Du noch ein bisschen Geduld aufbringen kannst.

- damit webCmd in deinem Sinne erweiterbar ist, muesste jedes {} ein Paerchen zurueckliefern: erster Teil ist fuer die Darstellung (Bild/Text/etc) verantwortlich, das Zweite fuer das auszufuehrende Kommando. Ich meine das ist fuer einen normalen Benutzer reichlich kompliziert, und loest nicht mal alle Probleme.

- was passt Dir an CommandGet nicht?

[justme1968]

- ich benutze devStateIcon nicht wirklich direkt. ich habe in meinem modul eine get das eine passendes icon generieren kann. wenn der benutzer es verwenden möchte kann er das. muss aber nicht. ich erleichtere ihm die konfiguration in dem ich bei neu angelegten devices einen vernünftigen default eintrage. es wird nur verwendet um den augenblicklichen device state anzuzeigen. ich denke das ist ein vorgehen das sehr elegant und transparent ist und mit minimalem aufwand alle beteiligten glücklich macht. wenn du der meinung bist diese vorgehensweise ist nicht die richtige ist bitte ich dich um einen besseren vorschlag und gebe zu bedenken das es noch eine zusätzliche schnittstelle bedeutet die meines erachtens hier nicht nötig ist weil es mit diesem einen mechanismus wirklich einfach und gut funktioniert einen default vorzugeben, dem benutzer zu zeigen was geht und ihm trotzdem freie hand zu lassen es zu ändern.

- ich glaube wir reden aneinander vorbei. ein einzelner {} ausdruck soll schlicht und einfach immer nur den html code zurück geben der für das element nötig ist genau so wie es bei devStateIcon auch geht. das ist der teil den ich brauche und er so zu sagen alles löst. selbst wenn es nicht die 100% lösung ist denke ich wir kommen damit sehr nah an die 99%. um das für den normalen benutzer einfacher zu machen gibt es hierzu zwei ergänzungen. die erste ist ein optionales #cmd hinter dem {} ausdruck für das kommando. die zweite ein paar perl Funktionen die man verwenden kann und die das kommando ergänzen. das ist die möglichkeit die ich mit iconCmd($icon_name, $cmd) andeuten wollte. von den xxxCmd hilfunktionen kann es dann ein paar geben. textCmd, iconCmd, htmlCmd jeweils mit einem parameter für den teil der sichtbar sein soll und einem parameter für das kommando. wie im beispiel unten schon gezeigt würde ein webCmd mit drei icons um einen rolladen in drei zusände zu fahren so aussehen: attr webCmd {iconCmd("shutterOpen","up")}:{iconCmd("shutterHalfOpen","50")}:{iconCmd("shutterClosed","down")} ich glaube das ist auch für einen normalen anwender der sonst mit fhem klar kommt zu bewältigen. zumal es nichts ist was er benutzen muß sonder benutzen kann wenn er mit der alten Methode an grenzen stößt. auf der anderen seite wäre das Konzept dann für stateFormat, devStateIcon und webCmd im prinzip gleich und auch das würde es einfacher machen es schrittweise zu erklären. auch wenn webCmd für den anwender ist kann ein modul autor hilfsfunktionen bereitstellen um eine oder mehrere von den {} sinnvoll zu füllen.

- ich habe kein problem damit. die syntax ist nur anders als bei Value bzw ReadingsVal und AttrVal und ganz persönlich finde ich es schöner wenn ähnliches auch ähnlich ausschaut und ähnlich funktioniert.

geduld sicher wenn es sein muß. ich finde nur die lösung die ich hier und in dem post vorher skizziert habe sehr elegant und flexibel weil sie ganz ohne komplizierte schnittstellen alle möglichkeiten offen läßt und doch mit ein paar einfachen hilfsfunktionen so einfach gemacht werden kann das sie jeder benutzen kann. auch haben modulautoren und endanwender die gleiche schnittstelle. das sehe ich als großen vorteil. weil eine einzige flexible schnittstelle von mehr benutzern verwendet wird statt unterschiedliche eingeschränkte schnittstellen von jeweils wenigen.

es ist deine software und du hast mehr erfahrung und mehr übersicht über das ganze. ich kann also nicht verlangen das du deinen weg für eine modulschnittstelle jetzt schon vorstellst. und es wäre eingebildet wenn ich sage ich kann mir nicht vorstellen wie sie für diesen anwendungsfall web interface besser und einfacher sein soll. aber interessieren würde es mich schon :)

[rudolfkoenig]

> ich finde nur die lösung die ich hier und in dem post vorher skizziert habe sehr elegant und flexibel

Leider verstehe ich es immer noch nicht wirklich, bzw. das was ich verstehe, ich nicht vollstaendig und schon gar nicht elegant finde. MAn. ist dem Benutzer nicht zuzumuten, dass er nach der Definition eines Geraetes ein webCmd nach obigen Muster definiert, damit er ein slider/colorpicker/etc hinkriegt, das muss deutlich einfacher sein, oder im Modul automatisch passieren.

Kannst Du bitte konkret hinschreiben, was {iconCmd("shutterClosed","down")} zurueckliefern soll?
Vielleicht verstehe ich dein Konzept dann eher.

[justme1968]

das beispiel mit mit dem iconCmd ist fast ganz unten. alles vorher der versuch noch mal meinen gedankengang zu erklären.

die grund idee ist das ganz genau so wie beim devStateIcon ein {} ausdruck für einen kleinen rechteckigen bereich auf dem bildschirm zusändig ist.

es tut mir leid das es schon wieder so lang geworden ist. vielleicht gilt es gerade für die einfachsten ideen das das sie einfach zu bedienen und zu zeigen aber schwierig zu beschreiben sind. vielleicht auch weil ich sehe das sich ganz unterschiedliche anwendungfällle abdecken lassen und jeder einzelne für sich ganz einfach ist aber die gesamtheit einfach durch ihre menge 'erschlägt'. der colorpicker an sich ist mit einem einzigen {colorPicker("rgb")} eingebaut. das ist nur der name des interaktions items und der name des kommandos auf das es sich beziehen soll. und letzteres könnte man im einfachen fall sogar weg lassen. einfacher geht es glaube ich nicht mehr.

das elegante ist das es für stateFormat, devStateIcon und webCmd der gleiche mechanismus mit der gleichen syntax ist. der mechanismus ist so flexibel das er von einem einfachen inline funktionsaufruf bis hin zum beliebig komplexen perl code alles erlaubt. es ist die gleiche schnittstelle für entwickler und benutzer und der eine kann dem anderen mit hilfsfunktionen unterstützen und defaults liefern. nichts von dem code der hier gezeigt wird muß vom endbenutzer geschrieben werden. kann es aber in den unterscheidichsten komplexitätsstufen wenn er es möchte.

als beispiel vielleicht noch mal einen schritt zurück zum devStateIcon und wie ich es gerade verwende:

• ich habe ein 'get devStateIcon' implementiert das ein icon zurück liefert das ich als modul autor für sinnvoll erachte den device zustand darzustellen. in meinem konkreten fall schaut der code dazu zur zeit so aus:

Code Auswählen Erweitern

 } elsif ( $cmd eq "devStateIcon" ) {
    return '<div id="'.$name.'" align="center" class="col2">'.
           '<img src="/fhem/icons/off" alt="off" title="off">'.
           '</div>' if( ReadingsVal($name,"state","off") eq "off" | ReadingsVal($name,"bri","0") eq 0 );
                         
    return '<div id="'.$name.'" align="center" class="col2">'.
           '<img src="/fhem/icons/'.$hash->{STATE}.'" alt="'.$hash->{STATE}.'" title="'.$hash->{STATE}.'">'.
           '</div>' if( AttrVal($hash->{NAME}, "model", "") eq "LWL001" );
                         
    return '<div id="'.$name.'" class="block" style="width:32px;height:19px;'.
           'border:1px solid #fff;border-radius:8px;background-color:#'.CommandGet("","$name rgb").';"></div>';
  }d.h. für den fall 'aus' verwende ich das normale fhem aus icon wobei ich den sonderfall das das device an ist aber die helligkeit 0 hat auch berücksichtige, für den fall das mein device eine weiße lampe ist verwende ich das normale fhem icon für gedimmte lampen und für den fall das es eine farbige lampe ist liefere ich ein div mit der passenden farbe. hier möchte ich in zukunft ein icon verwenden das ich mit einer hintergrund farbe füllen kann.

wenn der benutzer kein attribut devStateIcon gesetzt hat initialisiere ich es mit

Code Auswählen Erweitern

attr devStateIcon {CommandGet("", $name." devStateIcon")}d.h. es wird meine 'hilfsfunktion' get devStateIcon verwendet. der benutzer kann es aber jeder zeit überschreiben. (hier ist auch der grund warum eine etwas andere syntax für das get aus perl code 'schöner' aussehen würde.)[/list] die idee ist das der modul entwickler dem endbenutzer über hilfsfunktionen neue elemente bereit stellen kann die er in der für den endbenutzer vorgesehenen schnittstelle verwenden kann. das er diese auch per default setzen kann und der endbenutzer sich um nichts kümmern braucht wenn er nicht will.


jetzt den schritt weiter zu webCmd: webCmd ist zur zeit ist das nur die text liste aus kommandos und die beiden ausnahmen slider und time die auch nur an erster stelle stehen dürfen.

die idee ist nun diese liste von kommandos als liste von boxen,divs oder was auch immer anzusehen die jeweils mit dem ergebnis aus einem {} gefüllt werden können. was in dem {} zurück geliefert wird ist genau so wie beim devStateIcon völlig frei.

das ganze jetzt mit dem beispiel collorpicker:
ich möchte als modul author dem endanwender die möglichkeit geben in der web oberfläche farben interaktiv einzustellen oder aus einer liste mit farben auszuwählen. das mache ich in dem ich dem endanwender zwei hilfsfunktionen bereit stelle die den html code dafür generieren. wie bei devStateIcon initialisiere ich als modul autor die webCmd liste auf einen default der so aussehen könnte:

Code Auswählen Erweitern

attr webCmd toggle:{pickColor($name,"rgb")}:{selectColor($name,"rgb","ff0000"}{selectColor($name,"rgb","00ff00"}den ich für sinnvoll erachte. der benutzer hat aber jeder zeit die möglichkeit den default zu überschreiben und er kann sehen wie es geht.

• also modul autor baue ich eine hilfsfunktion pickColor($name,$cmd) die es dem endbenutzer erlaubt den colorpicker in diese liste von boxen einzufügen. genau so wie es die sonderbehandlung von slider und time jetzt erlaubt und es der colorpicker patch von oben erlauben würde. mit dem unterschied das es eben nicht in 01_FHEMWEB als sonderfall codiert ist sondern den generellen {} mechanismus den ich vorschlage nutzt.
  

Code Auswählen Erweitern

...
my $c = "\"$FW_ME?cmd=set $d $cmd %$srf\"";
return "<td colspan='2'>".  
            "<script type='text/javascript' src='$FW_ME/jscolor/jscolor.js'></script>".
            "<input class='color value='#$cv' onchange='setColor(this,$c)'\"/>".
          "</td>";

die zweite hilfsfunktion wäre selectColor($name,$cmd,$value) die einfach ein farbige kästchen darstellt und bei klick auf eine angegebene farbe wechselt

Code Auswählen Erweitern

...
my $c = "\"$FW_ME?cmd=set $d $cmd $value$srf\"";
return '<div id="'.$name.'" class="block" style="width:32px;height:19px;'.
           'border:1px solid #fff;border-radius:8px;background-color:#'.$value.'; onclick='setColor(this,$c)"></div>';[/list]
wenn ich an der stelle wo der {} ausdruck ausgewertet wird an $name komme muß er nicht übergeben werden und die aufrufe sehen noch einfacher aus: pickColor("rgb") und selectColor("rgb","ff0000"). das rgb könnte ich als modulautor auch noch weg fallen lassen wenn es der einzige parameter ist der auf diese art verstellbar ist.


fhem könnte jetzt mit hilfsfunktionen ausgeliefert werden von der eine statt dem text des kommandos wie es bisher ist auch ein icon erlaubt. webCmdIcon($name,$icon_name,$cmd):

Code Auswählen Erweitern

...
return '<a href="/fhem?cmd.$name=set $name $cmd$srf">'.
          '<div id="$name" class="col3"><img src="/fhem/icons/$icon_name" alt="$cmd" title="$cmd"></div>'
          '</a>'
das ist genau der html code der zur zeit für ein text element in der cmd liste tabelle generiert wird nur mit einem icon statt dem text. wenn zum zeitpunkt an dem das {} ausgewertet wird $name gesetzt ist kann man wieder darauf verzichten und es vereinfacht sich in webCmd($icon_name,$cmd). es würde also so aussehen es zu verwenden:

Code Auswählen Erweitern

attr device webCmd {webCmdIcon("shutterDown","down")}:{webCmdIcon("shutterHalf","50")}:{webCmdIcon("shutterUp","up")}
eine weitere hilfsfunktion könnte webCmdSlider(...) sein die den bisherigen sonderfall slider ersetzt oder ergänzt und es erlauben würde einen slider für jedes beliebige set z.b. auch in einem dummy zu verwenden und nicht mehr den erlaubten wertebereich mit der art der interaktion in der der cmd liste vermischt sondern es erlaubt das interaktionselement auszutauschen ohne am modulcode etwas zu ändern.

all der code wird im normal fall nicht von endbenutzer sonder vom modulautor geschrieben und mitgeliefert. er kann damit webStateCmd auf einen für ihn sinnvollen wert initialisieren. jeder benutzer kann aber diese initialisierung überschreiben. er kann aber auch wenn er etwas erfahrere ist selber funktionen schreiben und mit dem gleichen mechanismus einbinden. und zwar auch gemischt und in verbindung mit den vorhanden  hilfsfunktionen.

die #cmd ergänzung würde es erlauben nur den code zum html generieren zu schreiben und den teil der das commando ausfürt weiter zu automatisch zu erzeugen. vorallem könnte man dem devStateIcon ein  kommando mit geben ohne das erste in der webCmd liste zu 'mißbrauchen'.

gruss
  andre

[rudolfkoenig]

> es tut mir leid das es schon wieder so lang geworden ist

und ich will das ich auch nicht ermutigen, solche Aufgaben tendieren bei mir leicht auf spaeter geschoben zu werden.


> attr device webCmd {webCmdIcon("shutterDown","down")}:...

Das ist ein Konzept, den ich so nicht unterstuetzen will, diese Schnittstelle sollte dem Benutzer nicht so transparent gemacht werden. Weiterhin meine ich, dass der Benutzer ein slider/colorpicker/etc nur durch Definition des Geraetes bekommen soll, ich denke dabei auch an autocreate.

Ich apelliere nochmal an deinem Geduld.

[justme1968]

ich sehe nicht das irgendeine häßliche oder interne schnittstelle transparent gemacht wird. es ist die möglichkeit beliebigen perl code zu verwenden um ein kleines kästchen im user interface zu füllen. es ist absolut simpel und funktioniert überall genau identisch.

der colorpicker und der slider ist aber gerade das beste beispiel das es eine abstrakte interaktion für bestimmte werte ist die nicht auf ein gerät beschränkt sein sollte sondern eben ganz im gegenteil für jedes gerät gleich funktionieren soll. stell dir mal vor jedes gerät würde seine eigenen slider mit bringen... idealer weise würde das ganze an den interfaaces hängen und der benutzer sagt alles was helligkeit ist möchte ich mit gui element xy einstellen. ich sehen z.b. auch nicht warum es verboten sein sollte den color picker z.b. auch für einen dummy oder eine structure zu verwenden.

der apell an meine geduld mit der einleitung das es auf die lange bank geschoben wird ist hoffentlich nicht das was ich jetzt mit nehmen soll :)

es soll nicht der eindruck entstehen das ich nach dem kleinen finger (devStateIcon) jetzt den ganzen arm will. ich habe nur das gefühl das es eine schöne lösung ist die mit sehr wenig aufwand sehr viel ermöglicht. also höchstens noch ein zweiter finger :)

[justme1968]

ganz ohne ungeduld...

in der bisherigen diskussion nur am rande gestreift war die idee direkt konfigurieren zu können welches set beim klick auf das icon ausgeführt wird und nicht das erste aus der webCmd liste zu verwenden.

das hätte den vorteil nicht überall toggle in die liste schreiben zu müßen und damit den pct slider zu verlieren.

falls du das unabhängig von der anderen webCmd diskussion angehen magst würde ich gerne '#cmd' als suffix hinter jeder möglichen icon definition vorschlagen. also z.b.

Code Auswählen Erweitern

attr lampe devStateIcon an:on#off aus:off#on oder

Code Auswählen Erweitern

attr rolladen devStateIcon {...}#toggleoder auch  

Code Auswählen Erweitern

attr dimmer devStateIcon #toggle um das standard icon zu verwenden aber beim klick toggle zu bekommen um dann im webCmd an erster stelle den pct slider haben zu können.

gruss
  andre

[rudolfkoenig]

Deine Idee finde ich grundsaetzlch gut, wuerde allerdings kleine Aenderungen vorschlagen:
- keinen neuen Trenner (: statt #)
- {} liefert optional 2 Werte zurueck.

Bleibt die Inkompatibilitaet mit webCmd. Hast Du auch eine Idee, wie man die Altanwender besaenftigen koennte?

[justme1968]

der trenner an sich ist mir im prinzip egal. ich fände es aber besser nicht den gleichen ':' trenner zu verwenden wie bei webCmd. dort wird zwischen 'gleichen' dingen getrennt. hier zwischen zwei dingen die unterschiedlich sind aber zusammengehören. und falls etwas ähnliches später noch für webCmd in frage kommt wäre das nicht mehr möglich mit dem gleichen trenner.

optional zwei werte zurueck zu liefern finde ich gut. aber ich würde es nur optional machen und dem per trenner angehängten kommando den vorrang geben.

welche inkompatibilität meins du? man müßte ja das kommando explizit mit #xxx dran hängen damit es da ist. wenn es nicht gesetzt wird würde ich das verhalten so lassen wie es bis jetzt ist.

[rudolfkoenig]

Das ist wohl aufwendiger gewesen als gedacht, ich bitte euch das angehaengte Patch zu testen, bevor ich es einchecke.

- devStateIcon hat jetzt drei : getrennte Felder, das 2. und 3. ist optional. Das 2. definiert wie bisher das angezeigte Bild (falls gesetzt), das 3. (neu) wie gewuenscht das Befehl, was beim clicken ausgeloest wird.
- falls devStateIcon als {} definiert wurde, dann kann die Routine optional einen zweiten Wert (Befehl) zurueckliefern
- cmd ist sowas wie on/off/toggle, und wird zu "set $d $cmd" ergaenzt
- da ich beim Umbau war: webcmd bestimmt ab sofort nicht mehr was beim Click auf das Icon passiert, das ist die Aufgabe von devStateIcon.
- Problem: falls devStateIcon mit {} gesetzt ist, dann funktioniert kein "GET /fhem/icons/DEVNAME" mehr, da dieser normalerweise ein Bild zurueckliefert. Das ist auch im aktuell eingecheckten Code der Fall. Eigentlich muesste ich das {} aus devStateIcon wieder entfernen, aber da gibt es bestimmt Protest.

Beispiel:
attr DEV devStateIcon on::AI off::A0

[justme1968]

- die funktionalität die ich mir gewünscht habe ist komplett da. alles was ich bis jetzt getestet habe funktioniert.

- ich war davon ausgegangen das die {} auch überall erlaubt sind wo icon_name erlaubt ist. das habe ich aber nie gesagt und es ist für mich auch so ok. ich kann alles machen was ich brauche.

- ein vorschlag zur erweiterung: die {} doch zusätzlich an stelle des icon namen zu ermöglichen, aber dort als rückgabe nur einen string erlauben und diesen als icon namen verwenden. damit könnte man dynamisch die ganzen xxx% heizungs icons zurückgeben one zeilenweise werte zu mappen.

- es gibt noch ein paar fälle wo das parsen noch nicht funktioniert und fhem abstürzt. z.b. wenn ich wie ich anfangs dachte ':{...}:toggle' als devStateIcon verwende. (der fehler ist: 'Unmatched ) in regex; marked by <-- HERE in m/^devStateIcon") <-- HERE }$/ at /usr/local/FHEM/share/fhem/FHEM/01_FHEMWEB.pm line 2292.'). ich habe zwar gegen eine ältere fhemweb version gepatched weil ich meine colorpicker änderungen drin habe, aber ich denke nicht das es daran liegt.

- zum 'GET /fhem/icons/DEVNAME' problem: bitte den {} teil auf keinen fall entfernen :) um die farbe und helligkeit im icon darzustellen ist es völlig unmöglich fertige icons vorzubereiten und verwenden. es wären einfach zu viele. wäre es eine option in diesem fall beim get als fallback das icon zurück zu liefern das fhem verwenden würde wenn kein devStateIcon gesetzt ist? also das normale on/off icon?

nochmal danke und ich hoffe wir finden für den colorpicker und die möglichkeit im webCmd auch farben und icons zu verwenden oder  mehr als einen slider an erster stelle auch noch eine lösung.

[rudolfkoenig]

>  - die funktionalität die ich mir gewünscht habe ist komplett da.

Gut, hab die Aenderungen eingecheckt.


> ein vorschlag zur erweiterung: die {} doch zusätzlich an stelle des icon namen zu ermöglichen

Abgelehnt. Wer hacken will, der kann es auch jetzt, soll das Bild halt mit <img> zurueckliefern.


> fhem abstürzt ... wenn ich ... ':{...}:toggle' als devStateIcon verwende.

Hab nie gesagt, dass das erste Parameter auch optional sein darf, haengt auch nicht mit dem gestrigen Aenderungen zusammen. Will es erstmal nicht abfangen, weil ich glaube, dass ein zusaetzliches eval es zu stark verlangsamt. Wenn viele darauf reinfallen, dann werde ich es einbauen, das Leerstring habe ich jetzt abgefangen.

> wäre es eine option in diesem fall beim get als fallback das icon zurück zu liefern das fhem verwenden würde wenn kein devStateIcon gesetzt ist?

Ja, ich warte es aber ab ob es notwendig ist, und jemanden stoert :)

Und jetzt muss ich die Aenderungen noch in dem anderen Forum beichten: webCmd tut nicht mehr wie bisher...

[justme1968]

inzwischen gibt es ein paar interessenten mehr für den colorpicker.

gibt es von der lösung die dir vorschwebt schon etwas neues? kann ich irgendetwas tun dir dabei zu helfen ?

gruss
  andre

[rudolfkoenig]

Bitte noch eine Woche (bis nach Version 5.4) warten, danach gehen wir das Thema an.

Folgendes muss beachtet werden:
- ein Modul soll status im Raum-Ansicht (als html) definieren koennen
- ein Modul soll im Detail-Ansicht ein Bereich selbst gestalten koennen
- einzelne Befehle sollten (vom Benutzer konfigurierbar) mit unterschiedlichen Widgets dargestellt werden koennen (slider/time/colorpicker/etc), diese sollten nicht in FHEMWEB.pl sondern in externen Module(en?) implementiert werden.
- das Laden von notwendigen Javascripten muss geloest werden.

[justme1968]

das klingt sehr gut.

danke
  andre

[justme1968]

ich habe gerade gesehen das du etwas in der richtung eingecheckt hast. ist das schon in einem zustand das ist es verwenden kann/darf?

[rudolfkoenig]

Siehe http://forum.fhem.de/index.php?t=msg&goto=74762&rid=8#msg_74762

[justme1968]

klasse!

ich habe zwar gerade meine panStamps bekommen und baue das protokoll in fhem ein aber den colorpicker mache ich trozdem noch schnell fertig.

[justme1968]

und kaum geht das eine kommt schon der nächste wunsch...

es wäre gut wenn bei parametrisierten kommandos in webCmd diese parameter auch an webCmdFn durchgereicht würden.

wenn du dir diesen screenshot http://forum.fhem.de/index.php?t=getfile&id=2115&private=0 anschaust sind neben dem colorpicker noch mal drei bunte knöpfe in rot grün und blau. die sollen bei einem klick direkt auf die jeweilige farbe springen. welche farben konkret in der liste erscheinen würde ich gerne dem anwender überlassen. d.h. er sollte etwas in der art

Code Auswählen Erweitern

webCmd rgb:color ff0000:color 00ff00:color 0000ff verwenden können.

zur zeit würde aber 'color ff0000' nicht als gültiges color set in der allSets liste gematched. ich denke es würde schon reichen an dieser einen stelle (zeile 1079 in 01_FHEMWEB) nicht das ganze $cmd sondern nur bis zum etwaigen ersten leerzeichen zu matchen und trozdem das ganze commando inklusive der parameter an die webCmdFn zu übergeben. das splitten in die paramter kann ja dann dort passieren wenn es gewünscht wird. also etwa so:

Code Auswählen Erweitern

1079           my @c = split(' ', $cmd);
1080           if($allSets && $allSets =~ m/$c[0]:([^ ]*)/) {
im slider müsste man dann natürlich umgekehrt den slider nur einblenden wenn kein parameter angegeben ist und sonst wie bisher 'pct xxx' als text darstellen.

[rudolfkoenig]

Alles so eingecheckt, wie Du das haben wolltest, bzw. was ich davon verstanden habe :)

[justme1968]

von meiner seite funktioniert es wie ich es mir vorgestellt habe.

für den slider braucht es aber noch eine kleine änderung. es reicht nicht undef zurück zu geben sondern es muss wirklich html code mit '<a href...' und dem jeweiligen commando erzeugt werden. sonst wird z.b. 'pct 10' als auswahl interpretiert und im web zu einer combobox mit den slider parametern statt 'pct 10' als text zum anklicken.

[rudolfkoenig]

Danke fuer den Hinweis, hat eine leichte Aenderung der Interface zur Folge:
Falls webCmdFn undef zurueckliefert, wird weiter nach einem webCmfFn gesucht (wie bisher)
Falls webCmdFn einen leeren String ("") zurueckliefert, dann wird das Kommando als Link dargestellt.