OH 5.1(?) Discovery bug (I think)

Development Add-ons
1

Hi All,

In a comment in a bug for an issue with the Roborock binding, it was commented that if an item is added manually, it is still discovered - which shouldn’t be happening.

I’ve looked at my code in openhab-addons/bundles/org.openhab.binding.roborock/src/main/java/org/openhab/binding/roborock/internal/discovery/RoborockVacuumDiscoveryService.java at login-fix · psmedley/openhab-addons · GitHub and it seems right.

I’ve also looked at Plex and Tesla - and similarly, they use the ‘representationproperty’ as part of the thinguid.

I can repeat the issue reported with roborock with Plex and Tesla. It ‘seems’ like if the ‘representation property’ is a config parameter, then it isn’t being respected.

Compared with a Tapo item, where the representation property is a thing property - and it works. With Tapo, if you manually create a thing with it’s IP address, when it goes online the mac address gets added to properties and it doesn’t get discovered.

Any thoughts?

Happy to create an issue if others agree this is a bug.

Thanks,

Paul

2

Hi @Paul_Smedley,

Interesting is the fact that an already ignored device still leads to a new item in the Things inbox, so maybe the ignored list is not considered but the existing Thing with Thing ID == DUID is.

The workaround is to use the DUID (device’s UID) as the Thing ID. In this case, the “reinvention” stops. So, the only limitation here is that we can’t use individual Thing IDs like rockyor so.

I would call it a minor bug.

3

Do you also set the property in your handler? When you define the thing manually, the representation property never gets set, unless you explicitly set a property with that name in your handler initialization.

4

It seems that:

doesn’t match:

5

Thanks @laursen this is the solution. I’ll fix this for roborock and also teslascope. The tesla binding isn’t mine but will look there too.