Hi Adrian,
yes this was the right hint! The file is missing in my installation. I tried to de- and re-install the module, but the file was not written. 
Is there any log where I can see what’s going wrong while the installation process of the zigbee module? I can’t see any errors in the shell.
Can you provide me this xml also? Thanks!
Regards,
Carsten
I’ll send it to you attached to a PM.
After you copy it in /etc/homegear/families, please restart homegear, unpair the device then pair it again.
It would be nice if it would be possible to first delete the homegear.log in /var/log/homegear` then do the pairing. Then perhaps try to set the RGB value, too, then if possible send me the log in a PM…
Thank you!
Adrian Roman
Thank you for the log files!
I’ll look more over them to see what more I could figure out.
Things do seem as working now, there are some issues in the log but they do not seem essential.
I’ll write here instead of private, since it might serve others that are facing similar issues.
For RGB, it looks like you’re trying to send a string instead of an integer. You could do that as long as it’s a decimal. I’ll change the code today to also accept a hexadecimal string (prefixed with 0x or 0X) as well, but until this change gets into the binaries, please send the value either as an integer or a string containing the decimal value.
1 Like
Hi Adrian,
with MQTT.fx (tool to send MQTT commands to my broker) I have no possibility to define the type of the payload. I had no luck to find the right JSON structure and the correct topic in order to send the payload for RGB.
In zigbee2mqtt I had several possibilities to hand over color values. I could use “r,g,b” (e.g. 255,0,0) or hex code “#rrggbb” (e.g. #FF0000). It was also possible to send r, g and b separatly in a JSON structure. That’s why I tried different ways of payloads.
Currently I use openhab 2.5 to handle my bulbs. They use “r,g,b” as value by default. When this is not possible, I can create JS transformations to create the right value for the RGB topic.
Can you provide a sample JSON structure (including mqtt topic) or payload to send a valid RGB command? Thanks!
Regards,
Carsten
For now what would work for you if it’s sent as a string is “255” for blue, “65280” for green, “16711680” for red. I’ll change the code to accept hexadecimal as well and maybe “r,g,b” strings as well.
1 Like
The new sources are committed, the binaries will be available soon.
In general, now if a string is sent instead of an expected int value, it will be converted even if set as hex, prefixed with ‘0x’ or ‘0X’ or ‘#’. For the special RGB value, “r,g,b” is also allowed.
4 Likes
Great job Adrian! Thank you very much! I’m looking forward to test everything.
Hopefully the installation process works on my RPI 3b and all new files will be deployed as expected.
Regards,
Carsten
2 Likes
Hi @Adrian,
congrats to your implementation! Everything works as expected except the r,g,b value. I was wondering why the quotation marks are necessary for the r,g,b value. 
When I enter 255,0,0 as payload for RGB the bulb switches the color three times instead of showing a red color. But when I enter “255,0,0” as payload it works flawlesly. Imho it’s a bit unusual to also enter the quotation marks…just my 2 cents…
Now I can control my first HUE test-bulb via openhab and I’m looking foward to also migrate my other bulbs in order to eliminate zigbee2mqtt someday.
Update:
Somehow a payload like ‘“117,81,50”’ for a topic like ‘homegear/1/set/40/1/RGB’ (my HUE bulb) triggers a lot of zigbee state-messages (eight to be exact) in my broker:
…also the color changes at least two times.
I added also the payload for theses messages in the ZIP attached here:
ZigbeeMessages.zip (1,4 KB)
PS: Would it be possible, that the state topic (e.g. ‘homegear/1/plain/40/1/RGB’) responds with the same value format as it was triggered?
Regards,
Carsten
1 Like
From my point of view, 255,0,0 must be a string/text. Somewhere along the way, if you pass only 255,0,0, it’s not converted to a string but to something else.
This happens because a lot of lightbulbs do not expose in zigbee r, g, b values, but hue, saturation and value. So if you set rgb, those are triggered as well.
Some light bulbs might also send reports while they change values and those trigger some other values changes.
I’ll check the log to see what it happens in your case.
I think it’s better to reply in a consistent manner than to change types ‘on the fly’ depending on how was the last request.
PS This is still work in progress, by the way (and it goes in the zwave module as well, but it’s different there, because zwave exposes r, g, b and not hue and so on). It still suffers changes.
2 Likes
Hi @Adrian
thanks for the explanation. I’m fine with it. 
I made another experience while testing: When I enter payload #BB0059 for RGB, I see that color first changes to BA0058 (converted from decimal value 12189784 from state topic) and then changes to BB0059. I also see that the color changes two times. It’s the same behaviour like with values in “r,g,b” format.
Regards,
Carsten
I’m currently trying to remove some of the duplicates reported, by the way.
r, g, b or 0x… or #… are exactly the same thing, internally they are all converted to an integer.
As there is a conversion from rgb to hsv values, then those are actually set in the light bulb, you might see some differences between the values you set and the ones you get. The conversion is not perfect and besides, not all values might be supported by the light bulb.
As for seeing the values changing twice (actually, that happens three times, for each individual value from hsv), I’ll try decreasing the delay between setting each value. Some light bulbs do not like setting them immediately one after another (they ignore some of the packets if done that way), that’s why I added the delay.
I’ll do some tests and if I notice issues with that, I’ll increase the delay back.
1 Like
I tried decreasing the delay but tests with a Hommie light bulb show that’s a too low setting, so it will stay at 100 ms between commands.
I’ll try changing the order of the values setting, maybe it will be less bothering.
Ok, finally I did a change that I hope it will help: instead of setting individually the HUE and SATURATION items, it goes through COLOR_CONTROL.MOVE_TO_HUE_AND_SATURATION.HUE, COLOR_CONTROL.MOVE_TO_HUE_AND_SATURATION.SATURATION and COLOR_CONTROL.MOVE_TO_HUE_AND_SATURATION.TRANSITION_TIME (if available). This ends with sending only a single command packet to the light bulb for hue and saturation.
LEVEL is sent separately, though, but hopefully this will decrease the multiple changing color effect. I’ll commit the code today, so the binaries will be available soon.
Hi @Adrian,
I tested the new nightly 0.8.0-3031. The multiple color changes are still there but not that often as before. Most of the time the color changes only one time to the desired color code. Plus: I see now only 4 MQTT commands sent to the bulb instead of 8.
But unfortunately I experienced more “hick-ups” when processing MQTT commands. When I change the color often the bulb seems to be unresponsive. I can see that the MQTT commands are sent (in the ‘plain’ topic of the bulb) but nothing changes. Sometimes all commands are executed later one after another, but if not, I have to re-pair the bulb.
The same behaviour occurs, when I power cycle the bulb. MQTT commands are sent but nothing happens. Also in this case the bulb sometimes reacts after round about one minute, but sometimes not and I must re-pair the bulb.
What logs should I provide you in order to support you with error hunting?
Regards,
Carsten
I don’t think that these “hick-ups” were there before, but I can step back to an older nightly in order to test it.
1 Like
One thing that you shouldn’t do:
Don’t bomb the device with many commands one after another. Wait a little before setting a value, otherwise some devices do that, they ignore commands. About that I cannot do anything, since it’s the device rejecting the commands.
Those are not sent to the bulb. What you probably see is the multiple change of values that occur. Setting an RGB does not change only the RGB variable, but also HUE, SATURATION and LEVEL. That is, 4. Those are values in homegear.
The values that are actually changed are hue, saturation and value (corresponds to LEVEL), in the latest version that should result in sending two commands to the device: one for ‘move to hue and saturation’ and one for ‘level’.
Maybe for your device the delay between the commands (I added it there just because some of the devices do that nasty thing of ignoring commands that come too fast) is still too small.
Look in the log for things like ‘sending packet’ or something like that, after the portion where you locate the MQTT command sent.
Hi Adrian, I just bought an IKEA Tradfri E1745 Motion Sensor. No prob to pair the sensor, but I fear I need a special xml-file, isn’t it?
Not necessarily, it depends on what the sensor exposes ‘officially’ as supported.
The zigbee module interrogates the device to learn what it supports.
Sometimes there might be some manufacturer specific clusters that are not standard and in some cases some functionality of such clusters is known. Some other times the device does not expose correctly the supported clusters.
In some other cases the functionality of some clusters might be too complex and exposing some variables in a simpler manner through some definitions in an xml file might help.
In fact, just last week I added a new xml file for such a device, having a manufacturer cluster exposing battery level and status of the device and also misbehaving by reporting supported clusters as ‘client’ instead of ‘server’.
Anyway, if you see your paired device in homegear and if you receive notifications from it, it might not need an xml file.