[hue] Implementing "[discovery.upnp] Devices may apply a grace period"

[andrewfg]

BACKGROUND

The JUPnP library strictly follows the UPnP specification insofar as if a device fails to send its next 'ssdp:alive' notification within its declared 'maxAge' period, it is immediately considered to be gone. The Philips Hue can sometimes be late in sending its 'ssdp:alive' notifications even though it has not really gone offline. This means that the Hue Bridge is repeatedly removed from, and (re)added to, the InBox. There may be up to fifty such removals and (re)addings per day. This leads to confusion in the UI, and repeated logger messages.

SOLUTION PART A - CORE

I have made a Pull Request for a change in discovery.upnp that allows bindings to specify an additional grace period that the core UPnP discovery service shall wait before it removes a Thing from the Inbox. The change in [discovery.upnp] comprises an extension to the UpnpDiscoveryParticipant interface adding a new default int getRemovalGracePeriodSeconds() method. The change in [discovery.upnp] is implemented so that any existing binding inherits the default method, and its discovery behaviour is thus not changed.

SOLUTION PART B - HUE BINDING

This (HUE) binding overrides the default int getRemovalGracePeriodSeconds() method, and this asks for an additional grace period, which the core UPnP discovery processes will now honour.

REFERENCE
openhab/openhab-core#2144

Signed-off-by: Andrew Fiddian-Green software@whitebear.ch

[cweitkamp]

Build is green 👍🏼 . Two remarks.

wrt the configurationPid: we are using bunding.hue for factories and discovery.hue for discovery services. But in this case the second Pid is used for HueBridgeNupnpDiscovery. Don't know if it is really used over there or if we can remove it from that class and assing it to the UPnP discovery. That'll be a streamlined solution compared to other bindings.

We might ask @ghys if he has an idea how we can handle configuration settings for discovery services from the UI in the future.

[andrewfg]

ask @ghys if he has an idea how we can handle configuration settings for discovery services from the UI in the future

It seems to me that the way I have done it, is the solution to the problem. We could even cite the code from this binding in the respective documentation (.md) file.

[andrewfg]

We could even cite the code from this binding in the respective documentation (.md) file.

Oops. Actually I did that already!
openhab/openhab-docs#1478

[andrewfg]

we are using binding.hue for factories and discovery.hue for discovery services

@cweitkamp in case you missed it, the point of using the binding.hue config file in this case, (rather than the discovery.hue file), is that the binding.hue config file is read/write editable directly in the UI (whereas discovery.hue requires an external text editor).

And IMHO it doesn't matter how many classes in the same binding get config values from the same config file, as the respective name/value pairs won't clash.

[andrewfg]

Many thanks @cpmeister

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/org-openhab-binding-hue-internal-discovery-huebridgediscoveryparticipant-threw-an-exception/117247/4