My Flutter IoT Journey (Part 2)
Well, as promised, here’s a part two. But I do have to disappoint you… This won’t be about UnitTests in Flutter, but rather an update on what has changed in the project.
The Problem
Like most project changes, this one was also caused by a problem that we noticed when testing the clock. The problem is that the communication with the HM-10 bluetooth module, was not stable.
The communication over bluetooth was working just fine at first. The app did it’s job by sending the commands that are required to set the time of the RTC and color of the RGB LED strips. The Arduino also did its job of parsing the commands correctly, by reading the data from the bluetooth module, using the serial communication API that the Arduino provides. However, after some testing, we noticed that the functionalities for setting the time and color, were not working reliably anymore. Sometimes the command being sent from the app, was being received as a split string by the Arduino… The data seemed to be received too slowly by the Arduino, which was weird, because it had been working just fine.
After trying out some possible solutions, like adding a delay to the parsing of the bluetooth data, we concluded that we needed a different solution, since a project that only works half of the time, is annoying.
The Solution
The solution is simple. Throw away the project and start from scratch….
Seriously!? Actually no. I got you there for a minute :D. After consulting my friend on a possible solution we decided it would be the best way to do things, since products like the Amazon Alexa and Google Chromecast also do it.
So… what is the solution? We have decided to use a different microcontroller that supports WIFI. We will implement a web server on a NodeMCU that will need to be configured at first, to connect to a WIFI network. This will be done by opening a WIFI access point on the NodeMCU, which the user will need to connect to in order to configure the WIFI settings for the clock. Once the setup has occurred, the clock closes its own network, and connects to the configured WIFI network. The clock will be reachable via HTTP endpoints that can be called from the word clock app.
A further feature that will have to be implemented in the app, will be to add a screen where you can choose which clock to connect to, if the user decides to have multiple clocks in their home. This would have previously been a problem, since the app connected to the clock directly, without any user input. Alternatively, a default clock can be configured on first time usage of the app, and then be reconfigured in a settings screen. This seems like a more UX friendly option, since it saves the user an extra step every time when opening the app.
Well, you may have already guessed that that would be the solution, since it seems to be the industry standard when it comes to configuring an IoT device, and wondered why it wasn’t the go to implementation the first time around.
Dunno ¯\_(ツ)_/¯
We wanted something simple, but it did have its pitfalls… Anyway, this solution seems viable, so it’s time to get started with the implementation : D
I’ll give an update, when the clock has a stable implementation of this solution.
