LED Control in UI

[GoogleCodeExporter]

I am very new to this project and currently loving it. So Thank You.

I would like to be able to control LED's and more importantly there colour.
So for a start simple ability to colour the sliders would be great RGB or to 
group them together would be better. but in the future maybe a colour picker as 
well.

This is maybe a bit OTT but 
http://aycontrol.com/sites/default/files/images/kaufen/ayControl_KNX_RGB_Lichtst
euerung_am_iPhone.jpg

Thanks
Ben

Original issue reported on code.google.com by bhorns...@prg.com on 13 Jun 2012 at 12:40

[GoogleCodeExporter]

I'd like to see such a feature as well.

Thomas, as you are also dealing with RGB LEDs, I assign this to you (not to be 
implemented right away, but at least to keep this in mind as an open topic).

Original comment by kai.openhab on 15 Jun 2012 at 1:57

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by kai.openhab on 15 Jun 2012 at 1:57

[GoogleCodeExporter]

Looks nice! I will try to implement similar widget in the GreenT UI (Sencha 
Touch UI) once the back-end is ready.

Original comment by mishoboss on 21 Jun 2012 at 7:35

[GoogleCodeExporter]

Are we going to introduce new RGB Item as well as RGB Widget (which is obvious)?

Original comment by belovic...@gmail.com on 12 Jul 2012 at 5:09

[GoogleCodeExporter]

Will have to think about it, but not for 1.0.0 anymore...

Original comment by kai.openhab on 12 Jul 2012 at 5:40

[GoogleCodeExporter]

(reminder to self): probably that helps: http://anthonyterrien.com/knob/ ?

Original comment by teichsta on 12 Nov 2012 at 10:41

[GoogleCodeExporter]

Original comment by kai.openhab on 25 Dec 2012 at 8:42

• Changed state: Started

[GoogleCodeExporter]

I have created a branch "1.2-rgb" and added a new "Color" item type and a 
"Colorpicker" widget.
The Classic UI uses http://labs.abeautifulsite.net/jquery-miniColors/ for the 
colorpicker - this seemed to be a quite suitable and easily integratable 
solution.

Original comment by kai.openhab on 25 Dec 2012 at 10:04

• Added labels: Version-1.2.0
• Removed labels: Version-later

[GoogleCodeExporter]

The widget looks nice.  Here is some early testing feedback:

Usage on iPad 2:  
Color wheel response is sluggish. After dragging the point to a different 
location, it takes about half a second before the color of the vertical bar is 
updated.
Vertical slider is difficult to use. Most of the time, I end up dragging the 
entire browser page up or down, rather than the slider itself. I'm guessing 
that either the touch sensitive area of the slider is quite small or my fingers 
are too big..
The wheel looks really small. There is still lots of screen real estate that 
could be used.

Usage on iPhone 5: 
Color wheel response is better.
Vertical slider is almost unusable. It takes me an average of 5 tries before I 
can move it.
The wheel doesn't look as small as on the ipad, but it could probably double in 
size and still fit on the screen.

Usage on Ubuntu:
Color wheel is responsive.
Vertical slider is easily controllable with the mouse.

There was a case sensitive issue with the file names. A fix is available in my 
clone.

Original comment by davy.van...@gmail.com on 27 Dec 2012 at 12:24

[GoogleCodeExporter]

I just came across this color picker: 
http://acko.net/blog/farbtastic-jquery-color-picker-plug-in/
It doesn't look as nice, but I find it easier to use on a mobile device.

Original comment by davy.van...@gmail.com on 27 Dec 2012 at 11:24

[GoogleCodeExporter]

Problem with this is the GPL license - I cannot include it in the core distro.
I have just pushed my latest updates. The picker size is increased to look fine 
on iPhone and Android phone. The responsiveness is fine on both devices 
(although I had some freezes/sluggishness on my iPhone, but only a few times). 
I didn't yet try tablets - unfortunately, it is not possible to automatically 
scale the widget, so we will have to live with a "one size fits all".

> There was a case sensitive issue with the file names.
I have checked your change, but the capital S is actually the correct file name 
- did I miss something?

Original comment by kai.openhab on 27 Dec 2012 at 11:32

[GoogleCodeExporter]

> Problem with this is the GPL license
Didn't check that one..

> The picker size is increased ..
Cool, I will check the latest version.   The size on a tablet is not really a 
big issue anyway. 

> I have checked your change, but the capital S is actually the correct file 
name - did I miss something?
The main.html in my clone contained lowercase jquery.minicolors.js. 

Original comment by davy.van...@gmail.com on 27 Dec 2012 at 11:42

[GoogleCodeExporter]

> The main.html in my clone contained lowercase jquery.minicolors.js.

You are obviously right. I have pulled your changeset, thanks!

Original comment by kai.openhab on 28 Dec 2012 at 9:35

[GoogleCodeExporter]

Just pushed some other minor fixes.
From my testing point of view, it now works sufficiently good - tested on 
Chrome, Android, iPhone and iPad.
Would like to merge it to the default branch - we could then have other people 
more easily consume it (for Philips Hue binding and Colorpicker support in 
native apps). What do you think?

Original comment by kai.openhab on 29 Dec 2012 at 10:28

[GoogleCodeExporter]

I loaded all your latest changes and gave em a try.  The wheel is perfect. It's 
responsive and easy to use.  Personnally I'm still having issues using the 
vertical slider.  Sliding the white marker from top to bottom, is something 
that doesn't happen easily on my phone.  Maybe we can make the vertical bar a 
little wider. Or the make the marker on the slider bigger.  
At this point, it does seems like a good idea to have more people testing it, 
who knows, it may just be me who is having issues ;-)

I did notice something strange, when entering the following commands after the 
runtime is freshly started:
    openhab status RGBLight
    > Uninitialized
    openhab send RGBLight 9,50,10
    openhab status RGBLight
    > 0,0,10
    openhab send RGBLight 9,50,10
    openhab status RGBLight
    > 9,50,10

The first status update doesn't seem to be stored correctly.  

I've also noticed some other strange behaviour, where the colors appear to 
change when dimming. I'm not sure if this is related to the color item or to my 
dmx implementation.  I will look into this.
I had a late X-mas party today and OpenHab was used to provide the X-mas light 
chaser using 6 rgb strips. Apart for some timing issue I noticed on the fades, 
it was cool :-).

Anyway, as far as I've understood there is an openHab release every three 
months or so, which would mean the next one is around February/March.  Which 
means to me that it would make sense to merge it already with the main stream 
and get more people using it. If there is still an issue, there is still plenty 
of time to make the needed fixes.  

PS. My son, who is about 3.5 absolutely LOVES using the color wheel on the ipad 
to change the colors of the LEDs.

Original comment by davy.van...@gmail.com on 30 Dec 2012 at 12:24

[GoogleCodeExporter]

Ok, I have just merged the 1.2-rgb branch to default. You are right, we can 
still continue to do further bugfixing, the release 1.2 is still quite some 
time to go.

I have increased the width of the slider by another 30%, so I hope that it is 
now compatible with your fingers :-)

I was able to reproduce your initial status problem and fixed this bug. Let me 
know, if you find bugs in the dimming logic, I will leave this issue open 
meanwhile.

Original comment by kai.openhab on 30 Dec 2012 at 8:37

[GoogleCodeExporter]

I came across another bug.  When you define a Switch in the sitemap for a color 
item, it will always send the ON command when you toggle the switch.

E.g. in the sitemap there is:
Switch item=RGBLight

Toggling this switch results in:

00:45:04.506 INFO  runtime.busevents[:42] - RGBLight received command ON
00:45:08.256 INFO  runtime.busevents[:42] - RGBLight received command ON
00:45:15.593 INFO  runtime.busevents[:42] - RGBLight received command ON
00:45:16.508 INFO  runtime.busevents[:42] - RGBLight received command ON
00:45:19.233 INFO  runtime.busevents[:42] - RGBLight received command ON
00:45:19.853 INFO  runtime.busevents[:42] - RGBLight received command ON

There is no possibility to use the switch to send the OFF command.

Original comment by davy.van...@gmail.com on 2 Jan 2013 at 11:49

[GoogleCodeExporter]

I have fixed this bug and a couple of others on the way. Please let me know, if 
you find anything more!

Original comment by kai.openhab on 4 Jan 2013 at 10:00

[GoogleCodeExporter]

Closing this issue, if new bugs are discovered, please open a new one.

Original comment by kai.openhab on 11 Jan 2013 at 8:38

• Changed state: Implemented

[GoogleCodeExporter]

Hi guys, I try to implement the Colorpicker widget in GreenT UI. Maybe it's a 
silly question, but how exactly is represented the color? I see the classic UI 
is sending values like this "226.15384615384616,100,5.098039215686274". 
Initially I thought these are comma separated RGB values, but apparently they 
are not. In what format I should send the chosen color to the server? Thank you!

Original comment by mishoboss on 19 Sep 2013 at 8:21

[GoogleCodeExporter]

It's a HSB format.  Hue (0-360), Saturation (0-100), Brightness (0-100).

Original comment by davy.van...@gmail.com on 19 Sep 2013 at 8:28

[GoogleCodeExporter]

Mihail, great that you take the time to implement that - thanks!

Original comment by kai.openhab on 19 Sep 2013 at 8:51

[GoogleCodeExporter]

Thanks!

Kai, unfortunately I have very limited free time last few months, but GreenT 
desperately need to be updated. So, it's coming much more than just the color 
picker implementation :)

Original comment by mishoboss on 20 Sep 2013 at 11:02