I’m setting up the new Bridges we just got in (thanks guys, they’re gorgeous!) and I’m having some trouble with the wi-fi setup. On looking around, I see a reference to fixing a bug related to this in this developer update, but no other info. Previously, we haven’t had any trouble with this (our other hardware works great).
The setup page for the wifi (in browser) has the password as a required field. Since there is no password set on our infrastructure, it seems (even with the MAC address already provisioned on our end) there’s no way to get it to connect properly.
As a workaround, I tried removing the requirement for the password field locally by just deleting the “required” tag in the HTML. I was able to submit the setup and see the response on the Bridge (it attempts to connect to the right network!). Unfortunately, the Bridge then just goes straight past the Wi-Fi connecting screen to a “Pairing…” that flashes every few seconds and doesn’t seem to get any further, even though I haven’t actually paired it yet. I’ve yet to leave it for more than a few minutes, doing that now though.
Any ideas? Resetting via the button on the bottom gets it back to the normal state just fine, so hopefully I haven’t broken anything yet. And, yes, before anyone says, I know I’m bad and probably shouldn’t be messing with the HTML.
welcome to the forum! I‘m glad you like look of our new bridges.
I‘m very sorry you had trouble setting up its WiFi. What firmware version do they have? (You’ll see it at the top right of the bridge display while it’s in WiFi Setup mode.)
If you see „Pairing…“ and it doesn‘t show a pairing code within a few seconds it means that the bridge can’t reach our servers. But that might be related to your first issue with the WiFi.
There’s a few different things, so here’s basically what the top line of text on the Bridge says:
fabman.io v5.0.4 240A C415 E638
And, because I feel like I should clarify – our organization’s method for adding devices that don’t have web browsers to our wi-fi is by pre-provisioning their MAC addresses and just having them connect to an unsecured/unencrypted network. Since the web portal requires a password, connecting to the network always results in an error, and the HTML-edit fix was just a workaround I bodged together that seems to not work.
I just had a closer look and even though the fix for connecting to WiFis should have been part of v5.0.4 it was omitted by accident. I’m sorry.
But the fix simply consists of removing the required attribute from the password form – so your workaround in the browser was exactly right.
Therefore your problem seems to be that the bridges can connect to your WiFi (when you use the HTML workaround), but they can’t reach our servers (https://fabman.io) from within your network.It seems there’s something wrong with your pre-provisioning. Could you double-check that?
Glad to hear my workaround wasn’t stupid! I’ve managed to get it figured out, the issue was the MAC address I was using. It seems the Bridge uses a different MAC when it’s acting as an access point than when it’s acting as a client. They’re very similar – take a look:
Bridge (from scan while phone is connected to Bridge setup Wi-Fi):
24-0A-C4-16-10-7D
Bridge (from scan while Bridge is connected to phone hotspot):
24:0a:c4:16:10:7c
The latter (the one you want!) is just the other one minus one on the last chunk of the address. It might be worth displaying these while in the setup mode? I’m all sorted out at this point – took some jumping through hoops on my end, but by golly it works!
Agh, I’m blind! That MAC doesn’t match with my earlier post as I switched to another bridge while I was troubleshooting, for anyone reading this later. Maybe also throw it in the web interface or something? Or, format it in the more “traditional” way (at least for me – never seen a MAC in three sections like that).
Thank you so much for all the help! Now to get my solenoid valve working…