-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bindings not suggested while expected #16023
Comments
Hi @lolodomo, was this when running the setup wizard, or afterwards when looking at the add-on store? I have noticed there is sometimes some delay in devices becoming visible, both with mDNS and UPnP. You could switch on debug logging for |
Also, perhaps a stupid point, but some of my devices are discoverable when in sleep mode (e.g. Oppo bluray player) but others have to be fully on (e.g. Sony Tv).. |
Both |
To be checked later for my TV and washing machine. If the Android app discovering mDNS devices find them, OH should also. I have to check. |
After turning on my TV and washing machine, the home connect and LG webOS bindings finally appeared. I will reinstall to see if they appear in the first setup step. |
On clean startup, if you imagine being a new user, and go through the process of creating a new user account, and then choosing your exact home location, it takes perhaps 1..2 minutes (??), and I have found that this is sufficient to discover all devices on my LAN. But if you 'crash' through those steps like an experienced user, it would take less time, and therefore risk not to discover everything. This is why the Add-on Store now has the extra 'Recommended Addons' tab; so you can check at that tab even later, at any time. |
^ |
Ok, I can confirm there is no problem at all with home connect and LG webOS bindings. The problem with freeboxos is confirmed. Even if I wait many minutes, it does not appear. Same for Android debug bridge and Android TV bindings. So it is mDNS discovery that does not work as expected. Waiting seems to not help. I have now started the server 30 minutes ago. If I restart OH, I can even get less suggested bindings. It's quite random. Is there a kind of time frame setup somewhere for mDNS ? Note that the freebox is detected very fast by the mDNS discovery app on my Android phone. PS: I also played with the advanced settings and enabling/disabling UPnP/mDNS seems to work even if there is a certain delay, this is not immediate. I can see jupnp bundle being uninstalled when I disable UPnP. |
After a second server restart, this time, I got no mDNS suggestions, only UPnP suggestions. I will wait 30 minutes... Edit: still no mDNS discovery at all. PS: what is funny is that UPnP discovery seems to work very well while mDNS discovery does not. |
PC on Windows 10. |
@andrewfg : did yo implement a kind of cache ? |
I have the feeling it is a startup problem. Maybe the order of bundles startup ? At startup, you get a random result regarding mDNS suggestions. |
If I got more results at the very first startup, it could be simply because the order of bundles is very different. Maybe a race condition somewhere. |
The finder subscribes to the Jmdns service. The Jmdns service probably does have some kind of cache (but I don't know the details). When the finder subscribes to the Jmdns service, the service responds immediately with a bunch of already found mDNS service types, and then over time it adds further mDNS service types as they are discovered in real time. If you think there is a bug, then it would help to see your trace logs. (@mherwege mentioned above which logger settings to make). |
I am certain there is a problem at server startup. Here are partial logs when starting the server. This case leads to 0 mDNS suggestions:
The mDNS client seems to be started and stopped several times. |
Here are logs partial logs for another example where only 2 mDNS suggestions are found:
|
It looks like the mDNS services are stopped before the device discovery can happen (not enough time). With chance, few devices can be discovered. And the service is finally restarted a last time immediately after.
It looks like it is the detection of network interfaces that triggers the restart of the mDNS services (one per interface) and the lost of device discovery. I guess the problem is rather in o.o.core.io.transport.mdns. |
The problem is probably here: When IP interfaces are detected, there is a call to close() and then start() leading to a removal of all JmDNS instances. They are recreated by the call to start() but apparently without detecting anything again. We have to implement a more clever onChange() method that will close only JmDNS instances that are really removed, and keep unchanged the instances already started for an interface still present. I will try during the weekend with a modified version of io.transport.mdns bundle. |
Fix openhab/openhab-addons#16023 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
With the proposed fix, it is now reliable. |
Fix openhab/openhab-addons#16023 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Tested again with snapshot 3763 and for me everything is working very well now with this new feature. |
It happens on a schedule, every minute. So there is a delay of up to a minute. |
I wrongly thought it was the time to install the bundle but I was asking myself why it was so long to uninstall it. |
I would be happy to. But I just did exactly the same thing as in the feature installer/uninstaller for add-ons (code is essentially copied from there). It also refreshes the configuration every minute, so has the same delay for installing/uninstalling an add-on. Is 1 minute really a big deal for this? |
Probably not. Most of users will probably not update these settings and as they are ON by default, that is ok. |
I just tested using snapshot 3760 the new binding suggestion feature.
Edit: 1 binding should have been suggested in my network but is not: freeboxos.
Others are suggested as expected.
Tested on my PC windows 10.
@andrewfg for information
The text was updated successfully, but these errors were encountered: