Ellipto: a DIY Fitness Tracker and Dashboard In 70 Lines
New submitter InternetOfJim writes: "This is one of the most fun weekend projects I've done in a while — a fitness tracker for my elliptical trainer. But the real agenda was to figure out how lazy I could be via web services (Keen IO and Brace IO) and development platforms (Electric Imp). Quite lazy, as it turns out. I wound up with a working device and a nice realtime dashboard with no soldering, no backend to manage, and surprisingly little original code needed beyond the sensing and power conserving parts of the firmware and a little javascript to customize the dashboard."
What's up with all the glorified pedometers these days? When I read 'fitness tracker' I was thinking about something that tracks your fitness, not just your steps. He could also install any of the thousands of pedometer apps on his android phone and be done with it.
Stop. InternetOfJim, it's good that you came clean on the fact that this is your wife's company, but you really needed a bold "disclaimer" in both the summary and article for me to think this is anything but a self-serving post to advertise something that will profit your wife and, by obvious extension, you. The fact that this is your first /. submission only supports this.
you ignore the massive libraries it uses.
I can write anything you want in a single line of code, given enough time to make a library that encapsulates all the required functionality into single function call.
Its not impressive, it just shows how you think you're impressive for using so much of someone else's hard work and acting like you did it.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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!
r.e. self serving: sure, but it also serves others (like myself) by being educational. I hope Keen IO makes a ton of money and goes on to create more cool things.
...but you really needed a bold "disclaimer" in both the summary and article for me to think this is anything but a self-serving post to advertise something that will profit your wife and, by obvious extension, you.
1. This is a legitimately new approach.
No, it isn't. I have several 'IoT' things, NONE of them use some custom backend infrastructure somewhere else.
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.
Then you're a newb with little experience who must have just recently discovered the NEST and think thats normal. You just included the backend infrastructure on the device, and for a single object. This is how pretty much everything started. Years ago.
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.
Except its not a weekend project for those who don't already have considerable know how in the area.
Obviously, this doesn't eliminate code or servers. But the big win is that I don't have to deal with any of that.
Congratulations, you've caught up to 15 years ago. Hell, I have chips with ethernet and serial interfaces that have a built in web server (and a couple other protocols I don't remember) that simply require you to send it a few serial commands to return some html when connected via ethernet. Thats from the late 90s. Just because you recently discovered libraries doesn't make it impressive.
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!
So you think because you've only been doing one pigeon holed type of project that there is no other out there?
Its like you've never even heard of an IP camera from 15 years ago.
Worst part is that this made the front page of slashdot.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
I mentally shut this out when I realized debounce() and tilted() were sharing a global variable called "ignore". Yeah, let's see what happens when feature creep sends this beyond 70 lines.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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 actually a nice little project. It is what many projects out there should be if they want to be useful to normal people. It has a fairly simple hardware component and a fairly simple software component and a fairly decent reason for being created. My kids could take this as a starting point and within a few days have something physical that they have created and be able to modify it from there to do something useful or educational or both. These are the sorts of projects that should be done in school to show non-geeks they they can make things too.
Is this a slashdot-worthy article? I think it probably belongs on hack-a-day or something like that rather than slashdot, but I don't really care. If you care then you should complain to the moderators about their submission standards and stop beating up on someone who actually did something rather than just whine about how much of an unloved genius they are.
(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.
Electric Imp would be interesting if open source. Alas, it's not. It's proprietary and everything is in "the cloud," so if the company dies so do all the projects and products that work with it as you lose access to the Imps that are deployed.
What I find amazing is that product's like Lockitron are totally dependent on this may not be there tomorrow proprietary cloud platform.
Facebook is billions of individual "Skinner Boxes." And if you use it you are the pigeon!