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.