Ignore functionality of discovery inbox

Development
1

Hi. I have a question about the “ignore” functionality of the discovery inbox. Does the representation property need to be globally unique, or does it only need to be unique for a given bridge thing?

Here is the problem. At the moment, the Lutron binding is not correctly designed so that discovery results for manually configured things will be ignored in the discovery inbox. At first glance, this should be easy enough to fix. A given Lutron bridge device (the hub/processor/router depending on the system) assigns each device in the system a unique ID number called an integration ID that is used to identify it. These remain constant when the system configuration changes. Each child thing in the Lutron binding (switches, dimmers, shades, etc.) must be configured with the proper ID. And in the discovery code, discovery results are already built using withRepresentationProperty(INTEGRATION_ID). So my thinking was that all I needed to do was slap a line like: <representation-property>integrationId</representation-property> in to each thing-type definition in the thing-types.xml file, and it should be good to go. Right?

Except… What happens when someone configures multiple bridges? This is unlikely with a RadioRA 2 or HomeWorks QS system, but it isn’t too uncommon with Caseta systems since they have a smaller maximum device count. With multiple bridges the IDs of devices on each bridge can, and likely will, conflict. From my own limited testing, it seems like if one bridge has a manually configured device, and a device with the same ID is discovered on another bridge, both discovery results will be ignored in the inbox. This isn’t what I want at all. It takes a minor annoyance and turns it into a potential support issue. Is this the expected behavior? If so, what is the best way to get around it? On some Lutron systems it is possible to get serial numbers for attached devices, but on others it isn’t. Do I need to try to “uniquify” device IDs in the representation property by prepending some bit of bridge information to them (e.g. a bridge device serial number, if I can get one)? Even this may be hard to do across all of the supported bridges. What have others done in this situation? This must be a problem for other systems as well.

2

Doesn’t the inbox use the full thing uid (binding:thing-type:bridgeuid:thinguid) for this? Then it shouldn’t ignore the discovered thing since the bridgeuid is different. If not I would consider this a bug in openHAB-core, and you should probably file an issue.

3

Thanks. Sorry, I’ve been distracted by other things. A discovery result certainly includes the bridge UID in it, so I would think the “ignore” code SHOULD take it in to account. It didn’t seem to be doing that in my (admittedly very brief) testing, though. When I get around to doing a better test, I’ll report back on what I find.

4

To investigate further, set org.eclipse.smarthome.config.discovery to debug logging (I assume you are working on 2.5.x? Otherwise org.openhab.core.config.discovery) and see what it outputs when you run discovery on the conflicting bridges.

5

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.