BlogOne1
One of the initial prototype, 18 Feb 2015

Living in an apartment complex at Lanco Hills ibeyonde, we as a family used to face one key issue. When in the evening we had to go out for a walk all of us needed to carry a key. Since we had only three of them, we had to agree on certain protocol, such as the order we come back, so that no body waits at the door for the other to open it. What if we had a smart door solution where we could all feed our finger prints and then could go in and out without carrying the physical keys. Issues like these and some others motivated me to look into the market to buy such a device. There were hardly any, though there were many websites claiming to be close to the solution. This was in late 2014. This got me started on building my own door cloud solution.

I had raspberry pi B+ at my disposal. I ordered various sensors, pi cams and then started working on such a smart device. As the work progressed, I came across more such issues that could be solved by the set of smart devices that I planned to work on. One of them was smart switches that can be turned on and off by decision making software running in the cloud taking input from smart sensors and rule engine.

Internet was very helpful, the active community on internet helped me get kick started.

IMG_0299

This is a picture of my lab with a Raspberry pi B+ and several sensors hanging out. (Nov 2014)

I also hand made a cardboard box to hold them neatly !

As time progressed the project matured and several more people joined me. I was no longer working alone but had a small team consisting of electronics engineer, a design engineer, android programmer and website designer. We also had more sensors and other things integrated on the board. Initial versions were cloud enabled by a separate gateway device, that would route the surveillance videos and other information on to the cloud. (This model changed later, though).

With the help of the electronic engineer we were able to create a shield for the raspberry pi that carried all the sensors. Carrying this compacted device was a pleasure in itself. (Feb 2015)

Embedded Software Development

 

The device started in hotspot mode, would publish the menu on the initial browser screen. You could use it as it is as a local surveillance device or you could configure it to connect to the local WiFi so that it could be used over internet. We also wrote an android client that seamlessly configured the device from discovery to getting default network to switching the device to local WiFi. More about the android client in another wiki: Configure using Android

As time progressed, we felt we were wasting hardware on a local gateway. We questioned ourselves “Why we did not think of it in the beginning? We could have saved some time! My opinion was that it was not waste of time, but a local gateway was useful to test the stuff initially when it was not stable. In all, a local gateway just provided us a way to test our platform much more efficiently. Later we moved the gateway to the cloud, basically to EC2 instance. At the same time we started using EC2 and other amazon services. Why we moved our iot, offering it to amazon services is a good question and deserves a separate wiki of its own (coming soon).

Next we started looking for a voip solution for our cloud bell. After much of research and talking to several of our colleagues and companies, we zeroed down on an online PBX. Asterisk is an open source implementation of a PBX. After doing some research we decided we will use asterisk to provide voip service to the cloud bell. We got asterisk server installed on an EC2 instance, wrote php APIs to dynamically generate sip credentials and configured those on the device. At this point we had a fully functional cloud door bell. On the press of a button it initiated video voip call to all configured mobile phones and you could see and talk to the person at your door!

Next in line was to get the finger print reader and a lock interface to the door bell. At the same time one of my partners was working on getting an enclosure made for the device. Though we were able to get the design of the enclosure done in a month, giving it a physical shape was an iterative process. We started with 3D designing and printing, initially went for cheaper variety. The results were not very pleasing, the 3D printed boxes were structurally very flimsy. So, we went for higher quality one with polish. Still it was nothing close to a professional looking device that we could launch in the market. We also tried metallic ones, but then they interfered with the WiFi signal. We even tried wooden ones!

So, progress was very slow on the hardware front. However, on cloud side, the progress was immense. While at start, our perspective was more local as in a local gateway, local configuration of device, port forwarding on local router etc., gradually we moved to more of cloud based solution where all you had to do was add your device to your cloud account and then you could control it with internet. So you could configure your device from internet, and stream data, video and audio over internet to any of your other configured device. Streaming data was bit of a challenge but we finally mastered the art of Nat traversal to stream time lapsed images out without the need of port forwarding. This does not work from all networks, specially the ones that are very busy, they have a habit of loosing some datagrams. We put in place a slow but reliable fallback in case the udp was unreliable on a network. The cloud side was also streamlined with vagrant and ansible to take care of provisioning, configuration and scalability of various cloud pieces. More on that in the blog: Cloud enabling iot.

This journey is still on!