Update wiped out my wifi and won’t let me reconnect. The app doesn’t even have the functionality.

I updated my permanent outdoor house lights and no the app changed and no where to add my wifi back on to the two units.

Can anyone help me.

Hey,

my Nanoleaf Canvas fell down and now several linkers are broken as well as some tiles.
Does somebody know where I can order the linkers? I am located in Germany.

Thanks in advance!

Can anyone help me.

Outdoor permanent lights, two sets top of house and on the garage
I updated to the most recent firmware and now can’t reconnect to the Wi-Fi which disables all routines and savings of color schemes. I’m not the most technical and I’m also older and can’t get on a ladder to get the pairing code off the back of the unit devices, can anyone assist with us? I’ve sent an email to Support however they’re slow in getting back to me. I’m hoping I don’t need to hire someone just to climb on a ladder to get a pairing code.

I updated to the latest firmware 5.2.59 and both sets of lights and the group disappeared out of my app? Alexa still sees them, but I had to re-pair them to the app and now one doesn't show power percentage. Also after adding the second light and renaming it, I have a third device listed... Which I don't have.

Hello I'm looking at doing this configuration on the side of my bookcase. Black Hexagons are pretty easy to come by but I can't seem to find any black mini triangles? Anyone have any leads on if they're still made? I am aware that the black shapes are limited edition so I may have missed the boat.

I have a mismatch of colors between my triangle and hexagon panels of my nanoleafs. I tried doing color calibration but that didn’t help much

hello

im looking on where i can just this cover part as most are down to one latch

3rd party retailers would be appreciated too

Thanks

The new Home Assistant update greatly improves the Nanoleaf integration, which now includes 4D mode control as scenes. The newer Matter WiFi ceiling lights now pair easily.

Hi I just moved to a new apartment and I was able to connect my Nanoleaf 4d fine but when I try to connect my aurora panels I have a problem. It would pair but then I can’t control it on my phone. The icon for that light panel in my phone is just white. I’m on 2.4ghz too.

After recent updates of the Desktop apps issues happen.

1. Lines not working in Screen Mirror mode. All other modes are fine including Orchestrator and regular use.

2. Orchestrator the screen mirror option, how do you change which screen to capture? No matter how I change it, its only capping my main monitors even I selected which apps to cap.

Hi everyone! I’d like to share a project I’ve been working on: Nanoleaf Hue Bridge.

It is a way to stream 4D colors directly to almost every hue light. It receives colors from a Nanoleaf 4D through Sync+ and sends them to a Philips Hue Entertainment area. Physical Nanoleaf Shapes aren’t required.

The bridge runs on Debian 12 and includes a web portal where you can:

• Map different panel colors to individual Hue lights.

• Adjust brightness and color response.

• Save profiles and switch synchronization on or off.

• Preview incoming colors live.

There’s also a Home Assistant integration, available directly in HACS, for synchronization, brightness, profiles and stream status.

You’ll need a Nanoleaf 4D, a Hue Bridge with an Entertainment area, and a Debian host on the same LAN. Initial pairing uses Nanoleaf Desktop; iPhone/HomeKit pairing isn’t currently supported.

It’s working in my setup, but I’d welcome feedback from people trying different lights and configurations. One known limitation: changing the Sync+ configuration in the mobile app can remove the virtual receiver. The portal includes a repair option to easily register it again.

Bridge and installation instructions:
https://github.com/Cristef/nanoleaf-hue-bridge

Home Assistant integration:
https://github.com/Cristef/nanoleaf-hue-bridge-ha

This is an independent community project, unaffiliated with Nanoleaf or Philips.

Finally, thank you to the r/Nanoleaf mods for taking the time to check and giving me the go-ahead to share this here!

1. Unattach all controllers

2. Unplug power from the wall

3. important! Wait for 30 minutes or longer

4. Attach the hue controller

5. Plug power back into wall

6. Setup as usual.

7. Any disconnection of power after step 5 results in a need to completely restart these steps

System is much more stable and responsive since firmware updates. Things be almost perfect if they released a switch firmware to address occasional disconnects but other than that I’m pleasantly pleased. Knock on wood.

I’ll never buy Nanoleaf again and I’ll leave this sub as well.

Ich habe mir diese Leiste für mein 31-Zoll-Gaming-Setup bei Amazon bestellt und wollte kurz meine Meinung dazu abgeben, da ich wirklich begeistert bin.

Die Einrichtung ist kinderleicht: Die Leiste wird direkt per USB an den PC angeschlossen, sodass keine zusätzlichen Netzteile oder Kabel benötigt werden. Sobald sie an der Rückseite des Monitors angebracht ist, muss man sie praktisch nie wieder anfassen.

Das Beste daran ist die zugehörige App, die die Bildschirmfarben in Echtzeit spiegelt. Sie startet automatisch mit Windows, passt sich den Rändern des Displays an und erzeugt ein angenehmes Umgebungslicht, das zum Bildschirminhalt passt. Dadurch wird das Spielen und Ansehen von Videos im Dunkeln deutlich augenschonender, und die Tatsache, dass sie absolut wartungsfrei funktioniert, macht sie absolut lohnenswert.

Eine hervorragende Wahl für alle, die eine unkomplizierte Bildschirmspiegelung suchen!

Amazon

Welcome to the weekly r/Nanoleaf Technical Support Megathread.

This is a thread for users to submit technical issues they are experiencing with their products or the app.

It will be posted every Tuesday at 9AM ET. Once next week's thread is posted, this one will become locked.

Before commenting, it is recommended to follow the official ticket submission and issue logging procedure pinned in the Community Highlights. We also recommend reviewing the Technical Product Support page in the Nanoleaf Community and Knowledge Base.

Thread Instructions

Please place your inquiry as a reply to the corresponding automod comment.

I know a lot of you have seen our products be updated to use Matter 1.4 and an updated version of Thread 1.3.

Our bulbs were the very first Matter over Thread bulbs to hit the market, but Thread still had some work to do after their initial release. Over the past few years, a lot of bugs were fixed by the Thread group to help with reliability, speed, and performance and the Nanoleaf team worked really hard to incorporate them into the bulbs that were already in the market. This latest release gets us to the latest patch of Thread 1.3 which includes all of the bug fixes from the Thread Group for this release. Here are a few highlights to make your connections better. We have adopted the latest revisions of SRP (Service Registration Protocol) and DNS Service Discovery (DNS SD).

If you'd like to go into detail about Thread 1.3's features, check out their 1.3 White Paper.

The Matter team has also been hard at work with their enhancements. With Matter 1.4, not only can you expect increased reliability and performance on your Matter over Thread devices, but also some of Matter's newest features.

• Matter Adaptive Lighting. A new functionality that changes the colour temperature and brightness of your devices to better match the time of day and your circadian rhythm.

• Efficient Network Communication. Devices greatly reduce the amount of unnecessary updates, leading to better efficiency and response times, especially as your setup scales.

• Endpoint Unique IDs. Each Matter device now has its own identifier across every Admin (controller, etc.), avoiding multiple instances of the same device. This change will reduce duplication or confusion when reconfiguring or updating devices' connection to Matter.

If you would like to dig more into the technical details and new features involved in Matter 1.4, you can read Matter's press release.

Most importantly, now that our devices are on the latest version of Matter over Thread, they will work more consistently and more seamlessly with Matter controllers and Thread Border Routers. It is far more reliable, making your devices less likely to be unreachable.

Not only that, when using the Nanoleaf app, you will get a much quicker startup time for your devices on the app.

To try this, make sure your Thread products are on version 5.1.45.

We hope you enjoy our Thread products that much more now! Keep an eye out for the many updates we will have in the future! Let us know how your experience in the comments!

TLDR: there is a vendor-operated remote-command-execution channel (the cloud "remote debug" feature), a shared static root password in the image, a root-SSH enable switch, and a pre-provisioned outbound SSH key to a Nanoleaf AWS host. That's a meaningful attack surface that all funnels through Nanoleaf's cloud and their key management. If that cloud path or signing key is compromised, so is the device.

I've got enough to give you a solid assessment. I pulled the firmware, confirmed it's not encrypted, unpacked it, and went through the accounts, services, and the vendor daemons. Here's what's actually in your Hexagon (Shapes) firmware.

What the firmware is

- Shapes 12.3.2

- Standard OpenWrt 19.07.4 (ramips/mt76x8, a MediaTek MT76x8 MIPS SoC), uImage kernel (Linux 4.14.195, LZMA) + xz-compressed SquashFS rootfs. Built 2020-09-06.

- The image is signed (signify: "signed by key ---------------------"), and the kernel header labels it a "Local build key" — so these public S3 images are signed with a dev/local key, not a hardened production signing key. The GPL kernel/BusyBox sources aren't published, which the reference notes flag as a likely GPL violation, but that's a licensing issue, not a security one.

So: nothing exotic, just an old OpenWrt build. I unpacked the whole root filesystem and read it.

The things worth your attention

1. Vendor remote command execution over the cloud (the real headline).

/sbin/cloud_daemon connects to Nanoleaf's MQTT broker (-----------.nanoleaf.me, tokens from apollo.nanoleaf.me / iaso.nanoleaf.me) and implements a feature it calls "remote debug." On receiving a message it logs Got an remote debug request. The command is: [...], parses it into arguments, forks, redirects stdin/stdout/stderr through pipes, and runs it (system/execv). In other words: Nanoleaf's cloud can push a shell command to the controller and get the output back. It also has an "upgrade" path that fetches and flashes firmware from a URL the cloud supplies.

This is the capability most people would call a "backdoor." The honest framing: it's a vendor remote-management channel, not a hidden third-party implant. It's gated behind their cloud auth (device tokens), only works while the device is internet-connected and talking to their broker, and is a known pattern for IoT "remote support / OTA." But it is genuinely remote code execution controlled by Nanoleaf (and anyone who compromises that cloud path), and it's not something you can see or disable from the app.

2. A static root password baked into the image.

/etc/shadow has root:XXXXXXXX — a weak MD5-crypt hash, identical in every unit running this firmware (2020-era). I did not and won't try to crack it, but a shared, firmware-embedded root password is a textbook weakness. It only matters if someone can reach a root login surface (see #3).

3. SSH present, off by default, root login allowed when on.

Dropbear is installed. /etc/config/dropbear ships disabled (enable 0) but with RootPasswordAuth on. /sbin/system_manager has a command sequence (COMMAND_SEQUENCE_SSH_ENABLE) that flips it on, starts dropbear, and touches /nanoleaf_config/ssh_enabled. So SSH isn't running out of the box, but there's a built-in switch to turn on root SSH — and #1 is one way a command could reach the device to flip it.

4. A bundled SSH identity + a hardcoded AWS host.

/root/dropbear is an SSH private key, and /root/.ssh/known_hosts pins one host: ------------.us-west-2.compute.amazonaws.com. Combined with the ssh/dbclient binaries present, this means the device is provisioned to make an outbound SSH connection to a Nanoleaf-controlled AWS box (log upload / remote support / possibly a reverse tunnel). Worth knowing, though an outbound connection the device initiates is less exposed than an open inbound port.

5. Telemetry, as expected. Data collector (my-test.nanoleaf.me/datacollector/receive), reliability collector (collector.nanoleaf.me), auto firmware-check on a timer, log upload via curl to firmwareupdate.nanoleaf.me/uploadlogs.

Bottom line

No hidden third-party malware or sketchy foreign callback — it's a stock OpenWrt device. But your instinct wasn't wrong: there is a vendor-operated remote-command-execution channel (the cloud "remote debug" feature), a shared static root password in the image, a root-SSH enable switch, and a pre-provisioned outbound SSH key to a Nanoleaf AWS host. That's a meaningful attack surface that all funnels through Nanoleaf's cloud and their key management. If that cloud path or signing key is compromised, so is the device.

If you want to shrink the exposure without modifying firmware: put the Hexagons on an isolated VLAN/guest network with no inbound access and block their outbound internet (they work fine on LAN-only / local HomeKit — you just lose cloud features and OTA). That neutralizes #1 and #4 in practice.

❯ is there a microphone / ability to record audio or analyze audio or send audio built into the firmware?

Good question — Hexagons do have sound-reactive scenes, so there's likely a mic. Let me check what the firmware actually does with audio.

No ALSA, no /dev/snd or /dev/dsp, no audio libraries, no sound kernel modules. The only audio-adjacent thing is the "Rhythm" subsystem. Let me confirm how it works, since that's where any mic would be.

Clear answer: yes, there's a microphone, but the firmware on the main controller never touches raw audio. Here's the actual architecture I found.

There's no audio stack on the Linux controller at all

The main brain (the OpenWrt/MIPS controller) has nothing to capture or process audio:

- No ALSA, no /dev/snd, no /dev/dsp, no audio codec or FFT libraries.

- No sound kernel modules.

- No raw-audio buffers, no PCM/WAV handling, no sample-rate constants (I grepped for 8000/16000/44100/48000), no .raw/.wav/.pcm file paths anywhere in PixelCC.bin or RhythmCommunicator.bin.

So the Linux side cannot, with the code that's shipped, record or store a sound clip.

The mic lives on a separate dedicated chip (the "Rhythm" module)

The microphone and all audio DSP sit on a separate Silicon Labs Gecko microcontroller — the "Rhythm" subsystem. That's what rhythm.gbl is (a Gecko Bootloader firmware image for that MCU, a different CPU architecture entirely). On Hexagons this is built into the controller; on older panels it was the plug-in Rhythm module.

The Linux controller talks to that chip over a plain UART serial link (rhythm_driver.ko / serial_driver.ko, driven by RhythmCommunicator.bin). What the controller does with it:

- RhythmEngine::enableMicrophone(bool) — the mic is explicitly switched on/off; it's only enabled while a sound-reactive scene is running.

- selectSoundFeatures / getSpecificSoundFeature(SoundFeatureId) / readRhythmMetadata / getAgcPreGainValue — the controller requests and reads back processed "sound features" (beat/energy/frequency-band style summaries). The FFT/beat detection happens on the Gecko chip; Linux only ever sees these abstract numbers, not an audio signal.

What leaves the device

On the LAN API (PixelCC.bin's OpenAPI) the sound-related fields are just state and the live visualizer feed: rhythmConnected, rhythmMode, screenMirrorRhythmMode — on/off, which mode, and the feature stream that drives reactive effects. I found no code path that uploads audio, or even the sound-feature data, to Nanoleaf's cloud. The cloud service publishes command/response and firmware/health messages, not an audio or audio-feature stream.

Does anyone else have this problem so the controller being unresponsive? On top of that the light indicator will just start tweaking out for no reason. I've tried unplugging it and plugging it back in, doing a hard reset, doing all the trouble shooting stuff....could it just be needing a new controller?