Z0l
(Zoltan Orosz)
December 21, 2020, 1:34pm
1
Can someone please give me a working colorpicker example for Main UI? I was reading through the wiki pages but couldn’t find one.
1 Like
mstormi
(Markus Storm)
December 21, 2020, 2:37pm
2
off topic post hence moved.
Mind the rules please it’s the 2nd time in a row you didn’t.
Z0l
(Zoltan Orosz)
December 21, 2020, 2:58pm
3
I’m sorry but why is it off topic? The Main UI is only present in OH3.
mstormi
(Markus Storm)
December 21, 2020, 3:37pm
4
The thread is on the Release candidates and to find last minute issues, not to support users with theirs.
Z0l
(Zoltan Orosz)
December 21, 2020, 4:31pm
5
OK, so on OH3RC2, this is how a dimmer item looks like (and it is also working):
And this is how a Colorpicker looks like and it’s not working (there is a white bar that is not reacting to anything):
Go to Add Metadata → Select Default Standalone widget - > then change the widget from Default-OH to color picker card.
Z0l
(Zoltan Orosz)
December 21, 2020, 4:51pm
7
No joy, still that white box (I tried selecting colorwheel & RGB sliders in the Advanced properties as well but nothing changed):
ysc
(Yannick Schaus)
December 21, 2020, 5:22pm
8
Looks like a bug then… your item’s state is probably not initialized. Try doing openhab:send Jateklampa_Jateklampacolor "0,0,0" in the console and maybe the color picker will appear.
2 Likes
Z0l
(Zoltan Orosz)
December 21, 2020, 5:42pm
9
ysc:
openhab:send Jateklampa_Jateklampacolor “0,0,0”
Thanks, the colorpicker appeared after I initialized the item. How is this supposed to work with items that come and go (like lightbulbs)? Do I need a rule to assign the initial values when it comes online?
ysc
(Yannick Schaus)
December 21, 2020, 5:44pm
10
It will recognize H,S,B values, or numbers (will take it as brightness), or ON & OFF, but I forgot about NULL & UNDEF. So try not to avoid those states.
Z0l
(Zoltan Orosz)
December 21, 2020, 6:07pm
11
Sorry you mean to avoid NULL and UNDEF, correct? So I will need a rule to assign values during startup to get around this bug?
Z0l
(Zoltan Orosz)
December 21, 2020, 7:21pm
14
I’m not sure what you mean???
Dome
(Dome)
December 21, 2020, 8:21pm
15
Apparently, pocket posting is a thing… sorry about that.
1 Like
Z0l
(Zoltan Orosz)
December 21, 2020, 8:29pm
16
Do you want me to open up an issue for this on github?
Autchirion
(Autchirion)
January 31, 2021, 2:39pm
17
Did you report a bug? Because I’ve got the same issue using Philips Hue and Livarno devices, but not only for RGB, but also for the ones where I can change the temperature of the light.
Marlow
(.)
March 5, 2021, 11:29am
18
Was there a bug filed for this ?
I have the same problem with an Ikea bulb in zigbee2mqtt.
As I haven’t figured out, how to read out the CIE values yet (need to read out 3 individual topics, not just one, so as for the interim, I’m only reading out the brightness.)
That however doesn’t work (I didn’t think it would), the color item does not get initialised. It remains on value “NULL”.
This is in OpenHAB 3.0.1
/M
curlyel
(Curlyel)
March 5, 2021, 2:43pm
19
Yes:
opened 09:02AM - 26 Feb 21 UTC
closed 02:17PM - 04 Nov 24 UTC
bug
main ui
## The problem
Color items for newly discovered things (Extended Color Lights… ) don't get any color widget shown in all parts of the Main UI. Eg.:

I already opened an issue in the openhab-addon repository related to the Zigbee binding (see: https://github.com/openhab/openhab-addons/issues/10223)
Although, @cdjackson as the maintainer of the Zigbee binding suspects the cause in the webui. Therefore I raise this issue here too to start the discussion if it is to be solved in the binding _or_ the webui.
The following seem to support Chris's point of view:
```
openhab> send ZIGRGBWStripBuero_Color ON
Command has been sent successfully.
openhab> send ZIGRGBWStripBuero_Color 120,75,41
Command has been sent successfully.
openhab>
```
Openhab accepts the ON/OFF as well as the color commands sent to the item. And the real device indeed updates the color.
## Expected behavior
I'd expect a color widget show in standalone or lists allowing to control the color, e.g.:

## Steps to reproduce
- discover extended color light by the Zigbee binding (maybe other binding are affected as well)
- bind the color channel of the discovered light to a color item by "create equipment from thing" from within the model page
-
## Your environment
```yaml
runtimeInfo:
version: 3.1.0.M1
buildString: Milestone Build
locale: de_DE
systemInfo:
configFolder: /etc/openhab
userdataFolder: /var/lib/openhab
logFolder: /var/log/openhab
javaVersion: 11.0.10
javaVendor: Azul Systems, Inc.
javaVendorVersion: Zulu11.45+27-CA
osName: Linux
osVersion: 5.10.12-sunxi
osArchitecture: arm
availableProcessors: 4
freeMemory: 105461296
totalMemory: 323035136
bindings:
- astro
- bluetooth
- harmonyhub
- hue
- knx
- kodi
- miio
- mqtt
- network
- networkupstools
- rfxcom
- shelly
- sonos
- systeminfo
- zigbee
- zwave
clientInfo:
device:
ios: false
android: false
androidChrome: false
desktop: true
iphone: false
ipod: false
ipad: false
edge: false
ie: false
firefox: false
macos: false
windows: true
cordova: false
phonegap: false
electron: false
nwjs: false
webView: false
webview: false
standalone: false
os: windows
pixelRatio: 1.25
prefersColorScheme: dark
isSecureContext: false
locationbarVisible: true
menubarVisible: true
navigator:
cookieEnabled: true
deviceMemory: N/A
hardwareConcurrency: 8
language: de-DE
languages:
- de-DE
- de
- en-US
- en
onLine: true
platform: Win32
screen:
width: 3072
height: 1728
colorDepth: 24
support:
touch: false
pointerEvents: true
observer: true
passiveListener: true
gestures: false
intersectionObserver: true
themeOptions:
dark: light
filled: true
pageTransitionAnimation: default
bars: filled
homeNavbar: default
homeBackground: default
expandableCardAnimation: default
userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/88.0.4324.182 Safari/537.36
timestamp: 2021-02-26T08:59:41.316Z
```
… but up to now, I wasn’t aware, that the missing initialization causes that issue