Reverting Osram bulbs from Advanced to Generic driver breaks level, CT, and color control with Java error

I've been having a lot of problems with Osram bulbs in Scenes and Groups -- devices in a group not responding to commands (regardless of whether or not Zigbee group messaging is on) and scenes misfiring level and color commands. All of the bulbs were using the Advanced Zigbee RGBW Bulb driver, and I remembered far fewer problems on the Generic Zigbee RGBW Light driver in the past, so I reverted them all to that driver (and did hit the configure button after doing so).

Now, the bulbs cannot be controlled at all within Hubitat for color, color temperature, or level, and Alexa can't change those properties either. Attempts to do so generate errors in the log:

2021-12-01 19:11:30.925 [error]java.lang.NumberFormatException: For input string: "0A00" on line 343 (method setColor)

Interestingly, grouped bulbs can still have those properties controlled via the group.

Returning the bulb to the Advanced driver restores functionality.

Here's the full set of errors with line numbers for each type of attempted operation:

[dev:84]2021-12-01 19:26:38.762 [error]java.lang.NumberFormatException: null on line 313 (method setLevel)

[dev:84]2021-12-01 19:26:35.710 [error] java.lang.NumberFormatException: For input string: "0A00" on line 453 (method setSaturation)

[dev:84]2021-12-01 19:25:56.061 [error] java.lang.NumberFormatException: For input string: "0A00" on line 343 (method setColor)

[dev:84]2021-12-01 19:25:38.387 [error] java.lang.NumberFormatException: For input string: "0A00" on line 491 (method setColorTemperature)

[dev:84]2021-12-01 19:25:34.010 [error] java.lang.NumberFormatException: For input string: "0A00" on line 343 (method setColor)

Are these errors being generated by commands sent from groups or commands run from the driver.

Try changing to the “device” driver to clean everything up, then to the generic one.

The errors appear in the log when the commands are run directly on the specific device page -- I assume that means run from the driver.

Ok, I can look into this.

1 Like

The issue changing back and forth between these drivers is that the preference setting for transition time needs to be saved on each change, an unfortunate situation with the preference setting having the same name between the two drivers, but one uses a hex value, and the other a decimal.

Two bugs smashed in one day. Nice work! Will that fix also make it into the next patch for 2.3.0?

The fix for changing drivers is for the user to reselect and save the transition time. If I rename the preference it will break the saved preference value for all users, so we can't do that.

If you change these drivers, just review and save the transition time preference, boom, done...