Things discovered but already configured

Hi all,

I have a hopefully simple question. I’m currently cleaning my openhab configuration and finally I have 6 things which are getting automatically discovered, although they are already configured:

This is my .things file:

Bridge harmonyhub:hub:Wohnzimmer [ host=“192.168.100.152”] {
device Harmony_AcerProjektor “Harmony Acer Projektor” [ id=“51645220” ]
device Harmony_AppleTV “Harmony Apple TV” [ id=“50181087” ]
device Harmony_NeetAVSwitch “Harmony Neet AV-Switch” [ id=“51645254” ]
device Harmony_Switch “Harmony Nintendo-Spielekonsole” [ id=“50181068” ]
device Harmony_TV50 “Harmony TV 50” [ id=“50180532” ]
device Harmony_SamsungDolby “Harmony Samsung Dolby” [ id=“50180531” ]
}

In the past I had “name” instead of “id”. I tought, the id could fix that topic, but it didn’t. When changing the bridge name to "harmony hub:device:Wohnzimmer as the discovery shows, the things will not be shown anymore in the discovered devices, but the bridge will not go online with this name, so nothing is working. I’m wondering about that, because I thougt the name is free to choose.

Does anyone knows, what going wrong here? The items are working as expected, but I want to get rid of them in my inbox…

I’m running on OpenHAB 3.1.1 in a docker environment on a raspberry pi 4. But this should not matter.

Thanks,
Denis

I got the same thing happening to me, discovery of things that already are defined (I usually do all my things manual anyways).
One workaround is to tag the once you do not want to see again as ignored:

image

This will hide them from your inbox.

After a quick look into the code of the harmonyhub binding I say it needs to define a representation-property for the things to prevent them from being added to the inbox again.

Hi, thanks for the answer.

@chrismast
I don’t want to simple ignore it using the UI. This has to be done everytime I Setup a new OH instance and this is what I don’t want to do by using only configuration files.

@cweitkamp
I read what you wrote and I also reviewed your link. But I absolutely don’t know what that means. I’ve never worked with such xml files. Could you please give me a bit more input how this works?

Thanks,
Denis

  • the developer of the binding needs to create the “xml” file defining the representation-property
  • the representation-property is a unique key to identify a thing uniquely e.g. host in case of a router
  • when the same key e.g. host=192.168.0.1 is found in you .things file it is clear that the autodiscover process found a duplicate in case of 192.168.0.1 is found to be a router thing
  • that means as long as it is not implemented in the binding itself you will see the duplicate in your inbox
1 Like

I have nothing to add. @Wolfgang_S explained everything.

ok, thanks for that information. So I have to live with the inbox items :frowning:

I can offer my help and can try to implement it. But as I am neither owning not knowing much about Harmony one have to tell what a unique identifier can be for the Bridge (Hub) - the IP address? - and the devices - the id? - I have no clue.

According to the CODEOWNERS file @digitaldan was involved in the implementation. Maybe we can ask him to give us a hint.

I can take a look over the weekend, indeed it does sound like i missed setting the representation-property and its gone unnoticed for a long time.

:+1:
That’s appreciated. Thanks for jumping in.

It looks like host should be used as representation property. I also have file-based configuration:

Bridge harmonyhub:hub:home "Harmony Hub" [ host="192.168.1.57", heartBeatInterval=30 ] {
    device lgtv "Harmony: LG TV" [ name="LG TV"]
}

For this configuration I only have one property, name, which is blank:

Found this in the code:

        // earlier versions required a name and used network discovery to find the hub and retrieve the host,
        // this section is to not break that and also update older configurations to use the host configuration
        // option instead of name
        if (host == null || host.isBlank()) {
            host = getThing().getProperties().get(HUB_PROPERTY_HOST);
            if (host != null && !host.isBlank()) {
                Configuration genericConfig = getConfig();
                genericConfig.put(HUB_PROPERTY_HOST, host);
                updateConfiguration(genericConfig);
            } else {
                logger.debug("host not configured");
                updateStatus(ThingStatus.OFFLINE, ThingStatusDetail.CONFIGURATION_ERROR, "host not configured");
                return;
            }
        }

So it looks like host will be available always. Only slight inconvenience might be users configuring a hostname when discovery would find an IP address.

Of course must be tested with both UI-based configuration and file-based configuration.

Best regards,
Jacob Laursen

Yeah, thats my comment since i am the one who wrote the binding :slight_smile:

1 Like

See [harmonyhub] Adds a RepresentationProperty to discovery to avoid duplicate inbox entries by digitaldan · Pull Request #11941 · openhab/openhab-addons · GitHub

The device UUID will uniquely identify a HarmonyHub during discovery. When a device connects and establishes its first ping message it will retrieve this UUID value and save it as a property, so this will work for existing hub things that are either manually configured through a file, or auto discovered.

We are not using IP/HOST address as a representational property as an IP/HOST is likely to change for most users and are not a unique identifier for a hub.

1 Like