Looking forward tor integration into HAAS! I have two of these and looking forward to start building automations with these lights from HAAS.
Have a look at my how-to to get Aurora Nanoleaf working in hass.io. NB! This will be redundant as soon as this PR is merged. But if you are impatient 
Hi all. Im still waiting my light set but I’m already excited to implement this component.one question left… I saw options of effects …but I can’t find anything in the component docs. Could you please add all configuration variables yo the docs?
It looks like the PR made it into the 0.67 RC.
1 Like
Yeah but no effects config visible … I need those or can I use origin custom component configuration?
Not sure if I fully understand what you are missing, but when you have the Nanoleaf Aurora configured, it will show up like this in Home Assistant:
Then you can choose the desired effects in the dropdown list or change it in eg. scenes:
light.aurora:
state: on
brightness: 204
effect: Vintage Modern
I don’t know if this answered your question? Let me know if it was something completely different you ment
2 Likes
this fullyy answered my question. Thanks 1000 times … now waiting the paket with nanoleaf here
1 Like
It looks like in the nanoleaf app we have a beta option to use a motion sensor for controlling the lights. Is it possible to expose this as a sensor in HASS? I’d personally love to use it for room presence as I don’t have another motion sensor in the office yet. Two birds one stone kinda deal if this will work.
From what I can gather the API does not yet expose the motion sensor data.
Once it’s available though I’ll probably have a look at it, this could be awesome functionality
FYI: I had to rename the platform from aurora to nanoleaf_aurora to not clash with the existing aurora binary sensor – meaning that once 0.67 hits, if you’re already using a custom component and want to switch to the new one, you’ll have to change from api_key to token and from platform: aurora to platform: nanoleaf_aurora
See https://github.com/home-assistant/home-assistant/pull/13831
2 Likes
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!
1 Like
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:
- platform: nanoleaf_aurora
host: 192.168.0.120
token: removed
name: Dining Aurora - platform: nanoleaf_aurora
host: 192.168.0.122
token: removed
name: Living Aurora
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:
- Have you updated the aurora lights/which version are they now running?
- Are you in the nanoleaf beta program?
- Can you (still) ping the IPs from your hass host?
- Are you running hass.io?
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 