This series is meant to give a deeper look into the challenges you are likely to encounter if you decide to turn a maker project into an actual Internet of Things product. It's based on my experience over the past two years of creating a product from scratch. If you missed parts 1 and 2 you can find them at the following links.
Last time we talked about how even in your wheelhouse of writing code you are likely to encounter issues that cost you time and money. In this edition we're going to talk about the chicken and egg problem of connecting a piece of hardware to the internet. After all, this is an Internet of Things thing. This is also where you have to start interacting with people...a lot.
Connect to the Network to...Connect to the Network
Your customer just opened their new, fancy IoT product. The packaging is beautiful and the Thank You card makes them feel even better about the decision to buy from you. One of the very first things they need to do is get your product connected to the internet. For the purpose of this article we are going to assume WiFi as that is currently the most common connection option for consumer IoT devices. It's also the one with which I have practical experience. In order for the device to connect to the user's WiFi it needs some credential information. Back in MakerLand you probably didn't have to worry about this process at all. I've seen LOTS of code samples where there are simply some constant variables or #defines for SSID and password information. Unless you want to ask each customer for that information at checkout and then compile separate binaries for each of them you're going to need a better way. The two most common ways are SoftAP or using a serial connection over USB.
SoftAP is Hard
SoftAP stands for "software enabled access point" and is a common feature in many hardware platforms. When in SoftAP mode your device establishes its own SSID and acts as an access point to which other devices can connect. The process normally looks like this:
- User turns on your device. It will enter SoftAP mode by default out of the box.
- On a different WiFi-enabled device(phone, tablet, pc) the user opens the connection settings (you'd be shocked at how many people don't know how to do this).
- In the list of nearby WiFi networks they choose your product's special SSID it is broadcasting.
- The user device connects to your product's SoftAP.
- Magic happens(more on this below).
- You get the user's home network SSID and password.
- Miracles occur(yep, you guessed it, more on this below).
- Your device is connected to the internet and working as intended.
After the user connects to the SoftAP of your device they have to communicate with it somehow. This is usually in the form of an app or web page. An app or web page that you have to write and maintain. If you aren't a front end or app developer it's time to open your wallet again for another freelancer payment. This is the very first interaction customers will have with your product. It's not a place to cut corners. It can literally mean the difference between them loving your product or asking for a refund because the process is clunky. This interface has to handle all sorts of scenarios. What happens if the user fat-fingers their password. Your device will simply not connect and hopefully give you a valid error code. What should your device do in that scenario? What should your setup UI do in that scenario? There are lots of things to consider and handle here that you never spent a second thinking about when this was all just a maker project.
But your users never fat-finger anything and they enter their password perfectly. You have the correct SSID and the correct password. All we have to do is send it to the device. Done. But it's still not working. WHY ISN'T IT WORKING 🤬!!! The magic of it all starts to break down and you are forced to face the reality that all of this is very complicated and high tech. We are sending letters of the alphabet and numbers through the air to a device which then sends more stuff through the air to another device which then has to respond back. It really is magical when you think about it but wow can a lot of things go wrong. When you consider the number of settings that exist between the 3 devices involved in this process (your product, the configuring device, and the WiFi router) there are literally hundreds of millions of possible configurations. Most of the time things just work but when they don't, that's the problem field you are staring into.
Terminal?!? This Ain't the Airport
The other common way to configure your device with WiFi credentials is over a USB connection. This is pretty common in maker projects. One thing to be aware of though is that many of your customers will not even own a device with a regular USB 2.0 or 3.0 port. They have iPads or phones so this approach is not even an option for them. But suppose you do have some customers with USB-capable devices, how are they going to get their WiFi credentials to your product over that interface? Well, when it was a maker project you would crack open a terminal window and do your hacker thing and, viola!, connected to the network. I can promise you that is not going to work in over 90% of your customer scenarios. To them a terminal is something at an airport. So, if you want to use this approach you're going to need some form of application running that is dead simple and handles all of the serial connectivity. The user should launch an app, enter the username and password and hit "Connect". Now you just signed up to write and maintain another cross platform application.
Customers Aren't Developers
This is a blind spot of so many software developers. We are so intimately connected with technology that we forget all of this is complete black magic to most people. They have absolutely NO idea how any of this stuff works. Radio waves, gigahertz, tcp packets, and HTTP headers. It's all Greek to them. And it should be. The entire purpose of our job is to abstract those things away so they can use software and devices that make their lives easier. Just like you don't have to know the details of the CAN protocol to drive your car, your customers shouldn't have to understand the difference between WiFi channel 6 and 11.
If you have never had the pleasure of trying to walk a completely non-technical customer through the process of connecting to a device via putty or screen I highly recommend it. It's a very...educational...experience. You will get a lot of feedback around things that seem so obvious to you that are complete mysteries or giant mental leaps for your customers. Remember, they aren't developers.
The last thing to remember about your customers not being developers is that they are unlikely to RTFM (read the freakin' manual). You'll put an instruction card right on top of the box with beautifully illustrated steps on how to set things up. They will still send you emails asking questions that are clearly and eloquently explained in step 5. There is nothing you can do about this other than be prepared. It's human nature and you signed up to deal with it when you decided to turn this thing into a product.
You Can't Test All Scenarios
As I mentioned above the number of configuration permutations that exist for your device to handle is astounding just to get connected to WiFi. Did you know that some routers shipped to the US broadcast on a non-standard US WiFi channel by default? Did you know that your main WiFi chip doesn't support every standard WiFi channel? What happens when somebody has WiFi repeaters set up and your device gets placed right in the gray cross section zone in the house where the signal is really not great to either of them? What do you mean you don't have an Actiontec router that was configured by my super-smart nephew 5 years ago when he was just learning all about computers?
You can't test every scenario and thus you are bound to find some crazy ones. They'll find you actually. They'll find you in the form of "My device is not connecting to the WiFi, please help." Emails like that mean you're in for a fun adventure of learning about somebody's jacked up home network configuration.
Wrapping Up
When it comes to getting your device connected to the internet you do the best you can. You have a Mac, Windows, and Linux machine to test with. You have an iPhone and Android device to run through your setup process. You try your very hardest to do stupid, unthinkable things to break that process and then harden it so your customers can't break it. And then they will. You'll cry a few tears, learn something new, and then you'll make your product setup procedure even better. As long as you're prepared to do that you'll be ok.
That's it or part 3. Next up we're going to talk about creating an enclosure and how angry your wallet is going to be about it.
Top comments (0)