RGBW 2 Controller Bugs and More

[alex88 71]

Hi All,

 

I am sharing my communication with Fibaro Support as fair warning to anyone buying an Fibaro RGBW 2 module.

 

I am running 2x HC2 on the latest firmware 4.600. You need to be running 4.600 otherwise there are even more bugs that I experienced on earlier versions, namely 4.560.

 

If I come across anything else I'll update this post.

 

------------------------------------------------------------------------------------------------------------------------------

 

Broken Associations:

 

It appears that associations "break" after a short period of time. 

 

Given associations did not appear to be working, I wrote a LUA scene to control groups of lights together, however it has failed to work in all scenarios. 

 

When I press and hold the switch the colour does not sync with the "slave" RGBW 2 modules until about 6 seconds later. The result of a 6 second delay is very consistent and reproducible.

 

Looking at the Zniffer output:

• The Key_released message (from RGBW 2) is sent to the controller very quickly. From looking at the zniffer this happens within milliseconds, just like the key press, so all-in-all the communication between the device and the controller is blindingly fast... the 6th column is the delta between packets, you can see the 9, 10, 10, 9, 9, 14 millisecond delay. This is very fast!
   
   

  Please login or register to see this link.

 

 

However and here is the big however, The colour report is coming back about 6 seconds later ie. 15.466 (key released) vs 21.084 (colour report) and therein lies the problem..... a 6 second delay to sync the colour of lights via LUA

 

Please login or register to see this link.

 

 

 

I tested 2x different Fibaro RGBW 1 and they communicate in a different way. They send a "Color Switch Set" and guess what... it happens in about 160-250 milliseconds for the first report and then if you look at the second report together, they take no longer than about 300 to 450 milliseconds.

 

This type of performance is perfectly adequate for controlling groups of lights via scenes, but 6 seconds is not.

The RGBW 2 device does not appear to have been implemented well on yet another front.

 

 

Summary of issues / feature requests (for what it's worth):

 

1. Associations 

Bug1: Associations do not consistently work. They seem to work for a while after a while they break.

What does break mean? So far, I have tested that the colour keeps being sent from the master, but the brightness stops being sent.  

Despite any attempts, I have not been able to reproduce the original situation where the association was working. I wanted to watch Zniffer to see if anything happens when it changes to not working. Instead all I can see now in Zniffer is that the colour is sent to the "slave" device and that's about it. The slave device does not ever get a brightness setting anymore, so this is broken as you can never turn a slave on or off via a wall switch. You can only change its colour.

Bug 2: It takes far too long to set associations. On other modules, association updates from the BUI are sent to the device in seconds. With the RGBW 2 it takes minutes, as in 3-4 minutes when I have almost no other network traffic. There is something wrong here.

Bug 3: I have to click 2, sometimes 3 or 4 times on the save button before the association updates actually saves and the device window reloads.

Bug 4: While associations are being updated for a device the zwave network seems to be locked up. Maybe this is what always happens with association updates, but usually the updated happen in a few seconds. When it takes many minutes, the impact is noticeable.

Question: Ok, what is going on here? When I associate to an RGBW 2 module, 2 devices are also automatically selected for the association. In the image below you can see that the master device and the next device is selected. These are effectively the two devices before the actual end-user device. This did not happen on other modules. Even with the dimmer 2 module, which has a remote, only 1 other device was automatically ticked. Can you confirm that this is the expected behaviour?

 

Please login or register to see this link.

 

 

2. Rainbow mode 

a) Functionality improvement - Functionality has been detrimentally changed from RGBW 1. 

In HSB & White mode if the R, G and B channels are all zero when you click on IN1, all 3x channels are turned on at the same level to create a cold white. There is then no way to access rainbow mode from a wall switch. This is major flaw. With the RGBW 1 you could double click to get cold white, but when you click and held it would revert back to Rainbow mode. I don't understand why double click does not take you to the White channel and then click and hold rotate you through the colours. 

b) Feature request - It is beyond my understanding why Fibaro sell a device that can take 4x channels - R, G, B and W and yet rainbow mode does not allow access to the W channel. Please, please, please, when clicking on IN1 in HSB mode, let the last colour be the White Channel. I would prefer a completely different colour order, but it seems from previous conversations that this is not possible due to a regulation. I don't understand what the regulation is and it sounds very weird to me. Starting with red doesn't make sense for day to day use. Nor does ending with red if you double click... who uses red lighting in their house at Fibaro that makes it such an important colour.

c) Feature request - I guess the answer will be no, but if only we could change the order of colours in rainbow mode. I would ALWAYS start with the white channel or cold white if only R.G and B channels are connected. 

d) Feature request - speed of colour transition should be a user defined parameter

e) Improvement - What I love about the IN1 in HSB mode is that the colours change much faster. They may change a little too quick, but I would prefer it faster than at the speed of the RGBW 1, which was far too slow.

 

 

3 BUI Bugs

a) BUI within a room and in the devices, view does not update to reflect reality ie if a wall switch is pressed

b) BUI within a room and in the devices, view does not update to reflect a colour change, unless the brightness is changed after the colour change

c) Mobile app seems to suffer from the same issues as the BUI. I am using the original Android mobile app v1.27.0.0, which appears to be the latest on the Google app store

d) If you slide RGB or W on with brightness off, the device shows as on, despite being off. If you the slide back to 0 the device continues to show as being on.

There are other BUI errors, I have forgotten to document them all as they happened.

 

 

4) Brightness disassociated from RGBW channels

a) This makes little sense to me. With the RGBW 1, when you changed the RGB or W channel the brightness moved with it. It worked well for me. At a minimum it should be a user option to revert back to this functionality. As you would have seen, with the RGBW2 you have to select a colour AND a brightness to get the light to turn on... It's counterintuitive to me when different combinations of a channel colour and brightness result in the same level of output.

 

 

5) User-friendly wall switch control

I don't know anyone that wants to have to click on 4 buttons to control a single light, especially when you have multiple RGB/RGBW lights in a single room. Simply put the options should be:

a) One button operation for momentary switch - rainbow mode or brightness control. In rainbow mode start with the white channel, or if this is not possible end with the white channel. 

• Double click to max brightness
• Double click and hold could to access brightness mode i.e. dim up/down
• Triple click to access white channel or RGB cold white if connected to an RGB device

Through a single button you could control the entire device.

 

b) Two button operation for momentary switch - Rainbow mode for one button and brightness control for the second button. 

Two button mode would work similar to one button mode but with brightness accessed through the second button. 

TBH, if you modified the device to work in one button mode the way I described it, I'm not sure why anyone would need two buttons to control the device.

 

I know that only accessing Hue through a button does not allow changes in Saturation, however I don't know anyone that uses Saturation often; I don't use it at all. I think this level of control can be accessed through the BUI / mobile app. If you desperately wanted to include Saturation, then modify the two-button mode to work like one button, but one button controls Hue and the other Saturation. 

Finally, you could use the same logic as above to control all four channels from 2x buttons e.g. I think Hue and Brightness are most important, so B=Button, B1= Hue, B2 = Brightness, then Double click and hold B1 to increase/decrease Saturation and Double click and hold B2 to set RGB=0 and Increase/decrease the White channel. This would work for me!

In a) and b) above, the user should never be forced into a situation where they click to turn on a device and are stuck with cold white i.e. RGB all at the same value, AND they can never access rainbow mode without going to a device to adjust the RGB settings. This is a bad design.

There are options with the one and two button control where you could create a complete solution in a way that doesn't cover people's walls with switches and in a way in which I know people in my household may actuall use wall switches to control devices. They won't do it with 4 buttons per circuit.

 

EDIT: I have setup 2x button control throughout my house ~40 RGBW2 modules. I have had to write scenes to workaround all of the issues mentioned. It ain't pretty, but it works.

 

6) Colour report lag

This is a major issue. Having to wait 6 seconds to have a newly selected colour, from a wall switch, reported to the HC2 is too long. The RGBW1 did it in ~200 milliseconds. 

This bug needs to be fixed.

 

7) Press and hold to dim down - IN3 input from wall switch

If you press and hold to dim down, the light actually turns off rather than stops dimming at brightness value = 1. This is not a good user experience. The Dimmer 1, Dimmer 2 and RGBW1 do not operate this way. Dimming has to stop at value = 1.

PS: I found this to be the case with the Dimmer2... how on earth do you expect people to access the lowest light setting on their RGBW2 and Dimmer2's when clicking and holding turns the light off... it makes it s guessing game/game of skill to get the lights down low.

 

What to fix first?

This is a very important question and it all depends on what Fibaro intend on fixing.

 

• I spent a long evening writing LUA to control groups of RGBW modules as associations are broken. The code works barring issue 6) Colour report lag. If this was fixed, I would have a workable solution. It would not be completely desirable, but workable.

• Similarly, if associations are fixed then it will be a great way to reduce traffic (to the controller) when controlling groups of devices and simplify any LUA required to get functionality similar to what I have described above.

• Ultimately, I want two-button control, with Button1: Hue (including the white channel) and Button2: Brightness, and Saturation controlled through double click and hold would also be great to have as an option, as it would actually work for the entire product for all four channels. I'm really disappointed the RGBW 2 module didn't just do this out of the box.

• I don't understand how I can be in HSB mode, click on IN1 (Hue) and be locked into cold white (R, G and B, all stuck at the same value)

• Please fix the device before the BUI. I can live without a working BUI, but not without a working device.

 

There is a lot of feedback and quite a list of issues that I have raised, which is unfortunate as this means that the RGBW 2 has been sold as a production ready product when in fact it still needs A LOT of work.

 

------------------------------------

 

EDIT: 20.7.2020

 

I found 2x more bugs. 

- One is "requesting neighbours", the HC2 goes into an infinite loop during inclusion. I had to reboot the HC2 the first time to stop it. The second time after stopping inclusion, I added the device again and it stopped the message.

- There are constant errors appearing "application rejected request". I have never seen these errors before.

Please login or register to see this link.

Please login or register to see this link.

 

 

EDIT 28.7.2020 - API BUGS

EDIT:30.7.2020 -  Fibaro support cannot reproduce the following errors, so I'd take my conclusions with a pinch of salt for now. It may just be me and how I am doing it.

I'll continue testing and revert with an update when I get a chance

 

I have found more potential bugs. I say potential, as this is the first time I've used the /docs functionality, after @10der made me aware of their existence.  Thank you @10der. Again!

 

Bug A.1?

I found what looks like a bug. Maybe I'm doing it wrong.

When I test out the API/docs for my HC2, like this:

 

Please login or register to see this link.

 

Instead of the white channel being set to 255, it looks like a pseudo-white is being simulated by the HC2.... You can see it is setting R=254, G=199 and B=71, but not changing the white channel.

 

Please login or register to see this link.

 

What do I need to do to just control the WHITE channel?

 

Bug A.2?

In fact, I cannot seem to get the White channel to ever change values, no matter what I send to it e.g. 

 

{"args":[0,0,1,254]}
 

It appears that the HC2 is interpolating that 254 on the White channel should equal 254 on the blue channel as the result is 0,0,254,0

 

Similarly, if I send 0,1,1,254, I will get 0,254,254,0

 

Bug B.1?

Also, when I send arguments for other colours e.g. blue, no matter what value I send in the channel e.g.

 

{"args":[0,0,255,0]}

{"args":[0,0,1,0]}

 

The outcome is always that the RGBW2 module is set to the maximum value for that channel i.e. 0,0,254,0

 

Bug B.2?

If I send the same value to 2 or more channels e.g. 0,50,50,0. It does the same and maxes out the actual values received e.g. 0,254,254,0

 

Only when I send dissimilar values do I get the value I sent being received correctly e.g. 0,50,250,0

Try it out yourself and please get back to me if I am doing anything wrong.

 

 

 

EDIT: 30.07.2020

I raised a ticket with Fibaro Support some time ago. They have confirmed all of the issues I have raised, barring the API issues for which I have not received any reply.

I have been advised that a GIRA project has been raised which means someone will look into it. Unfortunately I do not know what "IT" is exactly.

 

@A.Socha

I have invested, literally days of my life on this one topic. I would be grateful if I was kept abreast of the remediation process and especially as to which features will be fixed, so I can plan ahead.

As always, I'm happy to chat further on any of the points raised with Support, however my most recent emails have gone unanswered.

 

 

------------------------------------------------------------------------------------------------------------------------------------------------------------------

SOME MORE INFO ON THE RGBW2 - INITIAL COMPARISON OF RGBW1 vs RGBW2

------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

In case you are migrating from RGBW1 to RGBW2 you also might want to read this post so you know what you are getting yourself into...

 

One of the big differences for me is that you have to triple click on the device to include (as in, you can't include from a wall switch anymore). I wasted many hours figuring this out and assuming the first 2x modules I bought from ebay were duds, when in fact they were not. On a positive note, inclusion is a charm with the RGBW2 modules. You only have to triple click once and sit and wait and it works EVERY time. What a change. What a relief.

 

Pity about the rest.

 

EDIT - more to add to the list:

- you cannot specify RGB vs RGBW, so even when you have an RGB module the W channel is present and of course this can and does cause no end of problem - this is available on the RGBW1

- you cannot specify a white only led strip, so you will see R, G, B, and W channels for a white only led and this causes no end of problem until you rewire it to hack a workaround

- you cannot specify custom programs - this is available on the RGBW1 - it means you have to spam your network to get simple programs to work, which if you know anything about zwave, you simply will not do as it will crash your system eventually if not straight away. Think Christmas tree lights throughout the house => dead zwave network if you have to run it manually, rather than with programs

 

EDIT 2- another to add:

- Device polling does not work. I poll the device through LUA or through the HC2 BUI and nothing returns to the BUI i.e. the current value does not return

 

 

Edited April 8, 2021 by alex88

[pflugj 13]

31 minutes ago, m.roszak said:

It is not directly a bug... actually  

Color components are separate thing from the brightness.
When you are reducing the intensity of the channels by button brightness stays as it is.

What we did in the firmware is that in case the device was turned off (brightness set to 0%) and then you will use the physical switch it turns on the selected color and restores the previously set brightness. 

So even if all color components are zero, the device is turned on if brightness > 0.
The Z-Zwave specification defines this behavior. 

Well, in my opinion:
A light that is:  NOT emitting light,  is OFF
At least it should show as OFF in the APP and dashboard

or even better when all channels are ¨0",   also set the brightness to "0"
... am I the only one??
 

Edited February 9, 2024 by pflugj
added suggestion

[m.roszak 542]

You are not, I actually agree with you.
The thing is that it is nothing new, it has been like that from the beginning.

We can't just set brightness to 0 (force it in the system to 0) as in the device firmware it is not 0, then - turning it on by "turn on" will do absolutely nothing. It will stay off as components are 0. 
If we send to the device brightness 0% when components are set to 0, it will be the same. Turn ON action will change the brightness but due to components set to 0 device still won't emit any light. 

I will talk with the team if there is anything we can do about it on the hub side (emulate something maybe?), the problem is that is how Z-Wave imagined it to work and we cannot change it in the device - it will be not compliant with the specification.

Output on the device is calculated as brigtness*colorComponent/100 where brightness gets values between 0 and 99, and color component 0 and 255. 

From the protocol level, brightness is something linked with the color components but it is not the same. 

You can read about it in the Z-Wave specification if you like.

 

[Fabir 67]

@m.roszak Thank you for the clarification. 

 

@pflugj

About the OFF indication. I don't remember how it was with firmware 5.0.  With firmware 5.1 and the latest hc beta firmware 5.152.24, it shows OFF in the RGBW controller and the Yubii App.

 

Please login or register to see this attachment.

[pflugj 13]

I dont see that :
In my dashboard (browser Firefox) the icons look like this:

Please login or register to see this image.

/monthly_2024_02/image.png.c9dc4ae0dda3bd97dfef3c62f76bdf26.png" />

 

but the light is OFF
'

 

in the Android App and the Apple App
it basically shows the same
 

All hc3 on firmware  5.152.24

 

What am I missing here?

Edited February 9, 2024 by pflugj

[m.roszak 542]

yep, in your case device is ON to 99% but with 0% components values. 

[pflugj 13]

I do not get it.

Quote

Output on the device is calculated as brigtness*colorComponent/100 where brightness gets values between 0 and 99, and color component 0 and 255. 

 

According to my calculations, using your formula:
Brigthness * colorComponent/100
99 x 0/100 = 0

 

What am I missing here??
🤔🫤

I would think the correct way, to calculate the colorComponent percentage would be:

 

RGBW[%]=(R+G+B+W) x 100 / 1020      ;(4 x 255 = 1020)

or
RGB [%] = (R+G+B ) x 100 / 765                 ;(3 x 255 = 765)

and then multiply this with the brightness[%}

[pflugj 13]

Maybe this spreadsheet sheds some light on the values, I would expect to see
for RGB & RGBW controllers

RED	GREEN	BLUE	WHITE	R+G+B VALUE	RGB COLOR [%]	R+G+B+W VALUE	RGBW Color [%]	Brightness [%]	OUTPUT RGBW[%]	OUTPUT RGB[%]
0				0	0	0	0	ANY	OFF	OFF
255				255	33.3	255	25	25	6.3	8.3
128				128	16.7	128	12.5	25	3.1	4.2
64				64	8.4	64	6.3	25	1.6	2.1
32				32	4.2	32	3.1	25	0.8	1.0
255				255	33.3	255	25	50	12.5	16.7
128				128	16.7	128	12.5	50	6.3	8.4
64				64	8.4	64	6.3	50	3.2	4.2
32				32	4.2	32	3.1	50	1.6	2.1
255				255	33.3	255	25	100	25.0	33.3
128				128	16.7	128	12.5	100	12.5	16.7
64				64	8.4	64	6.3	100	6.3	8.4
32				32	4.2	32	3.1	100	3.1	4.2
255				255	33.3	255	25	100	25.0	33.3
255	255			510	66.7	510	50	100	50.0	66.7
255	255	255		765	100	765	75	100	75.0	100.0
255	255	255	255	765	100	1020	100	100	100.0	100.0
128				128	16.7	128	12.5	100	12.5	16.7
128	128			256	33.5	256	25.1	100	25.1	33.5
128	128	128		384	50.2	384	37.6	100	37.6	50.2
128	128	128	128	384	50.2	512	50.2	100	50.2	50.2
64				64	8.4	64	6.3	100	6.3	8.4
64	64			128	16.7	128	12.5	100	12.5	16.7
64	64	64		192	25.1	192	18.8	100	18.8	25.1
64	64	64	64	192	25.1	256	25.1	100	25.1	25.1
32				32	4.2	32	3.1	100	3.1	4.2
32	32			64	8.4	64	6.3	100	6.3	8.3
32	32	32		96	12.5	96	9.4	100	9.4	12.5
32	32	32	32	96	12.5	128	12.5	100	12.5	12.5

[pflugj 13]

Sorry, 2nd row should look like so

RED	GREEN	BLUE	WHITE	R+G+B VALUE	RGB COLOR [%]	R+G+B+W VALUE	RGBW Color [%]	Brightness [%]	OUTPUT RGBW[%]	OUTPUT RGB[%]
0	0	0	0	0	0	0	0	ANY	OFF	OFF

Edited February 10, 2024 by pflugj

[Kage 37]

for me, there is no problem anymore, no reset or what so ever.

[m.roszak 542]

On 2/10/2024 at 10:47 AM, pflugj said:

I do not get it.

 

According to my calculations, using your formula:
Brigthness * colorComponent/100
99 x 0/100 = 0

 

What am I missing here??
🤔🫤

I would think the correct way, to calculate the colorComponent percentage would be:

 

RGBW[%]=(R+G+B+W) x 100 / 1020      ;(4 x 255 = 1020)

or
RGB [%] = (R+G+B ) x 100 / 765                 ;(3 x 255 = 765)

and then multiply this with the brightness[%}

 

 

let's make an example... Let's assume that output has a 0-255 range.

10%*255R/100= 25.5 Red channel output value...

50%*200B/100= 100 Blue channel output value...

If that helps, you can think that brightness takes values from 0 to 1 (with 0.01 step), then formula is just brightness multiplied by color component. 

As for your table, we are not showing the avarage output of the channels and we are not controlling it.
We got just brightness as a multiplier of the color components, that's it. 

Please login or register to see this attachment.

[pflugj 13]

Well, thanks for the detailed info.

Of course I do not question the way the color or brigthness has to be set.

I just believe that the "ON(xx%)" displayed is wrong!

Please login or register to see this image.

/monthly_2024_02/image.png.b76e4d18b683944eeeaa7eaf18f9531b.png" />while

The LIGHT is OFF but displays ON(99%).
That is at least misleading.

 

According to your formula from above:

Quote

Output on the device is calculated as brigtness*colorComponent/100 where brightness gets values between 0 and 99, and color component 0 and 255. 

or this
 

Quote

If that helps, you can think that brightness takes values from 0 to 1 (with 0.01 step), then formula is just brightness multiplied by color component.

You exactly proof my point with your formula - don't you?

The result of your formula:

brigtness*colorComponent/100
or
brightness multiplied by color component
 

0 x whatever = "0"
or

whatever x 0 = "0"

As mentioned before:
I do not question the way the RGB(W) light hat to be set.
I just have a problem with the "displayed %"
Currently I can have ALL lights "off",
but still showing me that ALL lights are "ON"
... and that is wrong - don´t you agree??

 

Cheers