I’ve been using my pixelblaze 3 with the sensor board and output expansion for a couple of months without issue then in the last week I’ve not been able to get the UI to load. Have tried various methods described in the forum to resolve without luck.
Currently it will power up and I can see the AP in phone/laptop wifi settings. When I attempt to connect i get stuck on a loading screen at the AP login prompt. I’ve tried numerous wifi resets, have seemed to have gotten connected but am unable to update the wifi access or AP login. Have tried different command lines such as:
to no avail, usually getting a connection refused. Even after disconnecting LEDs, output and senor expansion boards, same results. I’ve also tried different power sources (multiple known working with other devices) from various proximity to my WiFi, as well as on different wifi networks altogether.
Prior to this occurring I was a little concerned about the free space as I’d loaded a lot of patterns. ANy suggestions/assistance would be greatly appreciated as I really miss tinkering with my Pixelblaze.
Think we’re making progress here. While I’d already updated to 3.24 using the /update path did allow me to reboot then re-enter wifi credentials. Rebooted again and now the Pixelblaze shows up on network and via discovery services.
However i’m still unable to get the UI to load. Suggestions?
Sure - no loading screen appears justa. blank screen then after a period of time the browser reports the site can’t be reached because it took too long to respond (ERR_CONNECTION_TIMED_OUT).
This occurs with both the base url and with /recovery.html. But it still shows as active with the discovery service.
I’ve tried using the recovery page to both setup wifi and AP access. Each time after saving the browser displays: {“ack”:1}
Latest attempt seems to have saved the AP settings. I’m able to connect via AP but cannot get the UI to load. Same timeout messages as I mentioned in last post.
This can happen if you go to the wrong IP address for the connection method. In AP mode you wont use the discovery service, instead connect to that new wifi network, then point a browser to http://192.168.4.1
The entries on the discovery service take up to an hour to start to expire, so it might have been showing previous data. You’ll also need to switch wifi, so if you can get to the discover page, you might not be connected to the Pixelblaze’s network.
You can also try pinging it to see if its online at that IP, or going to the update page (just to see if it loads).
Sometimes a browser holds on to a connection attempt, so closing and opening it again can help. If you are sure it’s online, and your computer/phone is connected to the same network as the Pixelblaze, and pings and/or the update url load, then you should be able to get to the main interface.
I have been able to access recovery.html, update and save wifi settings. Pixelblaze then shows up in discovery but when I try to access the IP address via a browser i get the message ‘The site can’t be reached’. At that point I’m unable to connect to any url that I’m aware of. Have tried several times to connect to /update and recovery.html without success. Holding the button to reset Pixelblaze’s wifi works and I’m able to repeat this process again.
ANy suggestions on what I might try next would be much appreciated.
Can you ping its IP address? Anything show up in wireless networks? What does the status LED do on startup?
Do you mean some URLs work before that, and then stop when you try to load the main page, or just nothing works once configured to connect to your local WiFi?
When I ping the IP I get the message ‘Request timeout for icmp_seq xx. ping: sendto: Host is down’. I do see the pixelblaze on my network and in discovery.
What I mean by my reference to URLs is when I reset the pixelblaze wifi I am able to connect to /recovery.html and update the Wifi settings. After setting up wifi I cannot actually connect to the web UI and am not aware of any other endpoints/URLs to try connecting to. Yet the pixelblaze still functions, meaning lights up attached pixels and responds to pushing the button to step through patterns otherwise.
it shows up on attached wifi devices on network with an IP matching other device subnet addresses, 192.168.0.x. Resetting wifi through updating wifi settings vie recovery.html works as expected. However when in AP mode I can’t get to the login dialog and once connected via recovery.html with a valid subnet IP I’m unable to connect via any browser.
I’ll test turning off and on again, pinging all the while, later today and let you know.
Hey - I’ve been watching this thread and have a theory. I’m wondering if the board could be in one of those states where the current pattern has either a corruption or an unhandled illegal statement. After it joins a network or creates an AP, it attempts to run the current pattern, but faults immediately and then progressively resets LED settings, then WiFi settings. Perhaps so quickly that the pings aren’t getting through. Side note, I read you can set ping to try more frequently with the -i flag (maybe also set shorter timeouts with this).
@wizard, in that progression of failsafe fallbacks, is there one that un-sets the current pattern to a no-pattern state? Then my theory wouldn’t fit.
@jclarkks22 it sounds like you’re pinging the local subnet ip after configuring client mode and not getting responses. What about when resetting the WiFi into AP mode - are you able to ping 192.168.4.1 then? And if so, I’m wondering how far it is to your router. I’ve experienced some times where a Pixelblaze and laptop are next to each other on a desk, but about 30 feet and several walls from my home router - the laptop wifi could connect fine but the little Pixelblaze couldn’t reach it reliably. WiFi setup and AP mode worked ok, but client mode was full of connection resets and timeouts, including being stuck on the loading screen.
Yes, that’s one of the first fail-safes to kick in. Wifi reverts back to setup mode only as a last resort.
This doesn’t make sense to me, since wifi setup mode works ok. They are the same as far as networking goes, the only difference is how it triggers the captive portal stuff.
Another theory: I wonder if you are running a VPN? And perhaps it is misconfigured to not allow local traffic, and turns itself off when detecting a captive portal, but not otherwise.
Also puzzling is that you can’t ping it even when it’s able to get an IP and is online enough to register with the discovery service. It really does make me think this is some networking issue.
Some routers can be configured to disallow connections between peers/clients on a network, but that wouldn’t explain the AP mode difficulties.
We can try swapping it with a new Pixelblaze, but I have doubts that it’s the root cause of the networking stuff.
@jeff I was in the process of removing some problematic patterns when this happened. However even though I’m unable to connect to the UI I am able to use the button to change patterns and most work fine. Some do seem to hang but I’m able to advance and others work as expected. I’ve tested resetting and connecting in Wifi and AP mode with pixelblaze within a few feet of my router and seem to have a great signal so I don’t think the connection si the issue.
@wizard Not using a VPN and making sure all devices are the same 2.4GHz wifi network when testing (unless connecting to pixelblaze AP).
I do get varied results with being able to ping the pixelblaze in both AP or wifi mode. Typically once connected to the device in AP mode I’m able to ping and get responses such as follows:
64 bytes from 192.168.4.1: icmp_seq=0 ttl=255 time=3.665 ms
64 bytes from 192.168.4.1: icmp_seq=1 ttl=255 time=3.979 ms
64 bytes from 192.168.4.1: icmp_seq=2 ttl=255 time=56.397 ms
64 bytes from 192.168.4.1: icmp_seq=3 ttl=255 time=63.835 ms
64 bytes from 192.168.4.1: icmp_seq=4 ttl=255 time=37.231 ms
Once I setup the wifi and confirm it shows up on my network pinging the pixelblaze IP also get mixed results. Typically get the timeouts but just tested again and see this:
PING 192.168.0.119 (192.168.0.119): 56 data bytes
64 bytes from 192.168.0.119: icmp_seq=0 ttl=64 time=101.479 ms
64 bytes from 192.168.0.119: icmp_seq=1 ttl=64 time=107.679 ms
64 bytes from 192.168.0.119: icmp_seq=2 ttl=64 time=31.490 ms
64 bytes from 192.168.0.119: icmp_seq=3 ttl=64 time=66.817 ms
64 bytes from 192.168.0.119: icmp_seq=4 ttl=64 time=131.962 ms
Yet when I visit the discover.electromage.com I see the message " No Pixelblaze controllers have registered yet.". Also the web UI isn’t loading from my laptop or iPhone.
Up until a few weeks ago I had no issues and was able to connect to the pixelblaze UI from different computers and mobile devices. There were no changes made to my network so I’m really confused as to what’s going on. The only thing I recall was thinking I needed to cleanup some unused custom patterns to free up space then this all started.