-
-
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
[nanoleaf] Suppress ipv6 addr in controller discovery #17724
Conversation
…overy Signed-off-by: Stefan Höhn <stefan.hoehn@nfon.com>
@kaikreuzer Can you review this. It would make sense to add this the milestone tomorrow as matter is coming soon which requires ipv6 and without this fix the nanoleaf binding isn't reliable anymore. |
…overy Signed-off-by: Stefan Höhn <stefan.hoehn@nfon.com>
Double check: does this apply to all nanoleave devices? All revisions and firmware? On my phone unable to fully asses the code change and don’t expect to have time before the milestone build |
Yes it does, it happens to all panels and canvases - so all "wall-mounted" devices (at least all that I have). By the way this way introduced with some firmware changes a while ago (see the link of the community discussion I added) when all of a sudden Nanolead added ipv6 support. So you may run on an older firmware? My devices are all on the latest one. It is not related to bulbs and other devices that are only matter/thread enabled. If have many different devices of the ones that the binding supports and it is pretty annoying. The main problem seems somehow burried in the fact that the device may get communications via both ipv4 and ipv6 and therefore there seems to be something like an "interference" which then makes it flapping and it goes ON and OFF. As I am not completely sure what the exact issue is, this is, for the time being, the easiest solution that fixes it. Maybe, in an upcoming release, I can figure it out and an idea would be that during discovery only one device creation is used, either ipv6 or ipv4 and as soon as this has been added the other will then be suppressed. However, this is a more tricky approach which I need to investigate. The only downside of this fix here is, that the binding doesn't support a device being used based on the ipv6 address which is probably not an issue. |
Ok thanks, please add a note to the readme.md about this ipv6 suppression. Otherwise LGTM. |
Signed-off-by: Stefan Höhn <stefan.hoehn@nfon.com>
Signed-off-by: Stefan Höhn <stefan.hoehn@nfon.com>
I added a note to the Readme. |
...n/java/org/openhab/binding/nanoleaf/internal/discovery/NanoleafMDNSDiscoveryParticipant.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise LGTM
Signed-off-by: Stefan Höhn <stefan.hoehn@nfon.com>
The nanoleaf binding becomes very unstable when run in an ipv6 environment (though ipv6 is required when using matter). This simple change ignores the (additional) ipv6 announcement of the nanoleaf controller which fixes online/offline flapping of the nanoleaf thing.
Also see https://community.openhab.org/t/nanoleaf-binding-may-fail-when-upgrading-to-the-latest-nanoleaf-firmware-because-of-ipv6/148152