As cool as the BlinkUp feature is, our end user do seem to struggle with it. We are looking to offer the same functionality over BLE with enrolment happening at the factory.
From my understanding we can pass the WiFi credentials over BLE and then set them using imp.setwificonfiguration() and then calling imp.reset(). However how can we listen for the states that are usually surfaced during the BlinkUp process and pass them back over BLE for the end user to see. I’m talking about the following:
Searching for WiFi network
Joining WiFi network
Getting IP address
Resolving server name
Connecting to server
Updating ImpOS
I can’t see any callbacks available to get this sort of information in the imp code. Is it possible?
It’s certainly not possible to obtain the “updating imp firmware” state from within Squirrel code, because Squirrel code is not running at that point!
The other states, though, while not available “in real time”, can be determined from the failure code passed to the server.connect() callback if the connection does not succeed.
One important reason why those states are not otherwise available, is that we do not guarantee that the states and their ordering and their timeouts and their retries remain the same from one firmware release to the next. Once exposed to Squirrel, that whole state-machine would essentially become calcified, because any future changes to it would be visible to customer code and might cause breakage.
Note that, as it stands, the imp can get into rare situations where only blink-up can recover it. We currently intend that a future firmware release will make non-blink-up provisioning sufficiently fail-safe that it can replace blink-up entirely, while maintaining the same reliability criteria.
we would like to go to the same scenario as the OP explained (for the same reason + the fact that we don’t want to spend the effort of regularly updating the custom blinkup app we had to make some years back as nobody in the team really has decent skills on objectiveC or Swift development and it’s always a pain…).
I know this is always the million dollar question, but when do you anticipate such release would surface for production ? Question of deciding whether we need to include the optical blink hardware in our designs or not)
BLE blinkup is going to require app updates just as much as optical blinkup, though? Apple will change APIs, deprecate old builds, etc just as they always have, and Android APIs will move on too.
If you’re looking for a way to avoid native apps, a JS blinkup webpage (which can work on phone, tablet, laptop) seems like it’s the lowest level of ongoing support.
Indeed, we’d like to avoid native apps on both platforms. We’re using C#/.NET with Xamarin to have a cross platform solution which works really well. Supporting new iOS/Android APIs is really not more work then recompiling and publishing. The only thing we didn’t succeed in (due to lack of time because it is possible) is to embed the native blinkup libraries into a Xamarin (mono really) wrapper class hence we can’t integrate the blinkup in our main app. The pain on having to make the native blinkup app evolve is not because it’s complicated, but because nobody in the team has any experience in the languages (ObjC,Swift or Java) nor the toolchain and it’s always a learning curve if you only use it once a year or so…
Would a JS blinkup webpage work when hosted in a webview window within a mobile app ? If yes, then this is probably the solution we’re looking for.Need to take a closer look at that…
No, but - given some careful usage and best practices - several customers are deploying this solution from squirrel. You shouldn’t rely on it for development as there are many corner cases there with pushing bad code.