Wifilight.pm

[herrmannj]

Hi Sandra,

ich hab mir einige milights aus china auf Vorrat bestellt, eine ist bei mir auch schon in das walhalla eingezogen .

Vielen Dank für den Suche beim colorpicker! Ich hab den "alten" (obwohl größte Baustelle - noch) drin weil ich die nächste Änderung dort gerne weitreichender hätte. Das Ziel ist es den jetzigen costum colorpicker/slider ganz aus dem modul raus zunehmen neue colorpicker/slider als einzelnes (virtuelle-) device darzustellen.  Warum ? Unterschiedliche device / display / skins! Die Wünsche an: "wie soll es aussehen" und "wie soll es sich bedienen lassen"  unterscheiden sich je nach device.

Meiner Meinung nach lässt sich das nicht mit einem "all-in-one" colorpicker/slider erschlagen- alleine schon wegen unterschiedlicher Dispalygrößen, Designwünsche, Maus/touchbedienung etc.

Der Vorschlag lautet so: der colorpicker/slider wird als eigenes (virtuelles) device realisiert und je nach Wunsch kann der user seinen favoriten in den jeweiligen Floorplan einbinden. In der Folge habe ich dann einen anderen Floorplan den ich auf dem Wecker darstelle als auf dem Tablet oder mobile.

Der colorpicker/slider ist dann die sichtbare Instanz in der oberfläche (basis floorplan) und das wifilight modul kümmert sich nur um die Ansteuerung / colorfades etc.

Technisch ist im Modul bereits vorbereitet das der Status (RGB, HSV, on/off) per event rausgegeben wird. Der cp (short colorpicker ) müsste diese events lesen und die bestehende fhem Schnittstelle (xhr -> js widget) bedienen. Wenn Du jetzt gerade dabei bist wäre das doch genau der richtige Zeitpunkt.

Bei den events müsste ich im Modul nacharbeiten (Beispiel on-for-timer / on-till etc). Benefit wäre auch das der cp auch gleich die hue's etc mit bedienen könnte (sollte). Die Realisierung auf diese Art ist (fast) genauso einfach aber flexibler wie das einbinden IN das modul - weil: wo der code steht ist am Ende ja egal.

Ich hoffe ich hab mich nicht zu kompliziert ausgedrückt   Bin da für alle Vorschläge offen !

vg jörg

[justme1968]

schau dir mal rudis konzept der widgets für fhemweb an. inzwischen kann man die zuordnung zwischen set kommando und zugehörigem widget auch konfigurieren. das erste deispiel ist das neue popup beim editieren des raum attributes.

ich denke es braucht kein eigenes device und notifys sondern die konfigurierbaren widgets reichen bzw sind noch besser.

damit geht auch das konfigurieren eines anderen colorpickers pro device oder web port.

gruss
  andre

ps: sie hues haben absichtlich keine kräftigen grün töne. dafür ist die weiß darstellung optimiert. in der gut welt sind die living colors leuchten für kräftige farben zuständig.

[Blackcat]

ich hab mir einige milights aus china auf Vorrat bestellt, eine ist bei mir auch schon in das walhalla eingezogen .

Ich glaube das sollte ich bei Wohnungswechsel (wahrscheinlich nächstes Jahr) auch tun

Meiner Meinung nach lässt sich das nicht mit einem "all-in-one" colorpicker/slider erschlagen- alleine schon wegen unterschiedlicher Dispalygrößen, Designwünsche, Maus/touchbedienung etc.

Der Vorschlag lautet so: der colorpicker/slider wird als eigenes (virtuelles) device realisiert und je nach Wunsch kann der user seinen favoriten in den jeweiligen Floorplan einbinden. In der Folge habe ich dann einen anderen Floorplan den ich auf dem Wecker darstelle als auf dem Tablet oder mobile.

klingt gut !

Technisch ist im Modul bereits vorbereitet das der Status (RGB, HSV, on/off) per event rausgegeben wird. Der cp (short colorpicker ) müsste diese events lesen und die bestehende fhem Schnittstelle (xhr -> js widget) bedienen. Wenn Du jetzt gerade dabei bist wäre das doch genau der richtige Zeitpunkt.

Das ist super, wenn du mir den Stand zukommenlassen kannst kann ich eine CP Funktion schreiben, die deine Parameter übernimmt und ausgibt.

Bei den events müsste ich im Modul nacharbeiten (Beispiel on-for-timer / on-till etc). Benefit wäre auch das der cp auch gleich die hue's etc mit bedienen könnte (sollte). Die Realisierung auf diese Art ist (fast) genauso einfach aber flexibler wie das einbinden IN das modul - weil: wo der code steht ist am Ende ja egal.

Die Hues haben bereits einen Colorpicker, leider ist der auf dem iPad nicht wirklich gut zu bedienen.


Ich habe die mein Experiment unten angehängt. WARNUNG: Ungetestet und nicht refactort!!!!
was noch fehlt:

Code Auswählen Erweitern

<link rel="stylesheet" media="screen" type="text/css" href="css/colorpicker.css" />
<script type="text/javascript" src="js/colorpicker.js"></script>

ps: sie hues haben absichtlich keine kräftigen grün töne. dafür ist die weiß darstellung optimiert. in der gut welt sind die living colors leuchten für kräftige farben zuständig.

nadann ist die Werbung mal wieder falsch (siehe Spot Hue 1.1. mit cyan farbenden Bulbs) :/

[justme1968]

was genau ist das problem mit dem colorpicker auf dem ipad? bei mir funktioniert es mit dem dark style problemlos.

ist eventuell nur der bereich zu klein? das liegt eventuell an der höheren auflösung der neuen ipads. das müsste man aber einfach reparieren können.


gruss
  andre

[Blackcat]

was genau ist das problem mit dem colorpicker auf dem ipad? bei mir funktioniert es mit dem dark style problemlos.
ist eventuell nur der bereich zu klein? das liegt eventuell an der höheren auflösung der neuen ipads. das müsste man aber einfach reparieren können.

Habe das iOS7 style und mir hüpft immer die save config leiste in den picker und zum Farben abstättigen muss man mehrmals daneben drücken. Ansonsten ist er zwar klein aber ok....
PS: iPad 4 (Retina) mit iOS 6.1.3 und über Safari Verknüpfung gestartet

[justme1968]

kannst du mal bitte einen anderen style (default und dark) probieren und schauen ob das verhalten damit anders ist?

und auch ob es bei dir einen unterschied macht ob du den tablet port oder den normalen web port verwendest.

gruss
  andre

[Blackcat]

kannst du mal bitte einen anderen style (default und dark) probieren und schauen ob das verhalten damit anders ist?

und auch ob es bei dir einen unterschied macht ob du den tablet port oder den normalen web port verwendest.

Leider nicht mehr, habe meine Lampen schon wieder weggepackt und aus fhem gelöscht :/
Habe aber den Tabletport genutzt und das iOS Tablet Skin (damit nicht immer ein neues Browserfenster geöffnet wird in der Verknüpfung)

PS: eine config mit ein paar nicht ansprechbaren lampen würde mir aber helfen zum testen (also fertige defines für brigde und devices) ... dann kann ich das Trocken testen

[justme1968]

um auf dem trockenen zu probieren brauchst du glaube ich noch nicht mal ein bridge device. das hier müsste eigentlich reichen:

Code Auswählen Erweitern

define hdtest HUEDevice 1
attr hdtest color-icons 2
attr hdtest webCmd rgb

du siehst keinen echten status im device aber der colorpicker sollte erscheinen.

gruss
  andre

[Blackcat]

Beim Dark ist es nicht so, dafür aber immer noch das "mehrmal wohinklick zum onpropertychange Event" Problem, die Farben sind aber mit angeschlossenen hues richtig

[herrmannj]

Hi,

schau dir mal rudis konzept der widgets für fhemweb an. inzwischen kann man die zuordnung zwischen set kommando und zugehörigem widget auch konfigurieren. das erste deispiel ist das neue popup beim editieren des raum attributes.

Innerhalb von fhem web finder ich die widget Struktur gut, wünschenswert und im Hinblick auf eine konsistente Darstellung wichtig!

Anders wird das wenn ich gedanklich aus fhem web rausgehe. Beispiel: ich stelle (ganz rudimentär) fhem im Mediacenter (TV) dar. Basis floorplan als leere Seite auf der ich GUI Elemente beliebig positionieren kann. Gleiches mach ich auf einem Wecker (Xoro 390/ Android / Touch). Die Ansprüche könnten unterschiedlicher nicht sein: großes Display, großer Betrachtungsabstand, Bedienung auschließlich über FB vs. Minidisplay mit Touch.

Das widget System stößt da meiner Meinung nach an seine Grenzen. Mehrere Webinstanzen würden noch gehen, was aber wenn ich auf einem Device in unterschiedlichen Seiten verschiedene Darstellungen (Designs) haben möchte ? Sagen wir im Wohnungsgrundriss kleine icons und in einer Übersichtsseite das lcars (Strar Trek) design. Das ist jetzt nicht mal meine Idee, den Wunsch gab es. Der Versuch das in ein All-in-One widget zu pressen muss irgendwann scheitern oder das Ding wird so kompliziert das es keiner mehr versteht.

Die Trennung Darstellung und Funktion folgt nebenbei guten Traditionen und erlaubt den Usern die sich in JS/jQuery Grafik/design etc zu Hause fühlen sich besser einzubringen.

Den Slider schiebe ich schon seid Wochen vor mir her weil es eben viele für und wieder zu den unterschiedlichen Varianten gibt.

So macht es wohl am meisten Sinn (mit einem kurzen how-to):

Slider / colorpicker als device (ich nehme mal 'cp' als Arbeitstitel):

* in der Dev bekommt cp gesagt welche sein realer counterpart ist: also Wifilight device name.

* cp klinkt sich in die notify Schleife. Rudi hat eine Option eingebaut das nur events vom 'Mutterdevice' ankommen (noch klären: wie genau funktioniert das).

* Wifilight generiert events speziell für cp, kurze und kompakte. Im Augeblick erzeuge ich ein Name:c1:$hue,$sat,$val,$r,$g,$b. "c1" ist ein willkürlich von mir festglegte Kennung, das V von HSV gibt dem cp die absolute Helligkeit um die Dim Stellung anzuzeigen und HSV/RGB als Farbe ist klar. Der cp muss jetzt nur auf events hören die "cp1" an pos2 haben und die aufnehmen. An dieser kompakt-Msg würde ich schrauben wollen damit zB Infos wie "ich mach gerade einen colorfade" oder "ich bin on-for-timer" mit drin sind.
Ob der cp die auswertet und darstellt (icon floorplan - Grundriss?) liegt beim cp. Vorschläge/Wünsche dazu gerne, noch ist alles offen. Sollte möglichst so sein das zukünftig erweiert werden kann ohen zu kompliziert zu werden.

* cp liest die Daten also als fhem event und kümmert sich dann um "seine" Darstellung (Richtung Browser).

* Das 'cp' fhem Device hat eine Funktion 'FW_summary(@)' (hat jedes fhem device) mit ($FW_wname, $d, $FW_room, $pageData) = @_;
fhem benutzt diese Funktion so: wenn die Funktion undef zurückgibt wird die fhem eigene Darstellung genommen, also Widget für fhem web: das wär der Standard Weg, wigfilight bau ich so "zurück".

Wenn die Funktion HTML (JS) zurückgibt wird das zur Darstellung verwendet. Das wäre der Weg für den 'cp'. Im jetzigen Wifilight Modul sieht man wie sich der js gut mit "doc here" im perl kapseln läßt. In den perl params ist $FW_wname der Name der Webinstanz, $d das eigene Device, $FW_room der fhem-web-Raum für den die Funktion aufgerufen wird (hier ist der floorplan leider inkonsitent) und $pageData ein spezieller hash. Den habe ich auch erst spät verstanden setze den jetzigen Slider deshalb auch falsch (garnicht )  ein. Der Punkt ist das wenn auf einer Seite zB 'cp' A und 'cp' B eingesetzt werden ist es Blödsinn wenn jeder 'cp' den kompletten JS Code mitbringt. Es gibt ja Funktionen die geshared werden können, evtl sogar Bibliotheken die nur einmal geladen werden müssen. Wenn also fhem die Seite ausliefert ruft es erst dir FW_summary für 'cp' A auf. Der liefert den komletten JS den er braucht. Danach wird 'cp' B (FW_summary) aufgerufen und 'cp' B weiß nichts davon das A schon die shared Funktionen im Browser abgeliefert hat. Dazu gibt es $pageDate. Wenn 'cp' A aufgerufen wird ist das array (ist eine ref) leer aber alles was 'cp' A in das array schreibt wird dann auch an 'cp' B übergeben. 'cp' schaut also einfach nach ob ein anderer 'cp' ihm in dem array eine Nachricht hinterlassen hat. Wenn es die findet sind die shared JS functionen schon ausgeliefert und brauchen nicht noch mal.

Das grundsätzliche System (noch ohne padeData) läßt sich im jetzigen Wifilight gut abspicken.

Fehlt noch: wie bekommt der js Teil vom 'cp' (im Browser) die aktuellen Daten (longpoll). fhem lädt selbst "fhem_web.js", ist im Lieferumfang. Dort existiert "var FW_widgets = new Object();". In dieses object muss der 'cp' (als js im browser) sich eintragen um den fhem longpoll Mechanismus nutzen zu können (im source von fhem_web.js gut zu sehen). Der jetzige Wifilight slider ist dafür eine schlechte Vorlage. Weil ich den Mechanismus nicht kannte hab ich ein eigenes XHR aufgemacht was rückblickend völlig überflüssig ist.

Vorschlag / Wunsch wäre noch soweit als möglich auf externe js oder image zu verzichten. Das hat mehrere Gründe: longpoll und zustätzliches Bilder laden vetragen sich schon jetzt auf Apple device nicht, kann zukünftig auch andere Systeme treffen. Für den user ist ein einziger file besser. Webview Anwendungen haben unter Umständen keinen Zugriff auf die Ressourcen.

Bilder/Grafiken: besser inline svg oder canvas. Wenn Bilder unbedingt notwendig: können base64 gekapselt im 'cp' liegen und über FW_summary geliefert werden.
JS Bibliotheken: js Query wird von fhem ausgeliefert. Andere: wenn geht mit im 'cp' kapseln.

Viel mehr sollte nicht notwendig sein, das "how-to" hier ist vermutlich deutlich länger als das zugehörige device skeleton. Ich versuche mal kurzfristig ein perl skeleton dafür zu erstellen. Der js Teil muss dann natürlich individuell erstellt werden, ist ja jetzt genauso.

vg
Jörg

 

[hyper2910]

Hi, habe heute noch einen einfachen rgb Controller gefunden und einfach mal eine 12volt gut 5,3 led dran gehangen,  wie erwartet kann ich die Led in 3 oder 4 Stufen dimmen und ein und ausschalten. Da der Controller ja rgb kann, könnte man 3 leds separat darüber schalten, blau ein/aus, grün ein/aus und rot ein/aus,  alle an wäre dann weiss, violett dann 2leds und so weiter, sobald ich alles da habe, verkabele ich mal alles und mach mal ein Video.

Gesendet von meinem SGP521 mit Tapatalk

[justme1968]

auf jeden fall geht es um die trennung von darstellung und funktion. ich denke genau das tun die widgets. ein fhem device ist für mich etwas anderes.

bestimmt gibt es beim konzept der widgets noch verbesserungs potential aber ich sehe schon das sie genau in die richtung gehen die du vorschlägst.

ob du für ein oder mehre parameter eines devices das eine oder das andere widget verwendest ist konfigurierbar. den slider für die helligkeit oder ein text feld oder den knob. genau so kann es für rgb den colorpicker oder drei slider/knobs für die rgb werte geben. das ist die trennung von darstellung/ui und backend/funktion

sie sind rein js /rudis edior für das room attribut verwendet jquery-ui) und können mit fhem über longpoll kommunizieren. welche information du überträgst ist erst mal nicht festgelegt. und du kannst über die eine longpoll verbindung auch 'private'/device spezifische dinge übertragen.

ein beispiel für 'private' übertragung habe ich hier: http://forum.fhem.de/index.php/topic,23148.msg165046.html#msg165046 verwendet. das ganze ist eine art konfigurierbarer event monitor. vom fhem device zum browser werden über den longpoll mechanismus nur die zeilen übertragen die dazu kommen und zur zeit ein kommando das ding zu löschen.

die ideen in deinem 'how-to' gehen in genau die richtung die ich mir vorstelle nur ist cp kein fhem device (ich glaube das ist völlig unnötig und viel zu schwerfällig) sondern eben ein widget bzw. etwas (oder auch mehr) javascript das an longpoll hängt und so seine events bekommt.

fhemweb wird gesagt welches widget es für welchen parameter verwenden soll. entweder global oder device basiert. auch vom anwender änderbar.

das mehrfach laden von js code wenn ein device mehrmals auf einer seite auftaucht kann man jetzt schon durch $data{FWEXT} erreichen.

dein beispiel mir den icon im grundriss und lcars in der übersicht ist meiner meinung nach gerade dazu geeinget zu zeigen das die darstellung nicht in ein device gehört sondern ins frontend weil es die darstellung betrifft. d.h. der grundriss mit floorplan würde ein anderes 'framework' verwenden wie die lcars darstellung oder die normalen fhemweb seiten. hier wäre nur abhängig von der basis url ein andere default set an stylesheets und widgets zu laden. auf fhem bzw device seite ist nichts weiter zu tun.

das fhem device sendet seine events so wie bis her per broadcast an alle. und das cp widget pickt sich nur das raus was es interessiert. (by the way: das lauschen auf nur ein device geht in dem du $hash->{NOTIFYDEV} auf den namen des devices setzt das dich interessiert)

du sagst wifiligt generier spezielle events. ich glaube genau das ist nicht gut. es sollten events sein die so generisch wie möglich sind. eben damit man andere widgets dran hängen kann.

genau deine bibliotheken bzw das nur ein mal laden können die widgets bzw. sollten sie können. warum soll es dazu noch ein extra fhem device geben wenn der js teil völlig ausreicht?

für das eintragen gibt es auch schon einen weg. eventuell noch nicht optimal weil zur zeit jeder alle nachrichten bekommt. aber eigentlich hast das auch vorteile.

kurze zusammenfassung: ja, backend/funktion und frontend/design/bedienung sollten getrennt sein. warum dafür jeweils ein fhem device nötig ist verstehe ich nicht. ich denke das fhem device ist nicht nötig und fhem_web.js hat jetzt schon die möglichkeit dinge (konfigurierbar) nachzuladen, nur um den js code zurückzuliefern/einzubinden ist das device nicht nötig.

die summaryFn und detailFn sind zur zeit eher für den device state zuständig, die widgets für einzelne parameter/set kommandos. eventuell ist es sinnvoll diese trennung aufzuheben und das zu verallgemeinern.

ansonsten schön das jetzt noch jemand in diese richtung geht. bevor ich mit den hue devices angefangen habe gab es weder summaryFn/detailFn, noch die möglichleit die widgets zu konfigurieren. ganz zu schweigen von der möglichkeit sich in die longpoll komunikation einzuhängen. manches davon ist sicher nicht optimal weil es häppchenweise entstanden ist wenn mal wieder etwas nicht möglich war aber es geht sehr viel mehr als es auf den ersten blick den anschein hat.

gruss
  andre

[herrmannj]

Hi,

wie gesagt, ich zögere die Entscheidung widget oder device schon seid Wochen raus ... genau deshalb .

auf jeden fall geht es um die trennung von darstellung und funktion.

Dacour

... gehen in genau die richtung die ich mir vorstelle nur ist cp kein fhem device (ich glaube das ist völlig unnötig und viel zu schwerfällig) sondern eben ein widget bzw. etwas (oder auch mehr) javascript das an longpoll hängt und so seine events bekommt.

ein widget würde auch für mich syntaktisch besser passen. Stand heute sehe ich nicht wie ich das benutzerfreundlich konfigurieren kann. Wenn ich das widget auf nur 5 verschiedene Arten darstellen möchte (PC, PAD, Wecker, mobile, TV) müsste ich im Wifilight device fünf configs dafür  hinterlegen. Nehm ich jetzt noch die angesprochenen unterschiedlichen Darstellungen auf verschiedenen Floorplan pages multipliziert sich das.

Deswegen device: defacto werden dummys, und nichts anderes ist das, ja heute in der Breite schon so eingesetzt.

by the way: das lauschen auf nur ein device geht in dem du $hash->{NOTIFYDEV} auf den namen des devices setzt das dich interessiert)

Danke spart mir die Suche 

du sagst wifiligt generier spezielle events. ich glaube genau das ist nicht gut. es sollten events sein die so generisch wie möglich sind. eben damit man andere widgets dran hängen kann.

na klar. Die Idee war auch nicht komplett: Wenn der cp mit einer HUE spricht braucht es eben mehr messages. In der Summe sollte ein cp alle Farbigen Lampen bedienen können, alles andere wäre quatsch. Die "spezielle" msg dient dazu Bandbreite zu sparen, sollte keine Voraussetzung sein.

warum soll es dazu noch ein extra fhem device geben wenn der js teil völlig ausreicht?

Ist imho der einzige Weg einer individuellen und benutzerfreundlichen Konfiguration pro GUI Element

ansonsten schön das jetzt noch jemand in diese richtung geht. bevor ich mit den hue devices angefangen habe gab es weder summaryFn/detailFn, noch die möglichleit die widgets zu konfigurieren. ganz zu schweigen von der möglichkeit sich in die longpoll komunikation einzuhängen. manches davon ist sicher nicht optimal weil es häppchenweise entstanden ist wenn mal wieder etwas nicht möglich war aber es geht sehr viel mehr als es auf den ersten blick den anschein hat.

Danke für die Pionierarbeit, ich verstehe was Du ausdrückst!

Bei den farbigen Lampen haben wir beide vermutlich einen nennenswerten Marktanteil und das Thema GUI Element ist da eben auch integral wichtig. Ob das Kind hinterher widget oder device ist mir auch völlig Wurst. 

Vielleicht sollten wir mit dem Thema auch nochmal in den dev thread ? Wobei fünf Ärzte auch sechs Meinungen geben ... Ich bau mal das perl skeleton. Wenn sich später raus stellt das es bessere Wege gibt reisen wirs halt wieder ein :-D

vg
Jörg

Nachtrag: mit cp ziele ich primär auf floorplan ähnliche Darstellungsformen

[Blackcat]

Sagt mir Bescheid, wenn ihr soweit seit, damit ich bei der GUI (colorpicker etc.)
unterstützen kann

jq ui kenne ich ganz gut  und der picker lässt sich auch noch vereinfachen für z.B. Lampen ohne Sättigung.

[Bapt. Reverend Magersuppe]

ich hab mir einige milights aus china auf Vorrat bestellt, eine ist bei mir auch schon in das walhalla eingezogen .

Ich habe mir bei der Ebay-Aktion letztens auch ein 2er-Pack bestellt und bin angefixt. In China scheint es die Dinger ja viel günstiger zu geben, aber wie ist das mit Zoll? Sobald man mehr als eine bestellt ist man schon bei über 25€. Dann lohnt sich der Kauf wohl kaum noch. Es sei denn, man nimmt ein 100er-Pack.
Wie macht ihr das?