Hue binding: wrong id for discovered lights

[lolodomo]

The thing type UID is missing for the discovered lights in the inbox.
I got hue::bridge1:1 and hue::bridge1:2

[kaikreuzer]

This is a feature, not a bug, see #1652 (comment).

@SJKA: The decision to remove the thing type there seems to lead to quite some confusion and issues...

[lolodomo]

Having the thing type in the discovered thing would help me set properly my thing file.
I am not sure if I have to use 0200 or 0210 (or even 0220) !

[kaikreuzer]

How about reading the docs? http://docs.openhab.org/addons/bindings/hue/readme.html#full-example

[lolodomo]

Already done but it does not help to identify at 100% the type of my light !

[maggu2810]

Isn't the model ID property enough to identify the light?
https://github.com/eclipse/smarthome/pull/1789/files#diff-8fa06d6d05ccc8c9a1724a0b84c61e5fR113

[kaikreuzer]

Properties are not shown on a discovery result and you cannot derive a thing type from it.
But @lolodomo, if you once accept the discovered bulb, the thing list will also show you its thing type. So you can delete the thing again and manually define it in the things file then.

[maggu2810]

Properties are not shown on a discovery result and you cannot derive a thing type from it.

You see, I have not used the Hue binding for a time and don't know if the model suffers the needs, so the real thing type does not need to be known 😉

Regardless of this use case:
Should we modify the Paper UI, so it shows the properties of the discovery result (the DiscoveryResultDTO contains the properties)?

[kaikreuzer]

No, I don't think there is much value in this (and it would rather cause irritation as some of the properties will be used for the thing configuration later on).
Discovery is not mean to be a tool to find the right content for a things file...

[maggu2810]

would rather cause irritation as some of the properties will be used for the thing configuration later on

Okay

Discovery is not mean to be a tool to find the right content for a things file...

That was never my intention. I don't talk about thing files.
If the discovery can already provide properties like vendor id, product id, model, serial number, remote id etc. I think it is good to know. At least something similar to the thing view page where I can look at the properties.
If my discovery mechanism shows me a lot of sensors of the same type, I perhaps need some informations to find the correct one. The UID should never be used to extract information, so do you think adding a lot of sensors only to find the correct one, is good?
Perhaps I am missing something here.

[lolodomo]

A table in the documentation showing what thing type to use for each hue light model would help a lot.
I could take the model id in the properties and then search in the documentation.

[lolodomo]

My light model id is LLC011. So what thing type should I use ? 0200 or 0210 or 0220 ?

[kaikreuzer]

It is 0200. You will find the types listed on http://www.developers.meethue.com/documentation/supported-lights (but you need to create an account there in order to get access).

[joergkling]

The correct thing type can be identified by checking the table listing the channels in the docu. I tried to explain this in the enhanced example section but obviously this needs some more work. Will do that in the next couple of days.

[joergkling]

BTW, can I suggest to remove one of the colons from the generated UIDs?

Current: hue::bridge1:1
New: hue:bridge1:1

Reason: The current naming approach is confusing as it looks like that something between the colons is missing.

[kaikreuzer]

BTW, can I suggest to remove one of the colons from the generated UIDs?

@joergkling This isn't possible due to the way the ThingUIDs are constructed (it must be clear that "bridge1" refers to a bridge and is not the id of the Thing.

But note that #1946 reverts the change in the light discovery in order to avoid such confusion; the discovered UIDs will now be hue:0200:bridge1:1 etc, so hopefully similar to what you would expect.

[joergkling]

great, this will also help explaining the manual thing definition in the documentation.