Color picker item

[Shingoo]

Hi Kai,

we talked about this feature request: http://code.google.com/p/openhab/issues/detail?id=91 

I got the hue binding running and I am already able to switch on and off the lights with white color. Next step is to make them dimmable in white... This is not a big step anymore... Now it comes to color... It would be great if we could create a color picker item in the near future to make it possible for me to integrate color changing in my hue binding.

Time for bed now ;)

Cheers,

Roman

[Victor Belov]

Hi,

We need a widget spec from Kai or Thomas to implement it on UI side.

How does it appear on Hue side? Color control and brightness control?

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To view this discussion on the web visit https://groups.google.com/d/msg/openhab/-/txrVDtMoHaQJ.
To post to this group, send email to ope...@googlegroups.com.
To unsubscribe from this group, send email to openhab+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openhab?hl=en.

[Shingoo]

Hi,

The bulbs are controlled via Json messages. For example:

{"bri": 128, "ct": 200, "on": true}

Brightness: 0 - 255

color temperature: 500 - 154 (kind of 2100K - 5800K)

on: true / false

{"bri": 255, "xy":[0.4, 0.4], "on": true}

Brightness: 0 - 255

x and y: 0.0 - 1.0 (from XYZ-Matrix I guess)

on: true / false

But in the end I think we should think about what the user will expect. And I think he would expect something like a color wheel and a brightness slider... How we map that to the api of philips hue is the second step I think.

Cheers,

Roman

[Shingoo]

In the official app it is a color picker and a brightness slider, sorry ;)

[Victor Belov]

Hi,

That's exactly what I was asking about :-)

I think that (at list in Android client) it will not be possible to put both into a standard height widget. I was thinking about something like a dimmer (brightness) control on the widget itself, and a popup window with colour selection if you click on the widget, or probably on a colour palette (or smth like that) icon on the widget. Most of time you would like just to switch it on and off and probably we need to simplify this…

Best regards,

Victor Belov

On Mon, Nov 12, 2012 at 8:43 PM, Shingoo <roman.h...@gmail.com> wrote:

In the official app it is a color picker and a brightness slider, sorry ;)

--
You received this message because you are subscribed to the Google Groups "openhab" group.

To view this discussion on the web visit https://groups.google.com/d/msg/openhab/-/0nKzyJzlNSUJ.

[Shingoo]

Sounds like a good solution. Most of the time I just want to change the brightness and not the color. That's right.
How do you think about a second type of item, where you can define up to 4 different color settings which then will be available to choose from in the UI.
Another possibility would be to show a color slider with plus and minus for brightness.

[Kai Kreuzer]

As long as we do not have a dedicated RGBItem/Widget - and also as an alternative once we have RGB - I would suggest to also offer binding possibilities to Switch and Dimmer items for red, green, blue and brightness. This way you could already now add 3 or four sliders or switches to choose the colour.
The RGBItem will then be most likely a "ComplexItem" having exactly these 4 DimmerItems as their sub-items, so this should be very much in-line. And by this we can make sure that you are not getting bored as long as the RGBItem is not yet there ;-)

Regards,
Kai

> --
> You received this message because you are subscribed to the Google Groups "openhab" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/openhab/-/6fBGfkMs78gJ.

[Shingoo]

All right. So I will implement my binding, so that the user may have the following options:

1. A switch that turns the bulb on and off with a white color and full brightness.
2. A Dimmer that dimms the bulb with a white color.
3. A combination of two dimmers for white colors (one for color temperature and one for brightness)
4. A combination of three dimmers for RGB and a dimmer for brightness.
5. A combination of three dimmers for RGB and a switch for turning the bulb on and off (with full brightness)

Are there any other ideas, suggestions or wishes?

Cheers,

Roman

[Victor Belov]

Hi,

Just one suggestion. Is't it easier to create an RGB item? ;-)

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/d/msg/openhab/-/KzBpS6XaD9MJ.

[Shingoo]

Just to quote Kai: 

"The RGBItem will then be most likely a "ComplexItem" having exactly these 4 DimmerItems as their sub-items, so this should be very much in-line. And by this we can make sure that you are not getting bored as long as the RGBItem is not yet there ;-)"

[davy vanherbergen]

Hi Roman,

I agree, for the UI it does make sense to split the color from the brightness.  I like Victor's idea of having a slider and a color pallet button which pops up a color picker.  I've attached a 2 quick mock-ups of what it could look like.

Davy

 

On Tue, Nov 20, 2012 at 3:58 PM, Shingoo <roman.ha...n@gmail.com> wrote:

Hi Davy,

totally correct. But I think the user would prefer to have a slider that allowes him to change the brightness without changeing the color. To do this with three RGB-Sliders is quiet tricky. Better would be a color wheel to select the color and a brightness slider. Of course this should be mapped to thre simple RGB values.

Let's better discuss this here: https://groups.google.com/forum/?fromgroups=#!topic/openhab/OXXcR3bo0WA

Cheers,

Roman

[Kai Kreuzer]

Hi Davy,

your mocks look nice, widgets like that would do the job nicely.

I think you are right, for a complex RGBItem, three sub-dimmers would probably be enough (it is the code that has to adapt it to the three RGB values). From your experience, is this also the case for RGBW strips? I had through that the color space of them is bigger than pure RGBs, especially you have more possibilities of brightness versus hue control.

Best regards,

Kai

--
You received this message because you are subscribed to the Google Groups "openhab" group.

To view this discussion on the web visit https://groups.google.com/d/msg/openhab/-/niSFSz1053UJ.

To post to this group, send email to ope...@googlegroups.com.
To unsubscribe from this group, send email to openhab+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openhab?hl=en.

<rgbslider.jpg><rgbslider2.jpg>

[davy vanherbergen]

Hi Kai,

I don't have RGBW leds myself, but from what I could dig up, it appears that when using RGBW with DMX you do need 4 different DMX channels to control them. There are some dmx drivers which will accept a 3 channel input and then convert it to 4 channels, but this most likely results in some range loss.

I guess that if you want full support for RGB and RGBW in openhab, one option would be to to add 2 complex items: one for RGB and another for RGBW.  Or maybe only an RGBW one, of which the output can probably be scaled down to RGB.

Davy

[Kai Kreuzer]

Hi Davy,

So we would indeed need 4 channels (at least as an option) instead of only 3. I will try to dig into the matter when I start designing the RGBItem, how mappings could possibly be done.

Let's first get openHAB 1.1 out of the door so that I have some time to ponder about that and discuss it with you.

Regards,

Kai

To view this discussion on the web visit https://groups.google.com/d/msg/openhab/-/IYyTxsNVl1UJ.

[Kai]

Ok, 1.1 is out, so it is definitely time to revive this topic!

Thinking about 3 or 4 channels for the item, I agree with you that from all theoretical background, 3 channels for RGB should be enough to define any color - this is after all the standard representation. So my suggestion would be to go with this approach, knowing that we would have to convert this into 4 values for RGBW strips.

I will create a new feature branch in the main repo for this item/widget. What would you suggest as a name for the item/widget? I would call the item type simply "Color" and the widget possibly "Colorpicker", is that ok with you?

Best regards,
Kai

[davy vanherbergen]

Hi Kai,

Those names sound good to me.  I'll create a branch on the new feature branch for the dmx binding, as soon as I get my mercurial updated...

A Color item with 3 channels sounds good to me.  The extra channel for RGBW could then easily be mapped in the configuration like:

Color led_strip_rgb "RGB Led Strip"  {dmx="1,2,3"}

Color led_strip_rgbw  "RGBW Led Strip"  {dmx="4,5,6,7"}

What do you have in mind for the command types supported by the Color Item? At first glance we would need :

 - OnOffType: Could be used for switching the entire strip on/off

 - IncreaseDecreaseType: Could be used for changing only the light intensity

 - StringType: for sending complex (looping) color fade commands

I'm not sure if a dedicated ColorChangeType command would make sense.  A color change could also be expressed as a string command like "rgb(125,125,255)".

Kind regards,

Davy

[Kai Kreuzer]

Hi Davy,

What do you have in mind for the command types supported by the Color Item? At first glance we would need :

 - OnOffType: Could be used for switching the entire strip on/off

 - IncreaseDecreaseType: Could be used for changing only the light intensity

 - StringType: for sending complex (looping) color fade commands

I would have the ColorItem inherit from DimmerItem, so that it supports On/Off and Inc/Dec. Additionally, I will add a new RGBType that can be used as a state and a command for the ColorItem. 

I do not see the need for the StringType - as we discussed at Devoxx, I would suggest to put things like looping and other complex logic rather in the binding configuration (as it might be a very specific feature that only works for DMX, but e.g. not for Philips Hue). You could e.g. say in your binding configuration that you want to always fade with 500ms or you want to loop over the last 3 received RGB values. The item itself is then rather the contact point for the UI, where you simply have on/off, inc/dec and a color picker.

Hoping to get a first version pushed to the repo by tonight.

Regards,

Kai

To view this discussion on the web visit https://groups.google.com/d/msg/openhab/-/HzitSOT72PgJ.

[davy vanherbergen]

Hi Kai,

Having it available tonight would be excellent, then I can work om my dmx binding over the weekend :-)

You're probably right about not needing a string type in the item, I'm not too familiar with openHab and all it can do yet, but that will hopefully change soon.  I guess I could just bind the same light source multiple times in the binding configuration with different configurations for different purposes like fades, loops and scenes..

I will give it a try and let you know if I can get it working..

Davy

[Kai Kreuzer]

Hi Davy,

ok, I have just pushed a first draft version to the feature branch: http://code.google.com/p/openhab/source/list?name=1.2-rgb

This now allows to add items like "Color RGBLight" to your items file and widgets like "Colorpicker item=RGBLight" to your sitemap.

Please note that I haven't implemented any UI renderer yet, so trying to use the widget in a UI will fail.

But what you can already do is to operate on the items through the console. The string representation of a color is done as "<hue>,<saturation>,<brightness>", e.g. "0,100,100" for a bright red. Initially I actually worked with RGB, but changed it to HSB as this allows setting "B" to 0 without losing the color information - this was important for keeping the correct color, if the item receives ON/OFF or PercentType states (e.g. through normal switches or sliders, which are also valid widget options for ColorItems).

To test things on the openHAB console, you can do this:

> openhab send RGBLight 120,50,80

> openhab status RGBLight

> openhab send RGBLight OFF

> openhab status RGBLight

> openhab send RGBLight 50

> openhab status RGBLight

and you will see that only the brightness value changes after setting hue and saturation initially.

This should be enough to get you going for the binding - feel free to come back with questions!

Regards,

Kai

To view this discussion on the web visit https://groups.google.com/d/msg/openhab/-/CHt2YV4t7hAJ.

[Kai]

Hi again,

I just pushed an update which now can render a color picker widget in the Classic UI, which follows your design suggestion in https://groups.google.com/d/msg/openhab/OXXcR3bo0WA/niSFSz1053UJ

Note that it does not yet set the item value, so it is not yet usable. But I will work on this next. I will add further updates directly on the issue http://code.google.com/p/openhab/issues/detail?id=91, so whoever is interested in this feature, please subscribe on the issue for updates!

Regards,
Kai

[davy vanherbergen]

Cool. I'll have a look.  I have an initial version of the dmx binding running, so as soon as the picker becomes active, I will be trying it :-)

Tomorrow or so, I will push the dmx binding to my clone, but I still have a question on the build process.  The dmx binding depends on a different osgi module from OLA which is not publicly available anywhere yet.  What would be the easiest way of making it available to the build process?

Kind regards,

Davy

--

You received this message because you are subscribed to the Google Groups "openhab" group.

To view this discussion on the web visit https://groups.google.com/d/msg/openhab/-/bVEsxwLGPwcJ.

[Kai Kreuzer]

Hi Davy,

What would be the easiest way of making it available to the build process?

If a library is not available in a public p2 repo (or is not even an OSGi bundle), we currently always include them as a jar in "lib" folder in our bundle. This way it is also ensured that it is installed when a user adds the binding to the addons folder and we do not have to include such dependencies in the core distribution already.

See KNX, 1-Wire or Sonos as examples, where it is done this way.

Regards,

Kai

[davy vanherbergen]

Hi Kai,

In an ideal world, I would be able to run both OLA and OpenHab from one raspberry, but at this point I'm not convinced that my pi will be able to handle the load. If the load does turn out to be too much, I would like to keep my options open to run the OLA bundle on the raspberry and access it from OpenHab running on a different machine (another raspberry?) using distributed osgi. For this reason, I'm not to keen on including it as a lib in the binding bundle itself.  Or maybe I could include it as a lib and run only a lightweight OpenHab demon on the rapsberry which shares it's event bus with another OpenHab instance.  Is this a setup anyone has ever tried?

Anyway, I can probably get the bundle dependency published in Maven Central once it is ready to be released.  Would this be OK for the build, or does it really need to be a p2 repository?

I have also pushed an initial version of the dmx binding to my clone.  When you have time, feel free to do a spot check on the code to check if it is up to openHab standards.

Pom changes haven't been pushed to the clone, so the bundle doesn't compile yet..

In my clone, there is also a changeset containing a fix for the decimal type (which had an error in the equals method) and the hsb type, which did not always convert correctly to RGB.

Kind regards,

Davy

[Kai Kreuzer]

Hi Davy,

> In an ideal world, I would be able to run both OLA and OpenHab from one raspberry, but at this point I'm not convinced that my pi will be able to handle the load.

Is OLA that heavy? If the JVM/OSGi stack is up once, the pure event processing and execution should not demand for that much power, does it?
Btw, what size is the bundle that we talk about?

> If the load does turn out to be too much, I would like to keep my options open to run the OLA bundle on the raspberry and access it from OpenHab running on a different machine (another raspberry?) using distributed osgi.

This clearly wouldn't be a "default" installation anymore - the default should imho be the "embedded" version in the lib folder.

> For this reason, I'm not to keen on including it as a lib in the binding bundle itself. Or maybe I could include it as a lib and run only a lightweight OpenHab demon on the rapsberry which shares it's event bus with another OpenHab instance.

Well, you could include it as a lib and deactivate its use, if you find a remote DS available offering the DMXService (I doubt that it's a good idea to run openHAB as well there if all you really want is to have OLA running and exposing a service).

> Is this a setup anyone has ever tried?

The very likely answer is no :-)

> Anyway, I can probably get the bundle dependency published in Maven Central once it is ready to be released. Would this be OK for the build, or does it really need to be a p2 repository?

It needs to be a p2 repo.

> I have also pushed an initial version of the dmx binding to my clone. When you have time, feel free to do a spot check on the code to check if it is up to openHab standards.

Thanks, at a very first glance it looks pretty good!

> In my clone, there is also a changeset containing a fix for the decimal type (which had an error in the equals method) and the hsb type, which did not always convert correctly to RGB.

Thanks, especially for also already adding test cases for it!

I'll have to hurry up now to work on the widget, so that we can fit both parts together soon - looking forward to it :-)

Regards,
Kai

[davy vanherbergen]

On Wed, Dec 26, 2012 at 10:55 PM, Kai Kreuzer <k...@openhab.org> wrote:

Hi Davy,

> In an ideal world, I would be able to run both OLA and OpenHab from one raspberry, but at this point I'm not convinced that my pi will be able to handle the load.

Is OLA that heavy? If the JVM/OSGi stack is up once, the pure event processing and execution should not demand for that much power, does it?
Btw, what size is the bundle that we talk about?

The size of the bundle is about 840Kb, but I may be able to trim that down a little.  When running on my raspberry, OLA and the OLA java api together do consume about 10 to 15% of the raspberry CPU.  This is a continuous load, as the OAL daemon keeps sending about 30 dmx frames per second.  There may be some room to optimize here, this is something I need to investigate.

When openHab starts, it pretty much eats most of the CPU for a few minutes, after that it drops back quite a bit, but i don't have anything configured in openHab yet except for the DMX stuff. I expect that once I start enabling more things (my home automation system, persistency, etc..) that it will also have some impact on the CPU.

 

> If the load does turn out to be too much, I would like to keep my options open to run the OLA bundle on the raspberry and access it from OpenHab running on a different machine (another raspberry?) using distributed osgi.

This clearly wouldn't be a "default" installation anymore - the default should imho be the "embedded" version in the lib folder. 

 

OK, maybe I should just start with the 'default' and fix issues only as they occur ;-)  I'll embed it as a lib over the next few days.

 

> For this reason, I'm not to keen on including it as a lib in the binding bundle itself.  Or maybe I could include it as a lib and run only a lightweight OpenHab demon on the rapsberry which shares it's event bus with another OpenHab instance.

Well, you could include it as a lib and deactivate its use, if you find a remote DS available offering the DMXService (I doubt that it's a good idea to run openHAB as well there if all you really want is to have OLA running and exposing a service).

> Is this a setup anyone has ever tried?

The very likely answer is no :-)

> Anyway, I can probably get the bundle dependency published in Maven Central once it is ready to be released.  Would this be OK for the build, or does it really need to be a p2 repository?

It needs to be a p2 repo.

> I have also pushed an initial version of the dmx binding to my clone.  When you have time, feel free to do a spot check on the code to check if it is up to openHab standards.

Thanks, at a very first glance it looks pretty good!

> In my clone, there is also a changeset containing a fix for the decimal type (which had an error in the equals method) and the hsb type, which did not always convert correctly to RGB.

Thanks, especially for also already adding test cases for it!

No problem.  I was wondering though, is there any special reason why tests are in separate bundles and not in the same bundle 'maven style'?

I'll have to hurry up now to work on the widget, so that we can fit both parts together soon - looking forward to it :-)

Looking forward to trying out the widget!  I'm currently doing some manual testing by entering openhab commands in the osgi console to control my leds and based upon the feedback I've received so far (fades too slow, colors wrong, ..), your widget will definitely be tested for the Wife Acceptance Factor ;-)

 

Regards,
Kai

--
You received this message because you are subscribed to the Google Groups "openhab" group.

[Thomas Eichstädt-Engelen]

Hi Davy,

No problem.  I was wondering though, is there any special reason why tests are in separate bundles and not in the same bundle 'maven style'?

no, OSGi best practice!

There should be no Tests and especially no dependencies to e.g. JUnit in "production" bundles. The Test-Bundles are no "real" bundles but rather fragment bundles which can only co-exist with the configured host-bundle.

Regards,

Thomas E.-E.

[davy vanherbergen]

OK, that makes sense. I was expecting that Tycho (which I haven't used before) could figure out which dependencies are for test scope and which are for runtime scope, as it is done in regular maven builds.  Maybe someone will bring maven and osgi closer together in the future...

[Kai Kreuzer]

Hi Davy,

> Looking forward to trying out the widget! I'm currently doing some manual testing by entering openhab commands in the osgi console to control my leds and based upon the feedback I've received so far (fades too slow, colors wrong, ..), your widget will definitely be tested for the Wife Acceptance Factor ;-)

I have just pushed my current code - it should now already work to choose a color with the picker widget and the item receives the according command - possibly not yet stable nor finished, but you might already want to try it out and use it for the DMX testing. Have fun!

Regards,
Kai

[Kai]

I have just merged the feature branch to the default branch - we therefore now have the new "Color" item type and a "Colorpicker" widget, which looks like this (in the Classic UI):

  

@Mihail, Pablo, Victor: It would be great if you could add support in the other UIs before the openHAB 1.2 release (somewhen in the coming months). I think this is a very nice feature and can make openHAB very interesting for DMX fans, but even more for users of fancy new gadgets like Philips Hue.

Best regards,
Kai