[hue] Hue bridge frequently added to the inbox #9357

lolodomo · 2020-12-13T10:16:31Z

OH3 snapshot 2066.

Looks strange to have the hue bridge frequently added to the inbox. I would expect it to be added only once.

2020-12-13 09:13:45.979 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:xxxxxxxx' to inbox.
2020-12-13 09:26:49.464 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:xxxxxxxx' to inbox.
2020-12-13 09:51:09.280 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:xxxxxxxx' to inbox.
2020-12-13 09:54:38.180 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:xxxxxxxx' to inbox.
2020-12-13 10:08:32.554 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:xxxxxxxx' to inbox.
2020-12-13 10:11:59.232 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:xxxxxxxx' to inbox.
2020-12-13 10:15:28.387 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:xxxxxxxx' to inbox.
2020-12-13 10:23:19.267 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:xxxxxxxx' to inbox.
2020-12-13 10:27:39.515 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:xxxxxxxx' to inbox.
2020-12-13 10:44:09.945 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:xxxxxxxx' to inbox.
2020-12-13 11:12:51.758 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:xxxxxxxx' to inbox.

The text was updated successfully, but these errors were encountered:

lolodomo · 2020-12-13T13:13:09Z

I am not yet sure it has a direct link but trying to analyze the problem I discovered that the serial number in the discovery has letters in lowercase while the property set by the thing handler for the serial number has letters in uppercase.
It could probably explained why a new entry is added in the inbox while I have already a thing for my hue bridge.

lolodomo · 2020-12-13T14:35:55Z

This is UPnP stuff which detects the hue bridge again and again.
I believe this is something new, something which did not happen with OH2.

andrewfg · 2020-12-30T16:21:09Z

Confirming that I see the same thing. But I don't think it is new to OH3. On OH2 I had 'solved' the problem by reducing the log level on the hue binding from 'INFO' to 'WARN' :) however I think it would be proper to solve it properly in OH3..

I am 99% sure that the issue is due to a wrongly defined representationProperty. It might just be the capitalization issue that you @lolodomo mentioned above. But I seem to recall having read somewhere that when a hue is discovered via the app it returns a unique id of some sort that is different than the id returned by the upnp discovery service. In other words it may be very similar to the problem with HP printers which I solved recently in #8810

=> I will have a look into it further in a day or two from now..

lolodomo · 2020-12-30T16:26:39Z

The log is coming from the core framework, not the hue binding.
I have this regular entry only for the hue bridge,

andrewfg · 2020-12-30T17:58:57Z

@lolodomo apparently your PR #9367 should have fixed this? However I am running the very latest SNAPSHOT of openHAB 3.1.0 (Build #2107) and I can see that #9367 has NOT solved the problem. And unfortunately, I can see that the #8810 fix is also apparently not working anymore (see below). So I guess that somebody has broken something else in the Inbox code. Or??

2020-12-30 16:19:25.241 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 16:19:26.439 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hpprinter:printer:HP_OfficeJet_Pro_8730__47D657___2_' to inbox.

andrewfg · 2020-12-30T18:03:37Z

Maybe it is a regression from your own recent changes on Inbox ??

andrewfg · 2020-12-30T18:07:12Z

And maybe related to my issue openhab/openhab-core#1835

lolodomo · 2020-12-30T18:17:10Z

My PR #9367 was absolutely not fixing this "issue" but something else (the representation property of a bridge thing).
What happens here is that the UPnP stuff is apparently rediscovering the bridge leading to the adding of the bridge thnig in the inbox (and as a consequence the INFO log from the core framework.

I think we should log in the hue binding the object provided by JUPnP to see if there are differences. If not then we will have to search in JUPnP library or in the openHAB core framework to understand why the hue bridge is discovered again and again.

lolodomo · 2020-12-30T18:18:25Z

And maybe related to my issue openhab/openhab-core#1835

The hue binding is not using mDNS but UPnP for its discovery service.

andrewfg · 2020-12-30T18:40:50Z

The hue binding is not using mDNS but UPnP for its discovery service.

Indeed. And?

But let's just restrict our discussion to the Hue..

I have been watching my Inbox live onscreen over some time, and I can see the Hue bridge regularly appearing and disappearing (screen shots below). So not only is the bridge being added (as in the log), it is also being removed.

If it were just a case of having a bad representationProperty then, since both discoveries would be using the same wrong code, the Inbox would still recognise both things as being identical, so it would not add it again. Indeed it would not remove it and add it again; it would simply ignore it.

This is why I have doubts about removeOlderResults() (regardless of whether the method is called in mDNS or UPnP discovery).

Now you see it..

And now you don't..

andrewfg · 2020-12-30T19:23:49Z

In my case I see the issue with Hue and HP Printer -- albeit with different frequencies. The Hue uses UPnP and AFAIK HP uses mDNS discovery..

2020-12-30 17:52:29.316 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 17:56:09.136 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 17:58:13.159 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 17:58:46.613 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hpprinter:printer:HP_OfficeJet_Pro_8730__47D657___2_' to inbox.
2020-12-30 18:01:55.738 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:05:29.703 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:07:47.541 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:11:11.389 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:14:36.175 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:16:42.680 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:20:28.048 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:22:32.648 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:26:12.746 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:28:22.338 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:30:29.094 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:32:51.564 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:35:01.724 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:38:45.810 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:41:09.801 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:43:14.464 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:45:20.282 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hpprinter:printer:HP_OfficeJet_Pro_8730__47D657___2_' to inbox.
2020-12-30 18:46:52.106 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:49:28.046 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hpprinter:printer:HP_OfficeJet_Pro_8730__47D657___2_' to inbox.
2020-12-30 18:50:05.802 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hpprinter:printer:HP_OfficeJet_Pro_8730__47D657___2_' to inbox.
2020-12-30 18:50:10.739 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 18:54:53.793 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 19:01:31.671 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 19:03:56.993 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2020-12-30 19:07:38.642 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.

andrewfg · 2020-12-30T19:32:05Z

PS I don't experience the issue (that I referred to in my Issue report) anymore with the Velux hub. This is because the original OH JmDNS discovery was not reliably getting the data from the hub (dropped packets or something), so I ended up changing to a binding specific hard coded mDNS solution #8777

lolodomo · 2020-12-30T19:32:43Z

We have to understand why a new discovery scan is triggered and then why sometimes JUPnP is no more providing the hue bridge. When that happens, of course, the hue bridge thing will be removed from the inbox due to removeOlderResults and that is what we expect (openHAB depends on what JUPnP foir UPnP discovery). In case this is what really happens, the real question is why the hue bridge is no more "seen" by the JUPnP library.
We have not enough logs in the core framework to make a better analysis.

andrewfg · 2020-12-30T19:35:36Z

(dropped packets or something)

Both mDNS and UPnP use the UDP protocol. It is almost guaranteed that sometimes, a scan will not succeed.

lolodomo · 2020-12-30T19:37:05Z

I am going to add few logs in the core framework (UPNP discovery service) to understand what happens.

andrewfg · 2020-12-30T19:39:58Z

Therefore, I guess one solution would be to make discovery results more 'sticky' so that an occasional failure to discover a device does not automatically lead to it being deleted.

Perhaps also it is worth noting that currently my Hue is running a mega "Hue Labs Colour Loop" for Christmas, which loads it quite highly, so it is probably dropping UDP packets more frequently. Or responding to them with a longer delay..

lolodomo · 2020-12-30T20:04:15Z

One thing I can see is that the timeout for the UPnP discovery is set to 5 seconds by the core framework. Maybe it is not enough.

andrewfg · 2020-12-30T20:18:13Z

The UPnP Specification for the M-SEARCH discovery process specifies the MX Header value as follows.

MX: Required. Maximum wait time in seconds. Should be between 1 and 120 inclusive. Device responses should be delayed a
random duration between 0 and this many seconds to balance load for the control point when it processes responses.

So yeah I would say that 5 is a tad too low. :)

andrewfg · 2020-12-30T21:40:48Z

But increasing MX is probably not sufficient. There will always be some results that get lost. So I suggest to add 'stickiness' so that results are cached for (say) 30 minutes..

lolodomo · 2020-12-31T09:18:14Z

As I guessed, the problem has nothing to do with openHAB but is a problem in JUPnP library (we can forget the OH timeout and removeOlderResults):

2020-12-31 09:52:41.650 [INFO ] [y.upnp.internal.UpnpDiscoveryService] - UpnpDiscoveryService remoteDeviceRemoved participant org.openhab.binding.hue.internal.discovery.HueBridgeDiscoveryParticipant thingRemoved hue:bridge:xxxxxxxxxx
2020-12-31 09:52:44.776 [INFO ] [y.upnp.internal.UpnpDiscoveryService] - UpnpDiscoveryService remoteDeviceAdded participant org.openhab.binding.hue.internal.discovery.HueBridgeDiscoveryParticipant thingDiscovered hue:bridge:xxxxxxxxxx
2020-12-31 09:52:44.792 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:xxxxxxxxxx' to inbox.

Look at the timing, JUPnP is notyfying the removal of the hue bridge and 3 seconds later its discovery. It looks like it is always the same pattern.
Next step will be to investigate in JUPnP library by enaling logging !

PS: I have other UPnP devices like Sonos for example and they are not affected.

andrewfg · 2020-12-31T10:01:51Z

I have other UPnP devices like Sonos for example and they are not affected.

Don’t get too hung up on this fact. As I say I have it now on HP Printer, and have also seen it before with earlier version of Velux. Also if the problem is in JUPNP then it might also be in JMDNS too.

check org.openhab.core.io.transport.upnp as it is the one calling remoteDeviceRemoved

Hmm. I would still suggest something like changing to removeOlderResults(now.minus(30 minutes))..

lolodomo · 2020-12-31T11:19:47Z

removeOlderResults is,used when the user triggers a manual scan through the UI (and when the binding is topped).
And that is interesting to have the immediate discovery result rather than waiting 30 minutes...
I let you go in this direction if you like but I am not convinced at all. Maybe you can convince maintainers of the core framework.

On my side, my priority is to understand what is wrong with the hue bridge discovery and to fix the issue (if there is really an issue we can fix). Maybe the issue is in the hue bridge firmware ?

lolodomo · 2020-12-31T11:47:40Z

@andrewfg : don't hesitate to try removing removeOlderResults and you will see that it does help at all with our current problem with the hue bridge.

andrewfg · 2020-12-31T11:55:58Z

And that is interesting to have the immediate discovery result rather than waiting 30 minutes...

You seem determined not to understand: removeOlderResults is intended to remove results that had previously been added to the Inbox. It does NOT have any function to prevent new discoveries from being added to it. So it certainly does NOT mean that the user has to wait for 30 minutes to see new results.

The scenario is as follows..

Time 0 minutes: OH starts a (first) discovery; the device responds; it is added to the Inbox => device is in Inbox.
Time 3 minutes: OH starts a (second) discovery; the device responds; it is added to the Inbox; older results than time 3 are removed => device is in Inbox.
Time 6 minutes: OH starts a (third) discovery; the device drops a UDP packet; older results than time 6 are removed => device is NOT in Inbox..
Time 9 minutes: OH starts a (fourth) discovery; the device responds; it is added to the Inbox; older results than time 9 are removed => device is in Inbox.

The error we are seeing is because of step 3. above. If instead removeOlderResults(now) you called removeOlderResults(now - 30) then you would NOT get this error. It would smooth out the random disappearances of the device..

andrewfg · 2020-12-31T12:02:45Z

Maybe the issue is in the hue bridge firmware ?

As I have said already many times: the problem is NOT unique to the Hue.

But it certainly could be a problem in the hue firmware. It could also be a problem in our routers. Or a LAN interference problem. IMHO the issue is that sometimes, some devices, will fail to respond to a UDP search inquiry. This is an expected result. But certainly some devices will fail more often than others. Apparently the Hue is such a device. My point is that just one single failure, from time to time, should NOT be a reason to chuck out a device from the Inbox. Since the chances are NOT that the device has permanently disappeared. But rather that the device has undergone a temporary lack of response to a specific search inquiry. Which is normal.

lolodomo · 2020-12-31T12:36:55Z

I am not alone, on your side, you seem determined not to understand that in my scenario, openHAB is never starting a new scan, it only listens to changes from the JUPnP library. This is what I verified withj my added log entries.

What your are talking about is a different problem, something that could happen when openHAB is starting a manual scan because the user requested it in UI. I don't say there is nothing to do with that, I just say that it is not the cause of MY current issue with the hue bridge described in this page.

What you are talkiong about (temporary hidden UPnP device) is I think something that should be handled (if not yet done) by the JUPnP library itself.

lolodomo · 2020-12-31T12:44:57Z

We should also check again if the behaviour is different in OH 2.5. I believe it is but it would be better to verifiy again to be certain.
I don't believe there were any change in JUPnP library between 2.5 and 3.0, except that we moved from Java 8 to Java 11.

lolodomo · 2020-12-31T12:47:53Z

@kaikreuzer : could you please confirm what are the changes in the JUPnP library between the one included in OH 2.5 and the one now included in OH 3 ? Is it only a compilation with Java 8 vs Java 11 ? Any other dependency in JUPnP was updated ? No change in code ?

andrewfg · 2020-12-31T14:43:28Z

it only listens to changes from the JUPnP library

Ok. So I think you are saying that JUPNP calls remoteDeviceRemoved() in OH? And OH removes the device from the Inbox? Or??

Quote from the jdoc of remoteDeviceRemoved()..

     * Called when a previously discovered device disappears.
     * This method will also be called when a discovered device did not update its expiration timeout
     * and has been been removed automatically by the local registry.

UPnP discovery actually comprises two sub-functions -- namely NOTIFY 'alive' (device unilateral multicast notification), and M-SEARCH (finder multicast query, device unicast response). If you think there is a problem in JUPNP then we need to debug which of these two sub-functions is actually failing (especially in the case of the Hue).

If a device sends a NOTIFY 'alive', it includes an HTTP header 'CACHE-CONTROL: max-age = seconds', and thus it commits itself to send a refresh 'alive' notification within that period. If such refresh notification does not arrive, then presumably JUPNP will make a remoteDeviceRemoved() callback to OH. (Obviously whether OH should always handle that callback, or whether it should apply 'stickiness' and ignore occasional dropouts is another discussion).
If a device responds to a first M-SEARCH query, and then fails to respond to a second one, then presumably JUPNP would also make a remoteDeviceRemoved() callback. Etc. etc. as above.

andrewfg · 2020-12-31T16:55:28Z

I have been running Wireshark to trace UPnP SSDP 'alive' notifications and compare them to OH Inbox logs. See the example below.

At 15:39:19.708 the Hue sent an 'alive' notification borderline late (by about 0.35 sec); which presumably caused JUPNP to make the remoteDeviceRemoved() callback to OH, to delete it from the Inbox. (??)
At 15:40:53, 15:42:11, and 15:43:35 the Hue sent three on time 'alive' notifications; but apparently JUPNP did not call OH to add it to the Inbox. (??)
At 15:45:26 the Hue sent another on time 'alive' notification; and consequently at 15:45:27 OH added it again to the Inbox.

15:34:58.218 [WIRESHARK] 192.168.1.108 239.255.255.250 SSDP 347 NOTIFY * HTTP/1.1
15:34:58.915 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.

15:36:15.839 [WIRESHARK] 192.168.1.108 239.255.255.250 SSDP 347 NOTIFY * HTTP/1.1 => OK [interval: 77 sec < max-age: 100 sec]

15:37:39.354 [WIRESHARK] 192.168.1.108 239.255.255.250 SSDP 347 NOTIFY * HTTP/1.1 => OK [interval: 84 sec < max-age: 100 sec]

15:39:19.708 [WIRESHARK] 192.168.1.108 239.255.255.250 SSDP 347 NOTIFY * HTTP/1.1 => BORDERLINE [interval: 100 sec ~< max-age: 100 sec]

15:40:53.114 [WIRESHARK] 192.168.1.108 239.255.255.250 SSDP 347 NOTIFY * HTTP/1.1 => OK [interval: 94 sec < max-age: 100 sec]

15:42:11.397 [WIRESHARK] 192.168.1.108 239.255.255.250 SSDP 347 NOTIFY * HTTP/1.1 => OK [interval: 78 sec < max-age: 100 sec]

15:43:35.037 [WIRESHARK] 192.168.1.108 239.255.255.250 SSDP 347 NOTIFY * HTTP/1.1 => OK [interval: 84 sec < max-age: 100 sec]

15:45:26.635 [WIRESHARK] 192.168.1.108 239.255.255.250 SSDP 347 NOTIFY * HTTP/1.1 => OK [interval: 84 sec < max-age: 100 sec]
15:45:27.359 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.

andrewfg · 2020-12-31T17:20:08Z

^
..to summarise: in this example the Hue was on time for 7 out of 8 of its 'alive' notifications; and a tad late on one of them; strengthening the argument for OH to be a bit more lenient before deleting previously known devices from the Inbox..

lolodomo · 2021-01-02T19:37:31Z

With my OH 2.5.9 server, this problem does not occur. So it seems something that appeared with OH3. Maybe something went wrong in the JUPnP library...

PS: my OH3 server is still connected to Wifi, I will move to a wired Ethernet connection to see if it changes something !

andrewfg · 2021-01-02T19:47:24Z

my OH3 server is still connected to Wifi

Mine too. Obviously over a (part) wifi link there is a higher risk of UDP packets being dropped. But my Wireshark measurements indicate the hue sending packets late rather than packets being dropped. PS the upnp spec requires devices to send several repeat packets just in case; but AFAIK the hue is not sending repeats..

lolodomo · 2021-01-03T09:44:59Z

Connecting my openHAB server to Ethernet (wired) rather than using Wifi solved the problem.

So I close this issue as the issue is not directly in openHAB code. An issue could be opened in JUPnP library to explain that the library is not fully reliable when used from a Wifi connection.

andrewfg · 2021-01-12T12:03:49Z

Connecting my openHAB server to Ethernet (wired) rather than using Wifi solved the problem.

Connecting to Ethernet did NOT solve it for me :( ..
..so I am reopening it again :)

2021-01-12 11:27:26.895 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2021-01-12 11:34:50.541 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2021-01-12 11:36:37.492 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2021-01-12 11:40:11.153 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2021-01-12 11:43:20.996 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.
2021-01-12 11:48:05.007 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'hue:bridge:0017882157c7' to inbox.

andrewfg · 2021-01-12T12:04:29Z

@lolodomo fyi..

hansie8888 · 2021-01-18T18:53:43Z

Hi there, Its look like I have the same issue with the HUE gateway added to the inbox
Hue devices are online but not working.
I migrated from OH2.5 to OH3.0 with a new installation and copying the config files.
Most of my devices (108 Things) are working. My OH3.0 is on debian in a VM.
Hopefully there wil be solution. (By the way, I am a big OH fan, OH3 looks very promising)

andrewfg · 2021-01-19T13:03:43Z

@hansie8888 thank you for your feedback; it confirms that at least three people have experienced the issue, so there is really something needing to be addressed.

The following summarises the findings of @lolodomo and myself..

It is not really an issue with the OpenHAB Hue binding resp. not something that can be fixed by changing the binding code.
It looks like an issue in the Hue Bridge (not refreshing its ssdp:alive notification within the Cache-Control: max-age time).
It might be fixable in the OH UPnP core (e.g. by more leniency on ssdp:alive notifications arriving slightly late).

lolodomo · 2021-01-19T16:24:45Z

In fact, I believe it should be handled by the JUPnP library, that means not in openHAB at all, neither core nor binding.

andrewfg · 2021-01-21T19:27:38Z

I believe it should be handled by the JUPnP library

@lolodomo I don't agree with you; the UPnP specificaton is quite strict in that if a device fails to send ssdp:alive in due maxAge time, then it is gone (black or white). The Hue does send its ssdp:alive but sometimes it is late. So I would have the core wait a further maxAge time before actually implementing the actual removal from the Inbox.

This CODE is how I would suggest to do it.

lolodomo · 2021-01-21T19:59:21Z

Don't hesitate to propose your change. It will be reviewed and commented by oh core framework maintainers.

andrewfg · 2021-01-22T12:36:11Z

Don't hesitate to propose your change

@lolodomo openhab/openhab-core#2144

lolodomo added the bug An unexpected problem or unintended behavior of an add-on label Dec 13, 2020

lolodomo closed this as completed Jan 3, 2021

andrewfg reopened this Jan 12, 2021

andrewfg mentioned this issue Jan 22, 2021

[discovery.upnp] Devices may apply a grace period for removal from the Inbox openhab/openhab-core#2144

Merged

cweitkamp added the PR pending There is a pull request for resolving the issue label Jan 30, 2021

cweitkamp linked a pull request Jan 30, 2021 that will close this issue

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

Merged

cpmeister closed this as completed in #9985 Feb 9, 2021

cweitkamp removed the PR pending There is a pull request for resolving the issue label Dec 23, 2021

[hue] Hue bridge frequently added to the inbox #9357

[hue] Hue bridge frequently added to the inbox #9357

Comments

lolodomo commented Dec 13, 2020 • edited Loading

lolodomo commented Dec 13, 2020

lolodomo commented Dec 13, 2020 • edited Loading

andrewfg commented Dec 30, 2020

lolodomo commented Dec 30, 2020

andrewfg commented Dec 30, 2020 • edited Loading

andrewfg commented Dec 30, 2020

andrewfg commented Dec 30, 2020

lolodomo commented Dec 30, 2020 • edited Loading

lolodomo commented Dec 30, 2020 • edited Loading

andrewfg commented Dec 30, 2020 • edited Loading

andrewfg commented Dec 30, 2020

andrewfg commented Dec 30, 2020

lolodomo commented Dec 30, 2020 • edited Loading

andrewfg commented Dec 30, 2020

lolodomo commented Dec 30, 2020

andrewfg commented Dec 30, 2020

lolodomo commented Dec 30, 2020

andrewfg commented Dec 30, 2020

andrewfg commented Dec 30, 2020

lolodomo commented Dec 31, 2020

andrewfg commented Dec 31, 2020

lolodomo commented Dec 31, 2020

lolodomo commented Dec 31, 2020

andrewfg commented Dec 31, 2020

andrewfg commented Dec 31, 2020

lolodomo commented Dec 31, 2020 • edited Loading

lolodomo commented Dec 31, 2020

lolodomo commented Dec 31, 2020 • edited Loading

andrewfg commented Dec 31, 2020

andrewfg commented Dec 31, 2020 • edited Loading

andrewfg commented Dec 31, 2020

lolodomo commented Jan 2, 2021

andrewfg commented Jan 2, 2021

lolodomo commented Jan 3, 2021

andrewfg commented Jan 12, 2021

andrewfg commented Jan 12, 2021

hansie8888 commented Jan 18, 2021

andrewfg commented Jan 19, 2021

lolodomo commented Jan 19, 2021

andrewfg commented Jan 21, 2021 • edited Loading

lolodomo commented Jan 21, 2021

andrewfg commented Jan 22, 2021 • edited Loading

lolodomo commented Dec 13, 2020 •

edited

Loading

lolodomo commented Dec 13, 2020 •

edited

Loading

andrewfg commented Dec 30, 2020 •

edited

Loading

lolodomo commented Dec 30, 2020 •

edited

Loading

lolodomo commented Dec 30, 2020 •

edited

Loading

andrewfg commented Dec 30, 2020 •

edited

Loading

lolodomo commented Dec 30, 2020 •

edited

Loading

lolodomo commented Dec 31, 2020 •

edited

Loading

lolodomo commented Dec 31, 2020 •

edited

Loading

andrewfg commented Dec 31, 2020 •

edited

Loading

andrewfg commented Jan 21, 2021 •

edited

Loading

andrewfg commented Jan 22, 2021 •

edited

Loading