Color picker: Handle NULL states

[Fohdeesha]

My Color Picker controlling some RGB lights stopped working out of nowhere, I'm guessing it may be due to the adding of the alternative color picker style. Didn't change anything in my config.

Now clicking any of the HSL Sliders, they jump right back down to black. Checking openhab.log explains why - every time I try to use the sliders now I get this in the log -

2017-04-11 05:00:59.841 [WARN ] [thome.io.rest.core.item.ItemResource] - Received HTTP POST request at 'items/fWIFI_RGB_2' with an invalid status value '129,NaN,NaN'.

I thought it might be cache or the dashboard, so I deleted my dashboard, created a new one, all on a new pc, and still getting the same problem. No matter what I do with the slider, at least one of the 3 values it returns is NaN. Using the habpanel bundled with openhab2 installed from debian repos, snapshot branch/repo

Also tried just selecting the new colorpicker mode, "aCKolor", and it results in a blank widget - http://i.imgur.com/wiL8wHL.png

[Fohdeesha]

EDIT: OK, so the new color picker Ackcolor actually works, I just couldn't see the dot to click on. That one is working.

That also revealed something strange - once I use this new color picker to get the HSL values above 0, then the other stock color picker starts working.

However when I restart openhab2 service and they all go back down to 0 (0,0,0), the stock color picker no longer works anymore and goes back to returning NaN values. If I switch to the new Ackolor picker, change the value to something nonzero (like pink), then go back to the stock picker, it works again. Restarting openhab2 service then breaks it again. Very strange.

Just zeroing all the values (putting all 3 sliders to zero) with colorpicker doesn't re-break it, it's just on fresh starts of the service or box rebooting that the stock one fails and needs something else to get the values above zero, then it works again

[ghys]

Very strange indeed. I personally tried color pickers with the Hue binding. If you use something else maybe it doesn't report valid HSL values from time to time? Try going to http://<your_openhab_ip>:8080/rest/items/fWIFI_RGB_2 when you encounter the problem, to check the item's state has the expected format - 3 comma-separated integers e.g. 198,100,100. If it isn't the case the widget is likely to break.

[Fohdeesha]

Looks like you're onto something. After a fresh openhab 2 start, the state is null? It's just sending the HSL/RGB values to an arduino via mqtt, is there special care I should use when defining a color item in openhab to make sure it has some "default state" other than null?

{ "link": "http://openhab2.home.lan:8080/rest/items/fWIFI_RGB_2", "state": "NULL", "type": "Color", "name": "fWIFI_RGB_2", "label": "RGB", "category": "slider", "tags": [], "groupNames": [ "WIFI_RGB_2G" ] }

my item for it is just Color fWIFI_RGB_2 "RGB" <slider> (WIFI_RGB_2G)

If you define a new generic color item, does it also start out as null for you on a fresh start of OH2? (worth noting the Ackolor picker doesn't have this issue, it will happily update the color string if the current value is null)

[ghys]

I never encountered NULL values for color items, but I can understand they might be occuring and the widget should handle them properly!

[ghys]

Should be fixed by #175 - reopen if necessary, cheers!