[netatmo] Discovered things not attached to bridge (wrong bridge UID)

[lolodomo]

The binding is discovering a person thing. When I add it, the thing does not initialize ONLINE because the parent bridge is not defined. I say "no more" because I have the feeling that it was working 1 week o r2. Maybe there is a recent change that broke that.

I have only tested with a Person thing, not with other things.

@clinique for information.

[clinique]

I have modified discovery (thing Id generation) in the siren PR. Can you see if it works fine with it ?

[lolodomo]

I have also tested with the jar built from the siren PR but same result, the thing created through discovery has no bridge set.

[clinique]

Can you please check if the bridge is wrong ? Go in the thing, then 'Code' tab

[lolodomo]

Good remark. I thought it was not set but looking at the code tab, I see it is:

bridgeUID: netatmo:home:compte:xxxxxxxxxxxxxxx

while my home thing, defined in a configuration file, has this id:

UID: netatmo:home:compte:maison

So the problem is that the discovery code considers the ID returned by the API and not the real bridge UID.

[lolodomo]

I understand clearly why the code leads to this situation. The difficulty is the two levels of bridges in the thing hierarchy (hierarchy with a total of three levels). There is no problem for all things that are at the second level of the hierarchy (weather station for example). There is a problem for any thing that is at the third level of the hierarchy (camera, weather module, ...). I think there is a solution consisting in searching if a thing already exists as child of the account bridge and then then consider its UID.

[clinique]

The problem comes from the fact that you're mixing unmanaged things with your own naming, toward dynamically created things with a different naming rule. I'm not sure this is really a bug or an edge case. The siren PR may propose the beginning of a solution for this by introducing a map of created bridges with id as the key. It could be prepopulated with existing things..

[lolodomo]

The problem would be exactly the same with managed things in case you provide a thing ID that is not the ID from Netatmo. You can do that with MainUI.

I will propose a fix later after your siren PR is merged.

[lolodomo]

Finally, this is not clear for me if this is something to solve in the binding itself. I tried to use the feature in MainUI allowing to approve and set the ID of the thing. I hoped I could attach the bridge at this point but unfortunately you can only set the final ID of the thing UID. You still have the option to update the bridge in the thing after approving the discovery result.

[clinique]

The binding itself makes good discovery based on its own logic. If someone wants to change ids it's on its own purpose to solve devices hierarchy. I would not say we've got to implements counter measures in the discovery process/

[lolodomo]

I believe you're right.