A core value at Polymorph Systems is innovation and for the fourth and final H4ckd4y of 2014 we decided to venture boldly where as Software Engineers few of us have gone before, hardware hacking of the Internet of Things.
It seems as if the use of the term “the Internet of Things” (or IoT for short) is coming up more and more. In fact it is estimated that by 2020 there will be 50 billion Internet connected devices around the world of which only one third are expected to be computers, smartphones, tablets, and TVs. We are truly only limited by our imaginations in terms of what the other 66.7% of these connected devices will be.
For our first foray into the realm of IoT we decided to control access to our offices in Technopark Stellenbosch by means of the necessary connected hardware and then integrate it with a set of Mobile applications over the Internet. To make all this more achievable we were able to get our hands on a few Spark Core development kits (link: https://www.spark.io/dev-kits) which essentially are tiny Wifi development boards that can be connected to virtually any electronic components. In addition to offering some pretty easy to use hardware this vendor also offers their Spark Cloud service which allows one to expediently access your hardware through the Internet without needing to deal with any of the boilerplate networking such as reverse DNS or port mapping etc.
As with our previous hackdays we kicked off the day with some great coffee and a spread of muffins (the delicious not the healthy variety) and in addition were surprised by a cornucopia of jellybeans, smarties and potato chips. This all fed into a fun discussion of what we all agreed to be building and keeping it realistic in terms of what we would be able to produce during the next 2 days.
Without too much debate we were able to reach a consensus that we would strive towards producing as many client applications as possible that must be able to open the public entrance door on the ground floor as well as the glass door on our floor. In addition it would also be great if we could enable the Spark to report whether the doors are open or closed as well as what the current temperature in the office is.
One aspect of our previous hackdays which had to improved upon was the fact that despite the great system components produced, more often than not it ended up that integrating these components into a core deliverable proved to be more complex than expected and therefore not culminating in a demo-able product at the end of the time invested. The solution to this we decided was to follow an approach brought to our attention by Joakim Sundén who is an Agile Coach at Spotify (link: https://www.spotify.com). Joakim advocates an approach which they follow at Spotify where they do not build software by painstakingly crafting a perfect product that’s not functional until it’s fully assembled. They iterate in stages, developing a functional but rudimentary product at first and improving it at each step along the way.
An analogy that really clarifies what this entails quite well is that the objective is not to build a car but to rather provide transport. Building a car would entail starting with a wheel and then progressing to adding a chassis, then a body, and only then adding a windshield and controls that allow a user to start traveling. In order to achieve the purpose of providing transport it is more aligned with the end goal to start by delivering a skateboard and then by iterating to produce a scooter then a bicycle which then becomes a motorcycle and then, finally a car.
The “skateboard” of our intention to control access to the office electronically was whittled down to prove the ability to control the electronic locks on our office doors by means of applying the current from a power supply to it. This seems very elementary but all a skateboard really is, is a solid plank of wood with some trucks and wheels attached to its underside. This we achieved in record time which put us in great stead for the scooter phase.
For our “scooter” phase we intended to remove the manual intervention of a hand applying and removing the current to the electronic door lock. Fortunately it is possible by using the Spark Core utility app with the default Tinker firmware loaded on the Spark Core to easily write to a specific pin so within moments we were able to isolate exactly what we had to replicate in our own firmware in order to achieve our next goal.
On the “bicycle” phase we had to replace the Tinker firmware on the core with something we wrote ourselves and preferably be able to invoke this code via the Internet. The IDE provided by Spark.io is entirely web based and in very little time we were able to replicate the writing to a pin in our own code and deploy this code to the Spark Core unit by means of the web console. This then in turn allowed us to invoke our code on the unit by means of issuing simple Curl commands with the relevant security parameters populated and VOILA, we could unlock the security door remotely.
At this stage we really were taken aback by the rate of progress we had encountered during this small amount of time and took a little time to master working with a multimeter in order to assess what actually caused the ground floor entrance electromagnetic lock to unclasp long enough for the door to be opened. After isolating the individual wire originating from the intercom handset and the variance required we then supplemented it by extending it to the Spark Core so that we could achieve the same effect as a manual push of the open door button on the intercom handset. After a quick round of firmware and parameter adjustment in order to write to the relevant pin on the Spark Core we feasted on Pizza as all fired up hackers do.
With our bellies full of cheese, crust and bacon we returned to our pursuit and split up into pair programming teams to facilitate the expedient delivery of as many rudimentary mobile clients as possible which would amount to the conclusion of our “motorcycle” phase. At the end of day one this goal was achieved and we were able to demo the opening and closing of both doors by means of a Swift based iOS application, an Android application as well as a Javascript based web application ported to Android & iOS with PhoneGap.
After this successful demo we had an enthusiastic brainstorm session on the topic of what enhancements could be added to the already functioning access control prototype. This brought us to the end of day I and we all adjourned with great expectations of what we would be able to achieve during the second day of H4ckd4yIV2014.
As things go the second day of our hardware hackday got off to a slower than desired start because several participants had other responsibilities to take care of (Polymorph is not a non-profit after all) but as soon as the necessary time was spent we were all onboard and striving towards the completion of our “motorcar” phase. Some part of the day was spent refining the UI on the various client applications. Some hardware enhancements were also done to the access control system including a push button embedded in the doorframe sensing whether the door was closed or not and an LED above the door indicating whether the door was unlocked or not. Another little addition was a temperature sensor to gauge the temperature of the office.
All in all the 4th Polymorph hackday of 2014 was a great success enjoyed significantly by everybody who participated. Lots was learned although we realise only the surface was scratched in terms of what is truly possible in the realm of IoT.
Please feel free to check out the source code from this event here (link: https://github.com/polymorph-systems/PolyMorDoor)
