I recently added two of these globes to HA
HA is giving me the error “homeassistant.components.light.zwave: Error initializing as color bulb: No matching color command found. Initializing as standard dimmer.”
i have tried re adding them and see the zwconf file has what should be the color codes ready to go (assume it reads this)
Anyone help me out here?
I have noticed this is intermittent after each restart.
Sometime it detects the color sometimes not.
I’ve been troubleshooting the same error message with the ZW098 in Home Assistant 0.28.2, though in my case it wasn’t intermittent. The following fix worked for me:
In the zwcfg_[…].xml file in your .homeassistant directory, find the <Node> representing your ZW098 bulb (I did this by just searching for ZW098).
Scroll down to the <CommandClass> element with a name of COMMAND_CLASS_COLOR.
Inside that element, look for the following line:
<Value type="string" genre="user" instance="1" index="0" label="Color" units="#RRGGBBWWCW" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="#000000FF00" />
If you have that line, try capitalizing string to String and user to User, then restart Home Assistant.
In my case, this caused the bulb to be recognized correctly, and I was then able to set the color in Home Assistant.
The problem is that the get_rgbbulbs call in python-openzwave (version 0.3.1, in src-api/openzwave/command.py line 567) appears to be doing a case-sensitive search to find that element, expecting a capitalized genre and type, whereas the zwcfg.xml has them in lowercase.
I have no idea how to go about fixing this, but hopefully this will point people in the right direction. 
Thanks go to @armills for pointing me in the right direction.
Thanks for the suggestion. Gave it a try but just stopped HA from starting. I think its something in this config but mine is definately intermittant after each restart.
What error did you get when HA wouldn’t start after you made that change?
I had a little more time to look at this. Do you happen to remember how your original xml file was generated? I took a look at the sources for pyopenzwave and openzwave, and it looks like there might be some case confusion. Ideally these should both be case insensitive so it shouldn’t matter. If it only works when you specify it to match the pyopenzwave format, I’d guess the bug is there, rather than the C++ openzwave library. In any case this isn’t a home assistant bug since we’re just using the pyopenzwave api.
If I change the case and HA doesnt start it also doesnt give an error in the log. Like its stuck.
@armills - what case does HA expect it to be in?
Based on what ssimms says it should expect the capitalized form. It may depend on the versions of pyopenzwave and openzwave that you have installed.
I have the same issue using a raspberry pi with the all in one installer.
Tried the capitalizing but no difference.
It’s possible that the color value instance isn’t reliably being reported. If someone wants to test this, you can try deleting the flagged line and restarting home assistant. If that corrects the issue that code can be reworked.
That worked!, is still get a couple of “No matching color command found” errors, but I have 5 Fibaro RGBW controllers and they all seem to work now.
All the others channels (red, green, blue and white) now also have a colorpicker when turned on.
Good enough for me. It was intended as future-proofing logic, but I suppose I should have guessed not everyone would follow the standard. PR is in.
Strangely still one of my devices still has this error after this change
OK, so on further investigation, this problem runs a bit deeper.
Home assistant is listening for the openzwave node VALUE_ADDED event, at which point it creates the corresponding entity for that value. For most zwave lights, only a single value is required underneath COMMAND_CLASS_SWITCH_MULTILEVEL. For the colored bulb implementation however, the home assistant entity sends brightness changes to the COMMAND_CLASS_SWITCH_MULTILEVEL value, and color changes to the value under COMMAND_CLASS_COLOR.
https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/zwave/init.py#L289
In the current implementation, the entity is initialized when the multilevel value is added, the same as the rest of the zwave dimmers. At this point, it checks to see if the node contains the color value, and if it does it initializes it as a color bulb.
What we’re seeing here is that if the color value is added first, it is present when the multilevel value is added, and home-assistant initializes the color bulb entity properly. However, if the multilevel value is added first, the color value isn’t present, and we’re getting this error.
I think the proper fix will be to wait for the node initialization to be complete, before adding any home assistant entities, but this won’t be a quick fix.
Sounds like this might be the cause and explain why it it intermittent (depending on the initialization stage) Appreciate you lookinginto this 
PR opened here: https://github.com/home-assistant/home-assistant/pull/4030
Can you test the changes there on your network? It comes with the caveats described in the PR. Offline nodes will have no entities created until they come online.
Seems to have resolved the color issues for me. Well done
So to summarize the discussion in the PR, this patch introduces some significant delays in the zwave initialization process for large networks, so it’s not going to be merged in it’s current form. It’s certainly safe however to keep this patch applied to your local setup, if you want to keep your color lights functional.
The ultimate goal will be to work upstream with openzwave to get a better signal issued after all the values have been added. At that point the PR can be modified to use the new signal.
https://github.com/home-assistant/home-assistant/pull/4085 has been merged. v0.32 should finally solve this issue.
Is this issue related?
https://github.com/home-assistant/home-assistant/issues/7274
My error log:
Apr 25 15:07:53 hassbian hass[1602]: 17-04-25 15:07:53 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: service=turn_on, domain=light, service_call_id=1977389296-3757, service_data=entity_id=light.aeotec_zw098_led_bulb_level_35_0, rgb_color=[39, 235, 255]>
Apr 25 15:07:53 hassbian hass[1602]: 17-04-25 15:07:53 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Apr 25 15:07:53 hassbian hass[1602]: Traceback (most recent call last):
Apr 25 15:07:53 hassbian hass[1602]: File "/usr/lib/python3.4/asyncio/tasks.py", line 233, in _step
Apr 25 15:07:53 hassbian hass[1602]: result = coro.throw(exc)
Apr 25 15:07:53 hassbian hass[1602]: File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/core.py", line 1014, in _event_to_service_call
Apr 25 15:07:53 hassbian hass[1602]: yield from service_handler.func(service_call)
Apr 25 15:07:53 hassbian hass[1602]: File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components/light/__init__.py", line 246, in async_handle_light_service
Apr 25 15:07:53 hassbian hass[1602]: yield from light.async_turn_on(**params)
Apr 25 15:07:53 hassbian hass[1602]: File "/usr/lib/python3.4/asyncio/futures.py", line 388, in __iter__
Apr 25 15:07:53 hassbian hass[1602]: yield self # This tells Task to wait for completion.
Apr 25 15:07:53 hassbian hass[1602]: File "/usr/lib/python3.4/asyncio/tasks.py", line 286, in _wakeup
Apr 25 15:07:53 hassbian hass[1602]: value = future.result()
Apr 25 15:07:53 hassbian hass[1602]: File "/usr/lib/python3.4/asyncio/futures.py", line 277, in result
Apr 25 15:07:53 hassbian hass[1602]: raise self._exception
Apr 25 15:07:53 hassbian hass[1602]: File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
Apr 25 15:07:53 hassbian hass[1602]: result = self.fn(*self.args, **self.kwargs)
Apr 25 15:07:53 hassbian hass[1602]: File "/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components/light/zwave.py", line 334, in turn_on
Apr 25 15:07:53 hassbian hass[1602]: self.values.color.data = rgbw
Apr 25 15:07:53 hassbian hass[1602]: File "/srv/homeassistant/lib/python3.4/site-packages/openzwave-0.3.2-py3.4.egg/openzwave/value.py", line 292, in data
Apr 25 15:07:53 hassbian hass[1602]: self._network.manager.setValue(self.value_id, value)
Apr 25 15:07:53 hassbian hass[1602]: File "src-lib/libopenzwave/libopenzwave.pyx", line 2827, in libopenzwave.PyManager.setValue (src-lib/libopenzwave/libopenzwave.cpp:21766)
Apr 25 15:07:54 hassbian hass[1602]: TypeError: expected bytes, str found
I get the same error whether trying to use the color picker or an automation. It also throws a similar error when I try to change the color temperature, but works fine for brightness. Was doing everything fine before.
when I look deeper in my log I notice something strange. The way the states are reported for the Aeotec Bulb, and a Hue bulb is different. Color_temp and brightness are integers for the hue, and decimals for the aeotec. RGB_color is in parentheses for the hue and n square brackets for the aeotec.
<state light.hue_color_lamp_2=on; xy_color=[0.409, 0.518], supported_features=127, color_temp=289, rgb_color=(235, 255, 67), effect_list=['colorloop', 'random'], brightness=254, friendly_name=Hue color lamp 2 @ 2017-04-25T15:30:00.774289+02:00>
<state light.aeotec_zw098_led_bulb_level_35_0=on; color_temp=327.0, node_id=35, rgb_color=[255, 105, 55], friendly_name=Aeotec ZW098 LED Bulb Level, brightness=245.0, supported_features=51 @ 2017-04-24T10:14:38.573627+02:00>