[homematic] Invalid ID for hue integration causes errors

[LosPommos]

I am using the new (beta) hue integration in my CCU2. After pairing the hue bridge and the CCU2 the hue bridge (and the associated devices) show up in the CCU device list. Unfortunately the hue bridge is added in the CCU with the following ID: "HU-Philips hue" The ID can not be changed in the CCU, and contains a whitespace.

Expected Behavior

Everything keeps working, even with a hue bridge paired with the CCU2. Hue devices can be used in openhab.

Current Behavior

The binding doesn't accept the hue bridge as valid device and shows the following error: [ERROR] [very.HomematicDeviceDiscoveryService] - UID segment 'HU-Philips hue' contains invalid characters. Each segment of the UID must match the pattern [A-Za-z0-9_-]*.

Unfortunately this error seems to mess up some more things, as the Gateway-Extras are not working any longer. Log: [hingStatusInfoChangedEvent] - 'homematic:GATEWAY-EXTRAS-CCU:ccu:GWE00000000' changed from OFFLINE (CONFIGURATION_ERROR): Device with address 'GWE00000000' not found on gateway 'ccu' to UNINITIALIZED

After deleting the hue devices in the CCU everything is working again in openhab without any configuration changes in openhab! So the hue integration in the CCU seems to be the root problem. (probably the whitespace in the ID)

Possible Solution

Replace the whitespace in the device id by "_" as it is done for variables.

Steps to Reproduce (for Bugs)

1. Pair a hue in the CCU.
2. Try to use GATEWAY-EXTRAS in openhab.

Context

-

Your Environment

CCU2 Firmware:2.31.25 XML-Api: 1.15 Cux-D: 1.12 Openhab: 2.2 (short test on 2.3 showed same behaviour)

[MHerbst]

We already had a quite similar problem with the Lightify support by the CCU (see https://github.com/openhab/openhab2-addons/issues/2373). Is there a special reason why you are trying to use the hue bridge via the Homematic CCU? I would recommend using the openHAB HUE binding because it is tailored to the HUE functionality and I would expect that this binding supports the HUE bridge better.

[LosPommos]

The idea was to use both integrations at the same time. Some logic is integrated in the CCU, which allows fast reaction for CCU and hue lights. (e.g. "all off" will be switched directly from the ccu, not via openhab) Especially, if the logic is done via variables, which are syced quite slowly via GATEWAY-EXTRAS, this will be more convenient for the user. All other logic will be integrated in openhab.

Because the CCU hue binding is not bi-directional i even have to sync the real state via openhab into a variable to know, if a hue light is on or off in the CCU. (i could turn off the hue lamp vie hue app, after turning it on via homematic and homematic wouldn't know about it)

[MHerbst]

The Hue supports seems to be quite limited if it does not support bi-directional communication. What do you think about adding Hue support via CCU to the binding, @gerrieg

[kaikreuzer]

I am also not too fond of the idea to expose hue lights from the CCU to openHAB. There is nothing against having hue configured in the CCU to be used in scripts and "all off" scenarios, but I do not really see a reason why this would require exposing the hues through the binding.

But wrt this issue, if we decide to not support them as a "Thing", it should clearly be filtered out from the discovery and not result in any errors in the log.

[LosPommos]

I also don't think the hue lights from the CCU need to be exposed to openhab. It is much better to use the openhab hue binding directly, if you want to use the hue system in openhab (and use the benefits like the bi-directionality in openhab). An error-free co-existence for both bindings (in openhab and in the CCU) would be absolutely sufficient.

[gerrieg]

@LosPommos Can you please send me a full startup TRACE log? (see docs) I need to see the exact Hue implementation in the CCU.

[maniac103]

Is the 'invalid ID' issue the one fixed in #3184?

[LosPommos]

@gerrieg I just sent you the startup TRACE log via Email.

[LosPommos]

@maniac103 i just tried the snapshot build, but the problem still persists

[LosPommos]

Thanks, current snapshop is working again!