core
core copied to clipboard
Nanoleaf Skylight "unavailable" - even though it isn't!
The problem
I received a Nanoleaf Skylight last week. Since them HA integration has been a bit of hit and miss. Multiple times a day the light would become "unavailable" as reported by the Nanoleaf HA integration.
Thing is: It isn't!
I can still control the light through the app or even through HA itself over the Homekit integration (which unfortunately does not support the build-in scenes, so its not really a work around).
I do think this is API-related somehome, because - while Homekit always works - when I start the smartphone app, I can see the light listed there also as "unavailable". Then the app seems to do something (some kind of discovery perhaps?) and after a second or so the light is reported as online. After letting the app do its work, its also available in HA again.
As for the network side: I can always access the light through its IP without any issues - regardless of the presumed state by HA/the app.
What version of Home Assistant Core has the issue?
core-2024.5.5
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Nanoleaf
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
Hey there @milanmeu, mind taking a look at this issue as it has been labeled with an integration (nanoleaf) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of nanoleaf can trigger bot actions by commenting:
@home-assistant closeCloses the issue.@home-assistant rename Awesome new titleRenames the issue.@home-assistant reopenReopen the issue.@home-assistant unassign nanoleafRemoves the current integration label and assignees on the issue, add the integration domain after the command.@home-assistant add-label needs-more-informationAdd a label (needs-more-information, problem in dependency, problem in custom component) to the issue.@home-assistant remove-label needs-more-informationRemove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.
(message by CodeOwnersMention)
nanoleaf documentation nanoleaf source (message by IssueLinks)
Seeing the same behavior lately with my Nanoleaf Lines and Elements
Unfortunately the maintainer did not reply for nearly two months now. One thing I did notice: Sometimes, when the light has been in this state long enough, the integration seems to notice this and change its state to failed. In that case it does list the URL which it is trying to access - with an IPv6 URL. However, I am only running IPv4 and as far as I can tell from configuration database the light is also listed there with its v4 IP only. Maybe this is the root cause of the issue?
@joostlek appears to be the new owner. Any chance we can get a look at this issue? I've had it happening with the original Aurora panels as well.
I was able to mitigate this issue for my Nanoleaf Lines by updating them:
- Reset my lines and removed them from HA
- Paired them directly to the Nanoleaf iOS app
- Updated them from version
9.5.9to9.6.4 - Removed them from the app and Apple Home and performed another reset
- Re-paired them to HA via the Nanoleaf integration
It seems to have worked (for now, at least). I'm no longer seeing issues with dropped connections
I was able to mitigate this issue for my Nanoleaf Lines by updating them:
- Reset my lines and removed them from HA
- Paired them directly to the Nanoleaf iOS app
- Updated them from version
9.5.9to9.6.4- Removed them from the app and Apple Home and performed another reset
- Re-paired them to HA via the Nanoleaf integration
It seems to have worked (for now, at least). I'm no longer seeing issues with dropped connections
did it work on the long run?
@sadoMasupilami This worked for a while, but I had to repeat the process around a month later (version 9.6.4 to 11.2.4). Been working fine since then; let's see how long it lasts 🤞
i currently have an automation that restarts the integration regularly. It is not beautiful but better than nothing
Hello i'm having the same kind of issue with three nanoleaf shapes in v 12.0.0. They become unavailable from HA but as son as i open Nanoleaf app, they become available again. It's as if the api calls were kicked off by Nanoleaf (too many calls?) and opening the app resets the api.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
Problems rarely resolve themselves by ignoring them
@joostlek this is still happening for a variety of panels. Can this be looked into?
I too have a set of Nanoleaf panels becoming unavailable, though I can constantly ping its IP and access its web interface.
Reloading the integration restores functionality.
I have created the following automation:
alias: Nanoleaf unavailable reloads integration
description: ""
triggers:
- trigger: state
entity_id:
- light.hexagons
to: unavailable
for:
hours: 0
minutes: 0
seconds: 2
conditions: []
actions:
- action: homeassistant.reload_config_entry
metadata: {}
data:
entry_id: 01JJ9B6JDZX0CGGD2Z70JG58T8
mode: single
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
It is is still there sadly
Still an issue
On Tue, Aug 5, 2025 at 9:10 AM issue-triage-workflows[bot] < @.***> wrote:
issue-triage-workflows[bot] left a comment (home-assistant/core#118542) https://github.com/home-assistant/core/issues/118542#issuecomment-3155401397
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/118542#issuecomment-3155401397, or unsubscribe https://github.com/notifications/unsubscribe-auth/APSM5MPJPCDHKQALTIZRCGL3MC3OPAVCNFSM6AAAAABISM6PJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCNJVGQYDCMZZG4 . You are receiving this because you commented.Message ID: @.***>
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
Still an issue sadly