AH! I deleted my custom components and dependancies and it wasn’t working. Then I finally noticed the change from api_key to token. The documentation still calls the platform aurora, so it appears the merge update of documentation is not complete. Once I found this post and corrected the platform name I was up and running!
Congrats on getting this out, and Thank You!
Hello All,
Thanks to everyone that’s put work in on this.
Unfortunately, I’m having trouble transitioning to the new component. I had everything working under the custom component.
I’ve updated my configuration.yaml as follows:
but I’m getting:
Could not connect to Nanoleaf Aurora: Living Aurora on 192.168.0.122
4:56 pm components/light/nanoleaf_aurora.py (ERROR)
Could not connect to Nanoleaf Aurora: Dining Aurora on 192.168.0.120
4:56 pm components/light/nanoleaf_aurora.py (ERROR)
as errors at startup.
I’ve just done an upgrade to 0.67 to try this out. I was on on 0.54 previously. I’ve tried it with and without the older custom component removed.
Anyone have any other ideas?
Thanks,
Thanks, seems like the documentation fix did not make it into the current version, you’re right. Glad you got it working regardless 
@funhouse I am assuming it worked before with this config. Just some shoot in the dark questions:
Last but not least, please use the code formatting option for yaml, just to make sure there is no issue there.
Hi Oro,
Thanks for the quick response. To answer your questions:
Yes, working perfectly.
One is on 2.2.0 and the other on 2.3.0
No
Yes on both
No, it’s on a Debian install running on an ESXi VM.
Here’s the relevant configuration.yaml:
- platform: nanoleaf_aurora
host: 192.168.0.120
token: hidden
name: Dining Aurora
- platform: nanoleaf_aurora
host: 192.168.0.122
token: hidden
name: Living Aurora`
Since posting last, I’ve tried a forced reinstall of ver 0.67 which didn’t change anything. I also forced a new token to be generated on the Dining Aurora. That also didn’t help. The update of configuration.yaml was to change the platform name from “aurora” to “nanoleaf_aurora” and “api_key” to “token”.
I had a few other problems with other components, going from 0.54 to 0.67 in one hit, but I managed to get them all sorted out. This is the last one to fix.
Thanks
Thanks for the answers, that is very strange.
Could you please stop hass, get the logs and paste them here (or check them yourself, the library prints to stdout and, from what I can gather, hass only flushes stdout to the log on shutdown)
If you cant see anything wrong there, could you please add
_LOGGER.info("Aurora Light: %s", aurora_light.info)
after line 47 in <hassfolder>/lib/python3.5/site-packages/homeassistant/components/light/nanoleaf_aurora.py and check again?
Checking the logs myself I saw that the aurora is now actually discovered automatically by hass, I’ll seeif I can also add this to the component, would be kinda neat
Oooooh and just to make sure, are you on python 3.5 or higher? in 0.64, python 3.4 support was deprecated. I assume you are, just want to make sure: Deprecating Python 3.4 support
And you did of course delete everything “aurora”-like under the custom_components folder? Have you tried commenting out one of your auroras and try only one in the config to see if it has an effect?
Hello All,
It’s official - I’m an idiot!
After nearly a full day of troubleshooting, including setting up a brand new install of 0.67 on a Raspberry Pi as a test, I decided to rollback to the snapshot I took of my HA VM before I started upgrading stuff and go back to 0.54. That’s when I figured out that I’d managed to swap over the tokens between the two Auroras in configuration.yaml. Once I sorted that out, and went back to the 0.67 snapshot, it all worked as it should. I’m glad I took the snapshot before upgrading it all now.
My apologies to Oro and vegard for wasting your time, but thank you also for taking the time to help.
Having got it working, I have found a minor bug. To reproduce it, slide the colour temperature slider somewhere to the right hand side, so it’s warm. Then slide it all the way left in one move. On mine, the colour temperature won’t change. If it slide it left but stop before hard left, it works as intended. As I said, it’s a minor thing, and I’m just so happy to have it all working at the moment that I can certainly live with that.
Regards,
PHil
Hey, super that you could get it working!
Also, thanks for the bug report, seems I’ve missed an issue with the colour temp slider. As you said, the left-most setting does not work. I’ll check if I can fix this the next time I have some time off.
Best
Marco
Min temperature and max temperature is going to get fixed with PR https://github.com/home-assistant/home-assistant/pull/14571 , thanks for the heads-up
Additionally, the Auroras should get automatically discovered and setup now ( https://github.com/home-assistant/home-assistant/pull/14301#event-1636001024 ), only caveat is that you have to press and hold the on button on them for ~5 seconds on startup (!) of home assistant. Configuration like before in the configuration YAML of course still also works
still no news about the motion sensor unfortunately 
Does the discovery button push have to be done every time home assistant restarts, or is it stored somewhere in the config? The hue discovery where it prompts you to press the button to add without restarting or anything it is the new gold standard for me.
The integration is awesome thanks for all your hard work!
It’s stored in the config so you’ll only have to push it once during the inital setup.
Hey @sanderant , it is saved in a config file after initial discovery, so only one time setup is needed.
The Hue component really is the gold standard 
I tried getting it to work the same way, unfortunately I wasn’t able to display it the way Hue does it (with a new panel describing what to do) - this is why it only works on startup, which I hope is good enough.
Would this component work with the Nanoleaf Canvas?
I found using discovery to configure the nanoleaf is a little flakier than setting it manually. While the lighting portion of the nanoleaf is top knotch the wifi behavior leaves a little be desired as it only appears to connect when its first turned on so if your wifi goes down it won’t reconnect and when it does it sometimes gets (requests?) a new ip. In this drama for some reason home assistant kept on munging the keys.
It would be nice if we could make host: an optional parameter where you could store the token and let discovery use a provided token.
Just a request, but otherwise working fine and very happy with the integration.
I am curious to what the color value represents when there is an effect running. Does that value represent the first tile or something?
@RandyA I was able to test it today, no it does not work with Canvas at the moment due to an incompatibility between the canvas api and the aurora api 
I asked in the nanoleaf dev forum if this is a known issue (short summary: The endpoint for e.g. brightness/value returns the actual value on Aurora, but json with value, min and max on Canvas)
@sanderant That seems strange, DHCP correctly assigns my auroras the same IP addresses every time. I’d advise you in trying this route, i.e. go into your router settings and look for something like a static IP address allocation.
As for the color value, I had to check it since I had no idea. It is the last color value that was used, i.e. if you change from red to any effect, it will still show red. Not the best tbh, I don’t yet know how to better integrate that into home assistant, but I’ll find something (hopefully)
@Oro Thanks for your continuing work on this. I did assign an address via the router which did indeed solve that problem.
I have been using the integration lately with a different issue. **Sorry **
About once every month or two, the Aurora crashes. The symptom is that the system just shows the white light as if when you’re first starting it and the wifi and remote are unresponsive.
While I ask Nanoleaf about that to see what the deal is. It would be nice if the HA integration could do the following things:
Determine if the Nanoleaf is unresponsive. I can check manually via the device tracker, maybe there is another state I could monitor. My idea would be to resolve this via an automated plug to reboot the system if I can figure out a way to trigger it.
The other problem is when the Nanoleaf comes up after rebooting it won’t respond to HA until HA is restarted. I don’t know if this is an HA limitation or not, but it would be nice if it could read again.
Thanks again for all your work on this. I’m learning some python and hope one day to help contribute in a more substantial fashion.
I’m also experiencing the exact same crash with the Aurora’s on two seperate controllers. Seems like it’s a firmware issue.
Well I’ve not really been “working” on it for the past few months
And yes, error detection is pretty much nonexistent at the moment. I did a quick check with mine to see if it recovers and it does, but I assume if it is offline for longer it won’t be able to recover without a restart 
No easy fix for that I think, I’d have to change the python API wrapper to throw exceptions in case it encounters an error (and maybe also a nice way to check if it is available at all) - No idea how difficult that would be. But when I implement it HA should automatically pick up that the Nanoleaf is offline and just say “Unavailable” in HA and recover on its own.
Thankfully as of now I haven’t had issues with my Aurora, just one faulty Canvas controller that the awesome Nanoleaf support replaced very quickly.
I’m also experiencing the same error, where the light will crash and turn on to a blinding white (100% brightness) - typically happens in the middle of the night which isn’t great!
Only way to recover is an unplug at the mains socket, to reboot.
I did notice a firmware update recently to 3.0.6, but the issue still occurs