Connecting to local.autopi.io does not seem to work from a Mac. Stays stuck on:
“Please ensure connection to local hotspot.
No connection found. Retrying…”
Connecting via the IP (192.168.4.1) does open the local login page, but that one’s stuck on:
“Connected to a local device, but local API not yet ready. Please wait”
At the same time, connecting from a phone (iPhone X, Mobile Safari) works just fine.
I had to assign 192.168.4.1 as a DNS manually.
This is pretty shoddy programming - not everyone has DHCP-assigned on their macs. I have a manually configured list of DNS’ that i need for various reasons (VMs, work VPN, etc.).
Note that i don’t mind the fact that local.autopi.io does not resolve - rather it’s that the local web UI does not work at all in this case. I assume because it doesn’t have an IP address as a fallback, and relies exclusively on the domain-name.
It’s because of the clumsy way Autopi has it set up.
local.autopi.io will get resolved by any DNS out there, and it will resolve to Autopi’s server (172.104.147.185). That means that if you’ve got ANY DNS of a higher priority than the dongle itself, local.autopi.io will point to their servers, instead of the dongle.
The code on the local web UI page also uses local.autopi.io instead of the IP address, so using 192.168.4.1 as the URL doesn’t work either, unless the dongle is set up as either the ONLY DNS or the primary DNS.
Which is a bad assumption to make.
The local web UI should’ve had a more sensible name (e.g. autopi.local) and it would’ve worked fine on any machine, regardless of the network settings.
Yes, if you change the default dns servers on your machine, it will not work.
The reason it is made the way it’s made is because that by sharing the same name, it will fall back to the remote version if the device is not connected, and when the device is then connected, the remote version will refresh and the local will take over.
As you explain, our implementation is not perfect, but there was some consideration done when it was implemented, and in this case, we’ve had to pick an implementation that we believe would benefit the most users by means of usability and ease of use, but unfortunately it also means that it does not work for some of our power users.
If you have any alternative implementation ideas, we are very interested in hearing about it.
And I agree that it should work for both the domain AND the ip, as that would allow you to access and use it via the IP, now that the domain does not resolve.
make local.autopi.io redirect to autopi.local if autopi.local is up
fix local so it uses autopi.local in place of local.autopi.io in client code
That way, there’s no disruption / changes to documentation. People can still go to local.autopi.io as instructed. If local is not up/available, they still get remote. If local is up, they get redirected to autopi.local and no harm, no foul. The URL in the browser URL bar is different, but i doubt anyone will bi bothered by that.
