OH 3 - Fibaro RGBW Controller 2 - incorrect dimming / colorpick

Setup, Configuration and Use Beginners
1

Hi OH Community,

since 1 year I’m running OH on an RasPi 3, it’s quite callenging, when doing new stuff, as I am a real beginner.

I have some Z-Wave: Danfoss heatings, 2 plugs, 1 light and everything is running as intended. Some rules with time, some movement detection… all good.

Now I bought an LED strip and the Fibaro RGBW Controller 2.

Good news: The thing is included with all channels and looks really good.
But: I have an issue, when I change the color ( via sitemap, element colorpicker ), the color changes, but it “hops back” near to the old value.So, when I change from blue to green, the light changes in reality, but in the App, it is still green ( but not the very same green ).

I have this log, First line to see the latest state:

2021-02-18 21:30:51.879 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘LichtLED_ColorControl’ changed from 123,97,42 to 135,96,46
2021-02-18 21:30:56.003 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘LichtLED_ColorControl’ received command 235,90,46
2021-02-18 21:30:56.028 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘LichtLED_ColorControl’ predicted to become 235,90,46
2021-02-18 21:30:56.038 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘LichtLED_ColorControl’ changed from 135,96,46 to 235,90,46
2021-02-18 21:30:56.753 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘LichtLED_ColorControl’ changed from 235,90,46 to 127,95,40

So, the light was (green): 135,96,46, received command 235,90,46. The physical light switched to the correct color (blue), but the last line: the value is now 127,95,40 ( slightly another green ), which can only seen in the App / Desktop colorpicker. The light itself remains blue.

Sorry for the long post, I have potatoes, if needed.

I’m quite sure, there is something, I do not know yet, maybe the device is reporting back a kind of intermediate position? What can I do? Thanks in advance.

Martin

2

I assume, you are using the channel “color_color” for the colorpicker? I use “color_color1” and it works as expected.

3

Hi Stefan,

at the brginning, I tested the “color_color”, but it did not really work. After changing to “color_color1”, I have the rusult described above.

4

Hi Martin,

then we have a difference in our systems we need to identify, so we can compare and find out what might be the cause of your issue.
Which OH version do you use? Do you have a snapshot version of the Z-Wave binding in use or is it the one that came with the release you use?

5

Hi Stefan,

I switched to OpenHab 3.0.1, Release Build about 3 weeks ago.
When I was setting up the system ( OH 2.4 or 2.5 ?? ), I used the “standard” Z-Wave binding, which was offered in the bindings menu.

I have no real idea, which hint could be helpful, but: The device needs some time to change the color. Some (Somfy) roller shutters send back their position two or three times while running, does Z-Wave similar things?

Maybe anyone has a good idea for a kind of test?

6

Sending intermediate position states when running is a normal rollershutter feature. Which makes sense as the need a certain time until the command for opening or closing is completed. Mine does it also, it is Z-Wave controlled.

When you changed from OH 2.x to OH3, did you an upgrade of the 2.x installation or was it a “clean” 3.0 installation?

7

OK, I thought, this is some special feature of Somfy, as they are the only roller shutters, that can count their rotations and send that back.

I made an upgrade of my existing installation with some paste & copy Linux commands.

I just tried with a simple rule, a switch sends a command and I got the same result back. I cannot really figure out, whats happening here.

8

I experimented today as I was not really sure my RGBW-Controller thing was a “takeover” from OH 2.5 (=migrated) or newly defined on OH3.0. To have a clear situation I did the following:

  • saved the configuration parameters of the thing to have a reference (just a “save page as” from the browser to files)
  • commented all the relevant item definitions in my items file, hence breaking the links between the items and the thing definition
  • deleted the RGBW thing definition in the GUI (NOT excluding the device, just a deletion of the thing, the node remained to be a part of the Z-Wave network!)
  • stopped OH
  • executed a “sudo openhab-cli clean-cache” to be sure that no data remained from the configuration that existed up to this point (well, the Z-Wave XML file for the node was left intact)
  • started OH again, waited until it settled, stopped again and started a second time (two rounds so the second one was a system restarting with a newly built cache from the first round)
  • the RGBW thing was discovered automatically and shown in the inbox
  • redefined the thing with its old name (this step ensured the thing definition was definitely based upon the Z-Wave database that came with OH3)
  • checked the configuration of the thing against what I stored in the first step (everything was configured as before, I assume the settings came from the XML file)
  • re-enabled the relevant item definitions by removing the comment markers in the items file
  • checked the links between the item definitions and the thing in the GUI (everything fine as no name or ID changes occured)
  • as a last step I restarted OH again to have a clean startup

Afterwards I checked the behaviour of the colorpicker: I did not see effects as the ones you described. The color followed the picker mostly without a noticable lag. A few times it took a second before the color changed as intended. Maybe other devices talked to the controller at that times.
When I changed colors abrupt (e.g. full red to full green or something similar) the color changed in two or three steps, mostly showing a kind of white für a brief period of time before changing to the desired color. I assume there were several color commands being sent when the picker was moved with the mouse, not only one. But that is different to what you described.

My conclusion at this point: the database entries that come with OH3 are fine for this device. Based on these definitions the device can be controlled as intended.

That brings us back to your description and the search for a reason that causes the behaviour you see:
I count 23 Z-Wave devices in my setup, so from a number perspective our setups are similar in size. But the structure of the network can be very different. My RGBW controller sits app. 2m from the controller with no real (radio) obstacles inbetween. What does it look like in your setup? Do the controller and the RGBW device have a direct route or is communication routed via another device?
Do you have stale Z-Wave things in your setup? Nodes that should not exist anymore? (If you see unknown Z-Wave devices in the inbox and you click to “ignore” them, you most likely have some of these ghost nodes). They can play a big role in disturbing the Z-Wave communication and should be deleted from the Z-Wave network (=from the controller). An arcticle how to do that can be found here:
how-to-delete-a-dead-node-from-a-zwave-stick

9

Hi Stefan,

Thank a lot for your time and your testing!!

In the meantime, I integrated a second controller (the same: Fibaro RGBW Controller 2 ) and it bevaves exactly the same way. According to the network map, 1 receiver is directly connected to the controller, the other is connected via a plug.

I have “only” 2 Plugs as 230V devices, so I unplugged them: same behaviour. ( I have no dead devices at all, but a smoke detector and a Fibaro Multisensor are included as well )

The second receiver is on “short cables” at the moment, very next to me and next to the controller: same behaviour.

Maybe a clean, new setup would help… maybe it’s this noname- controller ( although everything else works ). Is there no chance to find out, “who” sends that command / sets that last value all the time?

If you have any tests, that I could perform, please let me know.

10

To be honest, I’m running out of ideas. But there is still hope. I suggest two things:

  1. Tag your posting with “zwave”. That might attract others with more ideas and/or knowledge.
  2. Try to set logging for the Z-Wave binding to DEBUG level and produce logs during the time when you recreate the behaviour. See here how to achieve that.

Post the logfiles here so they can be checked. You can do it yourself as well, using the log viewer that the maintainer of the binding offers for such situations.

11
20:36:18.240 16 COMMAND RECEIVED zwave:device:ea3d687c:node16:color_color1 ON [OnOffType]
20:36:18.263 16 TX REQ SendData 65 MULTI_CHANNEL_CMD_ENCAP EP-1 -> EP-1 SWITCH_MULTILEVEL_SET 99% ACK AUTO_ROUTE EXPLORE
20:36:18.280 16 RX RES SendData 65 ACCEPTED BY CONTROLLER 1 /128
20:36:18.433 16 RX REQ SendData 65 ACK RECEIVED from device in 170ms 0 /128
20:36:27.365 16 RX REQ ApplicationCommandHandler MULTI_CHANNEL_CMD_ENCAP EP-1 -> EP-1 METER_REPORT ELECTRIC_W 0 /128
20:36:27.395 16 STATE UPDATE zwave:device:ea3d687c:node16:meter_watts1 39.5 [DecimalType]
20:36:27.600 16 COMMAND RECEIVED zwave:device:ea3d687c:node16:color_color1 112.941177,100.000000,100.000000 [HSBType]
20:36:27.697 16 TX REQ SendData 66 MULTI_CHANNEL_CMD_ENCAP EP-1 -> EP-1 SWITCH_COLOR_SET WW=0 R=29 G=255 B=0 ACK AUTO_ROUTE EXPLORE
20:36:27.710 16 RX RES SendData 66 ACCEPTED BY CONTROLLER 0 /128
20:36:27.883 16 RX REQ SendData 66 ACK RECEIVED from device in 186ms 0 /128
20:36:27.938 16 TX REQ SendData 67 MULTI_CHANNEL_CMD_ENCAP EP-1 -> EP-1 SWITCH_COLOR_GET WARM WHITE ACK AUTO_ROUTE EXPLORE
20:36:27.959 16 RX RES SendData 67 ACCEPTED BY CONTROLLER 0 /128
20:36:28.108 16 RX REQ SendData 67 ACK RECEIVED from device in 170ms 0 /128
20:36:28.241 16 RX REQ ApplicationCommandHandler MULTI_CHANNEL_CMD_ENCAP EP-1 -> EP-1 SWITCH_COLOR_REPORT WARM WHITE=0 0 /128
20:36:28.314 16 TX REQ SendData 68 MULTI_CHANNEL_CMD_ENCAP EP-1 -> EP-1 SWITCH_COLOR_GET GREEN ACK AUTO_ROUTE EXPLORE
20:36:28.332 16 RX RES SendData 68 ACCEPTED BY CONTROLLER 0 /128
20:36:28.518 16 RX REQ SendData 68 ACK RECEIVED from device in 204ms 0 /128
20:36:28.661 16 RX REQ ApplicationCommandHandler MULTI_CHANNEL_CMD_ENCAP EP-1 -> EP-1 SWITCH_COLOR_REPORT GREEN=255 0 /128
20:36:28.718 16 TX REQ SendData 69 MULTI_CHANNEL_CMD_ENCAP EP-1 -> EP-1 SWITCH_COLOR_GET BLUE ACK AUTO_ROUTE EXPLORE
20:36:28.731 16 RX RES SendData 69 ACCEPTED BY CONTROLLER 0 /128
20:36:28.948 16 RX REQ SendData 69 ACK RECEIVED from device in 230ms 0 /128
20:36:29.091 16 RX REQ ApplicationCommandHandler MULTI_CHANNEL_CMD_ENCAP EP-1 -> EP-1 SWITCH_COLOR_REPORT BLUE=175 0 /128
20:36:29.135 16 TX REQ SendData 70 MULTI_CHANNEL_CMD_ENCAP EP-1 -> EP-1 SWITCH_COLOR_GET RED ACK AUTO_ROUTE EXPLORE
20:36:29.146 16 RX RES SendData 70 ACCEPTED BY CONTROLLER 0 /128
20:36:29.370 16 RX REQ SendData 70 ACK RECEIVED from device in 235ms 0 /128
20:36:29.511 16 RX REQ ApplicationCommandHandler MULTI_CHANNEL_CMD_ENCAP EP-1 -> EP-1 SWITCH_COLOR_REPORT RED=159 0 /128
20:36:29.538 16 STATE UPDATE zwave:device:ea3d687c:node16:color_color1 130,37,100 [HSBType]
20:36:29.541 16 STATE UPDATE zwave:device:ea3d687c:node16:color_temperature1 0 [PercentType]
20:36:32.982 16 COMMAND RECEIVED zwave:device:ea3d687c:node16:color_color1 OFF [OnOffType]
20:36:33.013 16 TX REQ SendData 71 MULTI_CHANNEL_CMD_ENCAP EP-1 -> EP-1 SWITCH_MULTILEVEL_SET 0% ACK AUTO_ROUTE EXPLORE
20:36:33.037 16 RX RES SendData 71 ACCEPTED BY CONTROLLER 0 /128
20:36:33.183 16 RX REQ SendData 71 ACK RECEIVED from device in 170ms 0 /128

OK, what I see, is:

20:36:27.600 112.941177,100.000000,100.000000; which is the command, I gave. Almost perfect green with full saturation and brightness.
20:36:29.538 130,37,100 [HSBType], which is another green, less saturation…

And this second one is the position within the App. The physical light remained in the same color.

Thanks so much Stefan. If this does not attract others… then I will live with that behaviour or maybe a complete fresh install / another controller, if I have some time/money :slight_smile:

12

If you still have the (unfiltered) logfile, attach it here as it is. It may contain information that seems to be unimportant but is relevant.

13

Hi Stefan,

these two seconds would be 55.000 characters. Is this OK or will I be banned, if doing that? :slight_smile:

It could be, that I found something, if you need more lines, let me know:

2021-03-02 20:36:29.518 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2021-03-02 20:36:29.519 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Application Command Request (ALIVE:DONE)
2021-03-02 20:36:29.521 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: resetResendCount initComplete=true isDead=false
2021-03-02 20:36:29.523 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
2021-03-02 20:36:29.525 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: Incoming command class COMMAND_CLASS_SWITCH_COLOR, endpoint 1
2021-03-02 20:36:29.527 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 16: SECURITY NOT required on COMMAND_CLASS_SWITCH_COLOR
2021-03-02 20:36:29.528 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 16: Received COMMAND_CLASS_SWITCH_COLOR V3 SWITCH_COLOR_REPORT
2021-03-02 20:36:29.530 [DEBUG] [.commandclass.ZWaveColorCommandClass] - NODE 16: Color report RED 159
2021-03-02 20:36:29.532 [DEBUG] [.commandclass.ZWaveColorCommandClass] - NODE 16: Color report finished {WARM_WHITE=0, GREEN=255, BLUE=175, RED=159}
2021-03-02 20:36:29.534 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Got an event from Z-Wave network: ZWaveColorValueEvent
2021-03-02 20:36:29.536 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Got a value event from Z-Wave network, endpoint=1, command class=COMMAND_CLASS_SWITCH_COLOR, value=0
2021-03-02 20:36:29.538 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Updating channel state zwave:device:ea3d687c:node16:color_color1 to 130,37,100 [HSBType]
2021-03-02 20:36:29.541 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Updating channel state zwave:device:ea3d687c:node16:color_temperature1 to 0 [PercentType]
2021-03-02 20:36:29.544 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Commands processed 1.
2021-03-02 20:36:29.546 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@b853a8.
2021-03-02 20:36:29.548 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Command verified org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@b853a8.
2021-03-02 20:36:29.549 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: notifyTransactionResponse TID:57974 DONE
2021-03-02 20:36:29.552 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2021-03-02 20:36:29.554 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1
2021-03-02 20:36:29.559 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2021-03-02 20:36:29.560 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty

14

To be honest, I do not know what limits apply for uploads here. But I assume an upload would be blocked if it is too big.
I cannot see anything from the two seconds log you posted. Others might be able to interpret it better than me.