The Pain of IoT Data

Posted by Diego on 11/2/17 1:00 PM
Find me on:

The Pain of IoT.pngShared pain brings people together. It comes as no surprise that I felt quite sympathetic reading "IoT is easy... they said". At least we aren't alone! In the article, the founder from Fitmatic.com talks about trying integrate data from wearables and failing because his team assumed that sensor data is like any other data they had handled before. What my development experience at Geeny taught me is that building an IoT platform is nothing like my other “scalable CRUD-as-a-product” experiences.

What is needed to create a product or services on top of existing IoT APIs? There are all kinds of wearables that count steps. In theory it should be easy to use this data to create an additional value for the user. Unfortunately it isn’t exactly straightforward.

IoT sensor data isn't trivial

Going back to the article, Chris from Fitmatic mentions how he used earth rotation as a factor for his steps synchronizations system. This might sound like a stretch if you haven't done IoT. We experienced weird sensor data manipulation ourselves when working on Dogsens’ a POC* of fitness tracker for dogs

Did you ever wonder how to convert dog steps to calories? It didn't strike us as something so hard until we started implementing it in Dogsens’.

Testing with dog wearing dogsens.jpgThe idea was simple: reuse the existing technology for measuring fitness data. Put it on a dog, add health insights and wellbeing recommendations for dog owners. The app would notify you when something is wrong or help you find your dog if it goes missing. It was also a first one of many challenges: what's the average calorie intake of a dog? Well, it depends on the breed, its weight, its “steps”, its heartbeat…and of course the model is just an approximation.

Biometric data transformations and estimations based on IoT devices remain an obscure topic. In our case, we had to license certain algorithms from a third party specialist in order to get data we wanted. And of course, this wasn’t exactly open source. Bring in the lawyer, license the algorithm, provide guarantees for IP, and well…that’s one of the reasons we thought building Geeny was a good idea. Too much science and legal issues just to build a valuable product.

Wait, I’m not done yet.

IoT: consuming data from wearables

Something that I feel wasn't mentioned strong enough in Chris’s post was the amount of "boring" tasks you'd have to do in order to consume data from a third party wearable device.

My team implemented DokiDoki, which is a very simple tool for visualizing heart-beat data using existing wearables, just like in Chris' case. In order to support three different data providers, we had to deal with two Auth Systems, three REST APIs and pull-push semantics (depending on the vendor). All of that just to get a visualization application in React. Sure it wasn't hard, but it was definitely too time consuming to solve a problem that produces so little value (a visualization app).

Interoperability and its nuisances isn't rocket science but can be incredibly time consuming if your team is small or your project isn't very complicated.

IoT: we need better solutions for data streams

IoT sensor data, and the fragmented landscape of vendors calls for better solutions. New standards might solve some of theproblems, but it's uncertain when and if it will happen. At Geeny we feel that the first step would be to share solutions for common problems. Embracing the marketplace approach of open platforms and provide the right incentives so we spent less time in earth rotation problems and more on products.

Interested in knowing more? Sign up to try out the platform!

Become Geeny Developer

*POC = proof of concept

Topics: Insider, Geeny Dev

Be the first one to know

Recent Posts