An IoT hackathon that makes a difference

Hey guys!

A short while ago our IT trio — Mail.Ru Group, Intel and Unwired Devices — held an IoT hackathon. Yeah, this could have been “just another IoT hackathon” since every other IT company now holds one, but we found a way to make our event a real difference: we held it in a brand new format.

This hackathon opens a whole new series of IoT events that will create an area for discussing today’s IoT technologies — an area intended not for enthusiasts alone, but also for technology developers, industry representatives and investors interested in IoT opportunities.

A very minor part of the “coffee fuel” consumed during our two-day hackathon

This IoT hackathon was a pioneer. Now we want to share why we held it, what it was like and what lessons it taught us.

So, what’s wrong about typical IoT hackathons? To start with, they usually involve no IoT as it’s used in the industry, housing or even smart home. It’s sad, but the educational segment in the IoT (and hackathons can be regarded as educational events) is currently empty. While we have 6LoWPAN for the industry, LoRa for housing, and Z-Wave and ZigBee for smart home, for a typical hackathon we’re most likely to have a plaything working on some regular Wi-Fi hardware, developed in an environment like Arduino or similar, the only serious part being analytics and visualization based in a cloud like ThingWorx or Azure.

Of course, you can use such platforms for trying possible software solutions and prototyping some IoT services, but you can as well do all of this just on your laptop. To demonstrate how data is transferred to the cloud from an electricity meter, you can use either Raspberry Pi or a laptop — any will do nicely for that. But neither will do if you need to transfer data from each of say 263 electric meters of a multi-dwelling house. That said, RPi and a laptop differ here in terms of quantity, not quality.

We decided to close this gap and held a hackathon based on the IoT technologies — both software and hardware — that are used in the industry not only today, but will be used tomorrow.

The second problem about typical hackathons is that they are usually organized in a “closed-loop” way, where the participants get some software/hardware/instructions as input and the prize awards as output. As a rule, there is nothing else to happen, neither before or during or after the hackathon (except the coding activities, of course). We addressed this problem too, and, as mentioned above, turned our hackathon into a discussion area open for the participating teams as well as the developers of basic technologies, industry representatives and investors interested in IoT opportunities.


In terms of technologies, the IoT comprises three subsystems:

  • data transfer: wireless communication technologies for connecting meters and management systems;
  • data collection: hardware and software systems for collecting and storing data from connected systems;
  • data processing: software environment for analyzing and visualizing the collected data.

For our hackathon, we took… all the three subsystems, of course!

  • Data transfer: the participants were offered hardware kits for building small mesh networks that used the 6LoWPAN protocol and were based on modules from our Unwired Kit. The kits included meters for air temperature, air and soil humidity, gyroscopic accelerometers, relays, various buttons, GPS modules and others. The kits could be connected to wired sensors from Seeedstudio.
  • Data collection: a gateway between 6LoWPAN and Wi-Fi networks based on an Intel Edison microcomputer that we assembled specially for this hackathon (and, of course, for future use: Edison solutions look smart as they allow for powerful computing capacities and plenty of memory in an ultimately small case).
  • Data processing: Tarantool database management system, which at this hackathon turned from a DBMS into an IoT platform. Tarantool has a Lua application server on board. It allows writing scripts for data collection (for example, our system uses the MQTT protocol), data processing and further transfer to higher-level systems.

These components would be enough to build a wireless SCADA system for some real-life object — anything from an office building to a plant site (in the industry, wireless SCADA networks are of special interest with regard to open-air sites: while it’s more or less possible to install low-current communication wiring inside a building and use it with the good old RS-485 + Modbus, a similar mission becomes absolutely impossible in a quarry, or possible but absolutely wasteful at a large electric substation or a water treatment plant).


As early as we fixed the list of hackathon participants, we could see that the suggested technologies have strongly influenced the hackathon’s content. By the beginning of the event, we had three distinctive categories of participants.

Category #1 — the classical one: teams, including student teams, that had their own projects and were eager to enhance and promote them within the hackathon. However, the suggested hardware and software influenced this category too: some of the teams asked to provide them with specific modules like GPS or accelerometer.

Category #2 — professional developers who felt like having a little exercise and getting a closer look at something new for them like MQTT, wireless sensor networks or the Tarantool database.

Category #2 — teams from the business world, not necessarily related to IT, but interested in the technologies suggested for the hackathon. For instance, we had a team from a successful agricultural company whose business was year-round herb cultivation. As they admitted, their main interest was not to create something in two days, but to get familiar with modern technologies. Year-round agriculture in our area is quite bothersome as it requires ongoing climate control, watering and lighting (for example, I learnt that some plants had daily cycles, and these plants got suppressed if you lighted them with the same flux of lumens 24 hours a day), so today many agricultural businesses consider the latest technologies for wireless monitoring and automatic management of their greenhouses.

All in all, we got an exciting cocktail: teams from category #1 moved on with their projects, teams from category #2 became a good example of skilled and task-oriented work for category #1, and teams from category #3 were engaging talk partners both for the organizers and for some investors who cared about technologies that were of interest for their prospective customers.


We didn’t invite industry representatives at our first hackathon, but they still came, and not only as team members.

Further we highly welcome the idea of building partnership with the prospective customers of whatever the teams can do at our hackathons — up to holding a hackathon patronized by some major customer that suggests its business cases as problems for the teams to solve. Advantages for the customers are clear in this case, and for the teams this is a perfect opportunity to get in touch with people who represent some real business and have a good understanding of all business problems — including the problems suggested for the hackathon and those to be faced underway.

This insight is often wanting, even when we talk about mature startups that have not entered the big market though. Even when such startups have a solid technological basis, they are often unaware of the economic, law and political problems that may come their way. So, we were excited to provide them with feedback from the business — with real feedback that sometimes could be harsh, not just the formally polite “well done, good job, go ahead”.

Of course, this can lead us to a dangerous gap between the two realities: that of the business and that of the hackathon. Business expects to see a smart-looking out-of-the-box solution, ready to ship within 10 days after payment. Meanwhile the teams come up with some “kinda done” solutions that they have fudged in a hurry over the two days (and one night) of the hackathon. But as practice shows, it’s quite possible to make the business understand the startups’ aspirations.

Speaking from the investors’ grounds, hackathon projects represent no solid venture capital — unless some business angel takes such a project under its wing. That’s on the one hand. But on the other hand, investors care about the situation in the industry itself, so sometimes they feel interested to take a look at startup teams, to listen to their thoughts, and maybe to watch their further luck.

Although our hackathon was held out of business hours — it closed at Sunday night — the attendees included representatives from CommIT Capital, IIDF, Skolkovo and other investors. They talked to many participants and asked to share the contact information of some teams.

The jury and their judging

At the end of the hackathon, each team made a 6-minute report about the results of its two-day work. After two hours of reports (the total time included reports from two dozens of teams and coffee breaks so that everybody had some time to chat with the recently reporting teams) the jury recessed for deliberation.

The jury was staffed with the representatives of all the three organizers of the hackathon. Our first decision was to abandon the trivial scoring pattern where every member of the jury comes with some points for each team and then the points are summed up. Our major objection was that the jury members would focus on different aspects of the teams’ work (like points for artistic impression and technical merit in figure skating), so the value of the final points would be vague.

That’s what we started with: since the first minute of the discussion, the jury fell into three camps. Mail.Ru Group representatives focused on technical implementation, Intel cared primarily about commercial issues, and Unwired Devices were in the middle, slightly leaning towards commercial issues though. As a result, we got a lively discussion instead of formal voting. We were pretty much unanimous about the outsiders, but our decision about the leaders, especially about the team placing, changed several times during the discussion.

Here is what we assessed:

  • Work at the hackathon. Since about half of the jury members were busy consulting the teams on technical issues throughout the hackathon, and some of them even stayed at the office overnight, we kept aware of each team’s activity and how much work was done independently.
  • Usage of the suggested technologies. Our minimal requirement was to use Tarantool.
  • Commercial matters. This said, how attractive the project (or at least its idea) was for real-life implementation.
  • Quality of presentation. Surely, we didn’t require the team reports to be professional performances, nor did we consider technical issues during the demos (every team who decided to make a demo had some technical issues). Our minimal requirement was to make it clear for all jury members what the idea of the project was and why people might need it in the real life.

The discussion was mostly to find balance between assessment criteria #1 and #3. On the one hand, a hackathon is a coding competition; on the other one, our aim was to hold something more than just a regular hackathon. And since some of the participants were professional developing teams, they would have become the only prize winners had we considered only coding merits.

Besides — and that’s what made our results differ from a mechanically calculated scoring total — a failure to meet any of the criteria could knock a team out of the shortlist. For example, even the fanciest presentation could not save a team that didn’t use Tarantool or that spent most of the time for discussing business models rather than coding.


The first prize is due to the “Agrogenez” project: an agricultural monitoring system (not the system we mentioned above, that one was called “GoodFarm” — as you see, the IoT gains popularity in the agriculture). This team moved up to the shortlist at once and split the jury into two camps as they tried to agree on its placing: on the one hand, this was a solid team that launched its project before the hackathon and will surely go on with it, but on the other hand, they haven’t done much at the hackathon and often needed the developers’ help from our side.

The second prize is due to the “Cool-IoT” team: wireless fitness sensors. They suggested equipping all fitness machines and devices (up to hand weights) with accelerometers and other sensors that collected statistics about sets per exercise, weight lifted, etc. Modern training machines are already equipped with similar systems, but they are rather costly, so many fitness clubs cannot afford such machines. In two days, this team made a prototype of a hand weight with an accelerometer (implemented as a light-weight plastic box rather than a heavy piece of iron) that really transferred the number of lifts as 6LoWPAN data to Tarantool, which nicely visualized the data in a web interface. The team’s soft spot was the presentation: they gave little details concerning the implementation and commercial prospects, which made some of the jury members doubt the project’s feasibility.

The blue box is a hand weight, though it doesn’t look anything like that

The third prize is due to the “ColorControl” project: a smart lamp that changes its color depending on the words you speak. For the words “deep ocean” it gradually gets blue, and for “the Sahara Desert” it gets yellow. This project didn’t use 6LoWPAN networks: speech processing was done by Intel Edison, and speech recognition was powered by Google API. The team made a great presentation talking about the atmosphere their lamp could create, for example as you read a fairy-tale to your kids at night. Their stumbling stone was using only third-party cloud services for basic data processing together with vague commercial prospects. This lamp looked great as a standalone product, but the jury had doubts about building a business on this technology.

As you can see, it was not easy to choose the winners. Even now, as I’m writing about the projects, I can’t help thinking that we could as well put the winners in a different order and find plenty of convincing arguments for that. In fact, if we had our will, the jury would be happy to award 5 or even 7 first prizes.

Lessons taught

Our main lesson is that we’ll need to make even more arrangements for our next hackathon. In fact, the teams got at their disposal two hardware platforms and three software ones that were complementary, but many of the participants had no experience of using any of these platforms. This is why we often had problems troubleshooting the systems, and it was unclear where the problems were rooted: in 6LoWPAN modules, in our Edison-based software, in Yocto Linux, in Tarantool, or in the way how all this was addressed from the code written overnight Saturday into Sunday morning. In practice, we encountered all these variants and their combinations.

The organizers were puzzled at this device up to the final presentation: what’s that and where does it go?.. As it turned out, this was a detector of harmful gases

Anyway, this kind of experience was useful for us too: now we have a better idea as to what kind of questions (not only technical ones) are likely to come from inexperienced users, what they expect, and how we can improve our documentation and use case studies for the next hackathon.

Putting all our conclusions as theses:

  • we’ll make more efforts to popularize the capabilities of Tarantool and Lua — the hackathon participants were primarily asking for specific examples;
  • we’ll focus more on getting-started documentation — both for hardware and software;
  • we’ll make the next version of our Unwired Kit fully plug’n’play — today the firmware in our radio modules is not universal, so it needs be changed sometimes to allow connecting specific accessory cards.

That’s all about technical issues. Speaking about the impressions in general, both organizers and participants liked this hackathon, and we hope to hold more events of the kind in future, gradually blurring the boundaries among hackathons, startup competitions and a public discussion area for IoT needs and development issues.

What’s next?

We hope that this Industrial IoT hackathon (indeed, we had no smart home project or a pedometer bracelet, but we had several teams with projects related to agriculture!) will be the first but not the last one to happen. We love the idea of promoting IoT technologies and demonstrating today’s hardware, network and software IoT solutions to everyone who feels as motivated as we are.

But we don’t feel like holding hackathons just for the sake of hackathons, that’s why we look for partners from business. If your company would like to become an organizer of a hackathon like ours — to promote its products, solve its business problems or for any other good reason — we are always ready to discuss our possible partnership.

Stay tuned.