Initial set up goes better with an internet connection, and mobile devices’ apps may require internet to function (haven’t tested) but I believe you could likely get by without internet as long as there was a local area network with WiFi and you had Hubitat methods of controlling locally. I’m not very familiar with Hubitat and its version of local-only-controls, but @dman2306 has created some integration efforts with Hubitat I believe.
Also - can’t recall off the top of my head if there is a configuration for “don’t reboot when you can’t reach the internet” for the hub right now or not.
Yup, the Integration for Hubitat makes it so I never use the BOND App other than if I want to update the firmware on my BOND hub. The integration between Hubitat and BOND is all LAN so there is no need for an internet connection on my end. I even route the Alexa stuff through Hubitat so there’s no need for my BOND to talk to the cloud at all.
We’re pretty dedicated to the goal of “100% local control” when possible. As I see it there are a few flaws we need to address here:
The Bond will not show up in the mobile app if it’s never connected to the internet. This is because we trust the Bond to inform our backend when its ownership updates, and the mobile apps trust the backend to tell them which Bonds they own. There isn’t a Bond<->mobile app way to communicate this yet. However, you can still use the local API, so I guess it’s not the biggest dealbreaker. Also, it’s enough to just give it an internet connection during setup, you could remove it after.
The Bond will continuously reboot if it’s not able to reach our backend (specifically the MQTT broker). This is definitely a dealbreaker! We’ll add an option to suppress this.
(related to 2) The Bond will expose its config AP if its not able to reach our backend. The option to suppress this should probably be bundled with point 2’s option.
We’ll have a draft of the API for points 2 & 3 shortly. Point 1 might be a bit more complicated, but it wouldn’t be a persistent issue, so I’d say its of lower priority.
Huzzah for points 2 & 3 being implemented in the future - though can we tweak (or offer options) for #3 being “if I can’t reach back end AND ALSO am not connected currently to a known AP, then broadcast my setup SSID”?
Also, @jacob - can you clarify (related to point #1)… If a mobile device was on the same SSID / AP as a BOND device (Bridge or SBB), but that network had no internet connectivity, is it expected that all of the app, save for firmware updates and any legacy ‘cloud’ devices, would function to appropriately control local devices?