I said nothing about NOT using the cloud. It's all **about** using the cloud as much as possible to simplify the devices and to avoid unnecessarily building the same kind of backend for every project, over and over again. And to whoever said that people aren't still building custom backends, I offer examples: nest, fitbit, jawbone up, nike fuelband, automatic, WeMo, hue (light bulbs), whistle, Streetline (parking sensors), Sensys, (traffic sensors), various divisions of GE, Basis, etc. Advertising and datacenter management are the main places I know of where 3rd party analytics backends are widely used today. Not too many years ago, one required a team of probably 5-10 developers-- EEs, firmware, web app developers, a TechOps team, etc., to just get this basic functionality. Now a hobbyist could follow a tutorial like this and do it over a weekend. And there are lots of other devices with switch-based sensors or basic analog inputs that could follow this pattern and build different kinds of devices, with custom dashboards. So no need to stick to pedometers. At this point, I'm done responding-- the free flowing anger in this space makes it a tiring place to discuss anything, which is why I had previously not even submitted anything here. But I hope people have fun with this. And if you don't like something, add some missing functionality, or have an additional application, by all means send me a pull request so I can share them.

Pedometers (devices and apps) seem to work poorly on elliptical trainers and won't work at all on bicycles. So if you want to track these activities , it's helpful to have multiple specialized trackers that know what's going on for different use cases and then combine the data in the cloud. Combining the data is a project for another day, however. I'm sure future elliptical and exercise bikes will build that functionality in. This is the general trend a lot of us expect-- lots of small, specialized devices everywhere, posting to API-accessible backends with analytics.

(A) ad hominem attacks are never appropriate here, although they're all to common. Learn some commenting manners, which exist to promote better reasoning and more useful commentary. (B) I'm not talking about on-device analytics and on device dashboards. I'm talking about he full power of what you can store and calculate in the cloud, since all the data is there. In the future, I could decide to add a regression analysis combining this data with my sleep and work schedules, or plot my average cadence over time, even though I didn't calculate rollups of that while the data was being captured. With fairly small effort and coding, I could build a leaderboard and stats across thousands of users, and have regional comparisons to create competition. And i sure don't want to do all that on a battery powered constrained device in the field.

I know quite a about low power, and have myself complained about people saying that mA is low power-- I've been building wireless sensor nodes averaging 100 uA down to an energy scavenger at nA levels -- but the key here is the part about average. The 5 uA is _while it's on the WiFi_ -- I turn almost everything off, down to low uA levels when the accelerometer shows it's idle for 10 minutes, and use the wakeup pin interrupt to get out of deep sleep when I start pedaling again.

This is embedded software-- I'm passing data to an interrupt routine. This is a common design pattern, not the usual wonton misuse of globals. Can't pass parameters to an interrupt routine. In C, I might have encapsulated the global with a getter/setter, but the only benefits to that here would be to hide data via file scoping (which imp doesn't have), and to validate the value of a Boolean for.... what? I could have used a semaphore, but imp code is not interruptible, so that wouldn't do much either. I appreciate constructive coding suggestions and pull requests, so please feel free. But don't assume others are idiots based on such a crude heuristic.

Ok, so one of you is accusing me of flacking for my wife's company to make a quick buck, while the other accuses me of taking credit for her company's work. Tough crowd!

I understand the concerns. I've tried to disclose appropriately and focused on two things: 1. This is a legitimately new approach. Pretty much everyone I know in the IoT and connected device world is still building a backend infrastructure and coding their own APIs, even for pure analytics apps. 2. A detailed tutorial seemed appropriate so people can see some of the ins and outs of doing this, and to show that now non-experts can do this kind of thing as a weekend project. Obviously, this doesn't eliminate code or servers. But the big win is that I don't have to deal with any of that. It's like saying Rails wasn't a big deal because all the code is on the framework, or AWS isn't a big deal because there are still servers. So look, I'm not a PR flack or something, I've been working on wireless sensors professionally for over a decade and I'm just excited to see the work get a easier, because I've spent a lot of the past 6 years building out and maintaining a scaled sensor backend before. It sucked, and I don't want to do it again if I can avoid it!