I'd like to request improved reliability when the light panels are connected to a traditional Wi-Fi network, but blocked from the internet. Right now, the panels behave unreliably (frequent "No Response" in HomeKit, etc) and go bright white while completely unresponsive after multiple hours of being powered on while blocked from the internet.
It'd be nice if the Light Panels would reliably work while blocked from the internet, but still connected to a HomeKit home. Right now, it seems like the controller fills up with failed requests and eventually crashes, requiring unplugging and plugging them back in.
I reached out to support who indicated that this is expected behaviour when the devices are blocked from public internet access. I really like keeping my IoT devices offline, unless they need it temporarily for a firmware update.
what firmware version us your controller running? I remember fixing something along these lines for offline controllers. So maybe you just need a firmware upgrade, and then you can take them offline as well.
Thanks for replying! Looks like my controller is running 3.3.6 with no updates showing as available. Not sure if maybe I'm on a different branch, if there was a fix released earlier. Really appreciate it!
Sorry for the delay! It's hard to say an exact amount of time. I'd say it's about 10-15 minutes before the light panels stop responding reliably in HomeKit (i.e. half of my HomeKit requests fail and I need to wait a few seconds to make sure the panels are reachable before sending the request again).
It's at least half a day (maybe a little more in some cases) before the panels go white and the controller stops responding. I was able to witness it the other day, and it seemed like each panel individually went to a bright white from the active scene. Once that started, I couldn't seem to get the controller to respond at all until I power cycled it.
I just gave it a power cycle now, and blocked the controller from the internet and made a note of it. I'll report back with more data.
Side note: I just noticed that the active scene (after about 5 minutes of being blocked) froze in mid-transition for about half a minute. The panels were unresponsive in HomeKit while the scene was frozen, but the scene resumed moments later and it is now responsive again in HomeKit. It looks like the scene freeze coincided with the non-responsiveness.
If I can provide anything else, I'm more than happy to! Outside of this issue, these panels have been amazing and extremely reliable. Very impressed since purchasing them, and I'll likely be picking another set up for another room!
I was just following up to see if you were able to reproduce the issue? Certainly not rushing for any update or rushing out any fix. I was just curious if you were able to reproduce what I'm seeing on the panels or if you're having trouble recreating this behaviour.
Occasionally, I can get it to perform perfectly fine when blocking the panels, but it ends up back with the old behaviour (scene freezing, no response, etc) after a power cycle.
Really appreciate all the responses here. Always nice when companies put the effort in :)
Happy New Year! Hoping you have been able to keep safe and healthy!
Yes I did setup a test. Although this was 3 months ago, at some point in between I must have power cycled my controller so my uptime is just 28 days.
However in that 28 days my controllers have kept running without going into any abnormal state. They have no connectivity to the internet.
Now in good news, we did recently release a new firmware to Beta with a whole bunch of fixes. Drop in your controller's serial number or DM it to me and I can add you to the Beta group and you can give that shot. That might just fix the issue for you as well.
Wow, you are quick! Got the Light Panels running beta version 5.1.
Unfortunately, the scene still starts to freeze right after blocking the controllers access to the internet and it temporarily goes unresponsive in HomeKit. A freeze seems to occur once every ~24s on the nose. It seems to run smooth as butter with perfect responsiveness as soon as I unblock the panels.
It was worth a shot! I don't suppose I can send any logs from the panels your way or anything? In case it helps at all, I'm using an AMPLIFI Alien and it seems to block packets leaving the network (while still allowing fully local communication); however, it will still answer DNS requests. I'm not sure if maybe successful lookups impact any "no active internet connection" logic that might exist?
I can certainly live with the issue and I don't want to take up too much of your (or the teams) time. Appreciate all the effort you've put into this already.
Side question: Will these panels end up back on the normal release schedule when this firmware eventually gets pushed out?
Yeah, they will keep getting updates as normal, once they connect to the internet. You can just reach out to me every few weeks to check in for a new update and I can tell you when to connect to the internet.
There might be something different in our setups. My router simply does not have internet, while yours is still answering DNS requests. In other words, I don't even have a DNS look up available. (Indeed, pinging google.com while connected to my non-internet network, just leads to bad address)
I don't like that you have to live with this issue so, if you have the capability, block DNS requests to the Light Panels as well and see if that helps.
In the meantime, I will try setting up a test similar to yours. This can take me some time, since my non-internet router is used for other things as well.
I have never run the panels in this scenario so there can be a bug.
An alternate solution is to place the panels in hotspot mode. This will have the panels broadcast their own AP, and you will still be able to control the panels from your app / HK once you connect to the panels AP. The caveat is that you have to connect to a separate AP every time, which may or may not be what you are doing right now.
I really appreciate the effort you're putting out here. Feels good when a company cares about their user experience and actually troubleshoots. I know I sound like a broken record, but I wanted to say thanks again for even hearing me out on these forums.
I'll try a few more tests over the next day or so, but I think that may be the difference causing my Light Panels to misbehave. I'm not sure if this is an adequate test, but I: changed my routers DNS to a non-existent private address so that lookups can't complete and then power cycled the Light Panels. The Light Panels went back to their previous scene and froze immediately for ~10 seconds or so (probably about how long it takes for a lookup to timeout) and then worked flawlessly without any lockups or non-responsiveness. I set the DNS back to my ISP's default and left the Light Panels as is and they started hitting that non-responsive state again after some time.
I'll have to run it a few times just in case it was a fluke, but I think it's hanging on trying to communicate with a device on the internet when it's able to successfully complete a lookup. I don't really have any advanced monitoring on my home network and I don't have any knowledge of what the Light Panels are trying to do, so this is just guesswork.
Absolutely no rush in setting up a test environment for this issue, but I would be interested in hearing if you're able to see the same thing. Curious if it's something wonky with my Light Panels configuration or overall setup.
Thought I'd chime in and let you know that I was able to get around to giving this another shot and it seems to be related to the Light Panels being able to complete DNS lookups, but being blocked from the internet (in my case). Unless there's something I'm overlooking or not thinking about.
If I set my routers DNS to a non-existent address (e.g. 192.168.1.1 so no lookups can ever complete on devices using the DNS server assigned to them) and reboot the Nanoleaf Controller: Nanoleafs behave perfectly. I only tested for about 2 minutes or so, but scenes remain active and the Light Panels remain responsive. Instantly responsive to all HomeKit requests. In the two minutes I let the panels operate with the invalid DNS server: I couldn't get the scene to freeze and every request was answered in HomeKit
If I set my routers DNS back to my ISP's DNS servers, which in the case of my setup allows lookups to complete; however, it continues to block any access to outside the network: the Light Panels scene begins freezing periodically about 15 seconds or so after starting. The freezing coincides with it becoming unresponsive in HomeKit and the Light Panels repeat its freeze/unresponsive cycle every 20 seconds or so.
I don't know if this information helps, but I thought I'd pass it along!
I see that you are working on this already, but wanted to report having similar issues. I use a Pi-Hole (DNS blackhole) on my network and block outside internet access to all in-house smart devices, so my DNS requests are succeeding while offline like the OP's.
The Nanoleaf behaves poorly compared to all of the other devices on my network when nullrouted in this manner: it makes over 20,000 requests per day (one every few seconds), and often becomes unresponsive. Other devices I use actively only make about 1,000 requests/day.
It seems like the Nanoleaf is constantly retrying for an internet connection and could benefit from better backoff/retry logic when permanently disconnected.
Just curious if this is something that's still on the roadmap to be looked into? I'm not overly concerned about the panels going white and flickering (as long as this isn't damaging the panels themselves), but having to yell at Siri a few times before I can catch the panels at a moment where they're responding is a little buggy at times.
All good here, hope you are doing well as well.
We will be releasing a new firmware for the LP soon, which should hopefully resolve this issue. It doesn't occur for me atleast. My setup is a router with no internet connection whatsoever. So its kind of like one of your setups. I will try and get a date for when that will be out to the public, though I know its in Beta.