Over the first quarter of 2018, we will be releasing Prota Charles, the next version of Prota OS. All of our products will be based on this new platform, and we will also provide software upgrades to our existing users to show our gratitude for their early adventures and feedback.
But what makes Prota Charles better? Why is Naran making this new version? Will my bug be fixed in this version?
Here’s the answer.
Short History of Prota
We’d like to start by a little history of Prota for those who are new to our systems. The very initial version of Prota was born in 2012 (the version 0.1), and it only supported Raspberry Pi B back then. It didn’t support any WiFi dongle, had no Bluetooth capability, and was only accessible through its IP address. However, it contained Prota’s first automation engine called Ambiency and was compatible with about ten 3rd party products and services to create automations. USB web cameras, Volumio and Webhook were the most popular apps used; some used it for personal cloud storage and testing Raspberry Pi’s GPIOs.
We launched myprota.me for those who did not have any knowledge in computer networks to help them easily access their Prota without typing in their IP addresses. We also added WiFi drivers and a web UI to configure WiFi network to use Prota without plugging in a LAN cable.
While fixing lots of bugs and introducing new features to Prota OS, we decided to build our own dedicated hardware running Prota natively. So we built Prota S along with MicroBot Push in 2015 and made it available in the market in 2016.
Many things happened in-between, and we learned a lot by launching real hardware products; we deeply experienced every single step that needed for launching a new hardware product including designing PCBs, dealing with BOMs, optimizing mold for manufacturability and assembly, various certification processes, legal documents, patents, implementing firmware and mobile apps, deploying cloud services to support the product, integrating popular 3rd party services including Amazon Alexa and IFTTT, setting up C/S, launching the product website, negotiating with major distributors, and selling on Amazon (and it’s still missing a lot of details).
We think we now know something about hardware products and what we need to focus on. We learned by getting our hands dirty with numerous of trial-and-errors.
The Fundamental Issue
Prota is still very young, and we are aware of many critical bugs that we haven’t got a chance to address. Many issues that our current users are experiencing now are very much related to a single fundamental issue. We released many patches and upgrades incorporating workarounds to these, but Prota still suffers from this fundamental issue which leads to many bugs and unsatisfying user experience; the hardware.
Hardware is very unpredictable, and this unpredictability increases by orders of magnitude when it operates in wireless networks. Hardware can fail at any time even if you write perfect software for it. It’s sometimes very time-consuming to figure whether an error is caused by hardware or software (or both). Very discouraging when you discuss this kind of errors with engineers because no one knows what’s happening.
Our Solution — Prota Charles
Prota Charles is our third major version of Prota, and what it solves that the previous versions didn’t is the hardware. Prota Charles operates in the cloud and is designed to overcome the fundamental hardware issue by applying basics in distributed computing. Let us explain how we’re applying Charles to the existing MicroBot Push system.
How MicroBot Push works now
There have been two different ways to use MicroBot Push before Charles. The easiest way is just to use the MicroBot Push app on a smartphone and connect via Bluetooth. The other way is to use a Prota S or Prota Pi to pair MicroBots and connect via the Internet; the Prota device works as a Bluetooth-to-WiFi gateway in this case. This setup has the fundamental issue mentioned in the previous section. When it isn’t working, we need to figure out whether the MicroBot is paired with Prota, whether Prota is connected to a WiFi network, whether the WiFi network is connected to the Internet, whether the smartphone has Internet connectivity, and so on. Of course, we also need to make sure all the corner cases are handled properly, and this is the most time-consuming task in the development process. We even saw a case where our user kept failing to download updates from our server due to the unpredictably slow Internet packet routing from our server to the user’s device. We use BLE a lot, but we found that sending and receiving data that exceeds its typical packet size wasn’t quite trivial.
We learned (in a hard way) that trusting any wireless connection is not safe and synchronous handling is never possible when there are ten thousand users relying on our code that involves BLE, WiFi, Internet and AWS.
Charles makes it different
There are three different parts in Prota Charles; the hub, relaying edges and device edges. The hub refers to the Prota Charles in the cloud. This is the only one smart hub we will ever refer to. A relaying edge is an Internet-connected device bridging between the hub and device edges, and a device edge is a smart device like MicroBot Push (perhaps, any BLE-enabled device for now). All edges connect to the hub whether they connect directly or via one or more relaying edges and fulfill what the hub is telling them to do. And yes, a device edge can connect to more than one relaying edges. This makes the whole system far more stable and responsive as a smartphone can also work as a relaying edge.
MicroBot Push is a device edge, and your smartphone and Prota S and/or Prota Pi work as relaying edges. Push decides what relaying edge to use to communicate with the Prota hub in the cloud, and relaying edges implement various mechanisms to make sure the hub can always see MicroBots and eventually deliver orders even if they are disconnected temporarily.
You are always using the fastest and the most stable relaying edge, so you get the responsiveness as a bonus (and the relaying edge could be your smartphone itself if you’re close enough). Another perk you get is that you can use any unused, old smartphone as a relaying edge, so you wouldn’t need to buy a Prota S or configure a Prota Pi to control MicroBots away from home.
So… what now?
Replication is one of the most useful, usable and used solutions in distributed computing. By replicating, the chance of failure decreases by 50%. Prota Charles can now use multiple relaying edges to talk to device edges like MicroBots and vice versa. Even if all devices die, you at least know they are dead for what reasons and when. This makes it far more informative and user-friendly as well as easier to maintain and upgrade.
Prota Charles is a big change, so we will carefully roll this out to existing systems and all of our new products will be based on Charles from now on.
Beta testers are always welcomed, but we prefer to give early access to hard Prota users first. Please let us know.
