An IOT Device That Tells Dad the Stove is Off.

So, I just had my 3rd interview with a large regional newspaper. Also got talked about in the Philadelphia Inquirer, but those guys didn't even bother to talk to me, or read the information materials I sent them. So, not surprisingly, the article is full of inaccuracies, like me winning the 5k grand prize, which most definitely didn't happen.

Philly tech-sters bring home honors

Still, publicity is publicity, and it's an essential component in any kind of crowd sourced campaign, and if there's one single thing I'm good at, it's getting my mug in the press.

As for the device, I met up with patent attorney friend, and we've been doing searches on my implementation. More on that coming up later. In the mean time though, this blog establishes me as an author of prior art, should it ever arise.

But on to technical details!

So, I haven't updated the project log here, because I've been super busy doing publicity to lay down the ground work for a crowd funding campaign. Which means PR. But that's about to wrap up this week.

I've had a kind of knack for publicity since I was a kid, appearing in newspapers back when I was about 11, all the way to showing up on Latin American TV in front of almost a billion Latino's for riding a bicycle across South America. But not once did I use any of that for anything other than having fun. It's a lot of fun to show up in the media.

This is probably the 2nd time I've ever had to use publicity for an actual purpose. And that purpose is to get people aware of what I'm doing so that when the actual crowd funding campaign gets started, I'll already have the ground work done to get people to fund the product. And so far, the publicity campaign is starting to bear some fruit. This just came out over the weekend.

Cherry Hill native's newest invention heating up in the hardware community

And this is the release with the information packet.

Internet of Things Maker, David Nghiem, Wins the TechCrunch Disrupt NYC 2015 Hackathon

Which has been spreading its wings over the internet. I got back some responses from other local papers who wanted this news the moment the win happened, but given that I'm a one man show, doing prototyping, development, PR, crowdfunding campaign, business writing, that's a tall order.

And it's making me very aware of all my limitations. Yes, I know getting a startup going is a team sport. The problem is finding team players who you can trust who won't jerk you around, which unfortunately I've had to deal with over the last several years with my previous startup.



Ever watch the series "Silicon Valley?" I've been dealing with characters very similar to Erlich the last few years, except without the helpfulness, but with the same amount of arrogance, total lack of empathy, and far worse, the same amount of bad advice.

Yep! So, I'm also on the hunt for some help in the D.C. area to make this fly. This device, even though it was started as a $#!ts and Gigglez project to take care of a massive problem I had with my Dad, is rapidly turning into my comeback, especially after the crash and burn of my previous startup based on this.

Control Things With Your Muscles

Which you can read all the gory details about in the blog.

So, to start finding help, I met a new friend at a local bar here in D.C., who invited me out to check out the WeWork coworking space near Dupont Circle here in D.C.

WeWork

One major thing I've learned out here is that for entrepreneurs, community is your lifeline. If you don't have a community, your idea, your business, might as well be dead. And I learned that lesson the hard way with my previous startup. Finding the right people who know what to do, instead of sticking with people you know who profess to know everything right to do, is the most important thing you can do for getting your idea off the ground. Again, I learned that lesson, the hard way. Don't do what I did. Go find the right people.

Speaking of finding the right people, technology wise, I'm starting to hit that point where I'm going to start needing help. I got in contact with the IBM Watson people to see if I can get some time with integrating some of Watson's capabilities with the device. I'll have more on that later, as things progress.

I got back from the Twilio Signal Conference in San Francisco, and it was a blast! The week before the Signal Conference, I was running around like a mad man getting the rest of the components I needed for version 2 of the device. And they all came in just in the nick of time. But I wasn't able to get it done before I flew out, so when I got to San Francisco, I crashed at a friend's place, and finally got the 2nd iteration of the prototype working in his kitchen, which you can see here.

They also had a hackathon carnavale event going on, where the stovetop sensor swept the stage prize. Apparently, they've never seen someone send a text with fire before.

But it was the Twilio Hackathon Carnavale, so the prizes weren't as, um, interesting as TechCrunch. They definitely were nothing like the TechCrunch Twilio prize of the free trip! Hey, I ain't complaining about the prizes! I wouldn't be in San Francisco if I didn't win at TechCrunch Disrupt's Hackathon with this!

"I went to San Francisco and won at the Twilio Ba$h Hackathon Carnavale and all I got was this lousy T-shirt..."

The Twilio Conference is definitely a must go if you do anything that involves telecommunications with your phone. The Internet of Things part was really small though. I'm predicting that it will get much much bigger. Still, the stand out seminar for me was using IBM's Watson AI API and php. I definitely can use IBM's Watson with some of the applications I have in mind with what I'm working on.

But the best part at the conference wasn't the hackathon, or the free trip to San Francisco. The best part was reuniting with an old friend again, who also grew up in Silicon Valley, and worked for numerous startups, as well as presented at TechCrunch during its earliest days in 2008 for one of the few female led startups. My Kung Fu brother from my University days, Sheldon.

Sheldon and I go way back. He's one of those undiscovered Internet Pioneers. He wrote one of the first white papers, Do Healthcare Providers Need the Internet?, about transforming medicine with the Internet, back in 1995-1996!

Anyway, Sheldon thoroughly grilled me regarding the device, my grand vision for the concept, and with the grilling, I was able to flesh out and hammer out a real plan. That plan, is the pitch video for the monitor device, which you can see here:

And the "How It Works" part of the plan, which you can see here. Because TechCrunch didn't allow more than 1 minute for the presentation, I obviously wasn't able to present more than just the essence of the device. But with free form video that's made concise and patterned like a pitch, we had a lot more time to make something more definitive and concise. It also shows a more refined prototype in action.

And it's time for the business end of things, which means the pitch deck, the business plan, and the elevator pitch.

Woohoo! My thermopiles and gas/CO sensors have arrived! And considering I've got a lot more time than I did at the NYC Disrupt hackathon to work this one out, it should go a lot smoother. What I do need though is another microcontroller board to do some tests of the device.

But in the meantime, to stay ahead of the game, there's this article to think about.

Beware the ticking Internet of Things security time bomb

One of the problems I ran into during the hackathon was the issue of doing SSL on the Arduino. The library alone would've eaten up the entire memory bank of the chip. It also would've eaten the memory up on the Teensy LC. It's the reason why we went with Temboo as our main API interface to Twilio. But that's not ideal because you can still intercept the data before it hits Temboo as unsecured. So I'm on the hunt for an easy way to incorporate and use encryption on the device.

If anyone's got any suggestions, I'm all ears.

So, I'm finally coming off of the high of winning the Twilio sponsorship prize of the all expenses paid round trip flight to Twilio's Signal Conference out in San Francisco, and I'm now getting slammed with the sobering reality.

Yes, it's great that the stove top monitor got awarded. It's great that my $#!ts and giggles idea actually has some public interest. The publicity is great too. But you know what would be even better? Having a much more viable product out.

So, today, I recuperated some sleep, went online and started shopping for sensors and evaluating microcontroller boards. I could just go with the Teensy LC, which I'll need to get another one to make a back up prototype, and to do some science experiments with the stove with. I'm also trying to find out if the Teensy board is open source, so that we can use the electrical schema and integrate that into an overall PCB board with the sensors and Wifi. I'm also on the hunt to figure out how to program the Freescale arm chip in just straight C on the teensy.

I'm also looking at the MSP430, and the MSP432, but I'm not that familiar with programming it, unless I stick to just Energia. I did do a crap load of C a long time ago though, so I've recently been giving myself a refresher in just straight C on the MSP430. I also can't believe there isn't really a decent tutorial on the MSP430, Linux, and MSPGCC! That's going to be a side project in the future for educational resources.

The MSP430's nice because it's low power. So is the 432, but the the problem is price point. I have no idea how much chips are for the 432 should we decide to make, say, a thousand of these.

I also want to get rid of the CC3000 wifi break out board, and see if I can instead integrate the ESP8266 module, because it's smaller and cheaper. The CC3000, while it's nice, is a lot of hardware and expense. And I want to build something that's manufacturable and cheap component wise. Plus I can include the ESP8266 information as a tutorial in how to use it.

But the most important thing is I'm picking up a thermopile.

While Marcin, https://hackaday.io/marcino239, and I were hammering out the functionality of the sensor at the hackathon, this dude, John, came over to our table, and as soon as he saw what I was doing, he immediately said he had just what I was looking for. He brought over this Texas Instruments bluetooth enabled sensor cluster package that also had a really sensitive temperature sensor, far better than the clunky DHT11 we were using that was really slow, and it wasn't that great at a distance. For a proof of concept, the DHT11 worked really well.

Hey, I can't complain, I'm going to San Francisco because of it!

But John's sensor, which unfortunately was already integrated with an ipad would've set us back several hours, and it was already 3AM Sunday, so we went ahead with our bread board and phone work. We finished the code for it at around 4AM, at which point, I took a nap. At 5AM we did several more tests on the proof of concept, and added a few code modifications. At 7AM, we declared victory, and chilled out/grabbed quick naps. 9:30AM, the hackathon was over.

All during that time, I kept the thermopile in mind.

Now, winning that prize at the NYC Disrupt hackathon was great. Part of the prize also included two free tickets to the TechCrunch Disrupt conference, and each ticket sells for 2995 bucks! That's almost 6k worth of tickets! Which of course, I took full advantage of. But it was while I walked around the conference, bumped into startup peeps and investors that I realized something.

I was woefully, terribly unprepared for that incredible opportunity. Here I was, walking around at least 20 billion worth of venture capital, and I couldn't do jack freaking squat, because I didn't have a business plan, a pitch deck, and I didn't have a product. What I had was a nice proof of concept.

Well, for this upcoming Twilio Signal conference, there's no way in hell I'll be that unprepared! So I bought the sensors today, and I've already started revising the code. By the time I get out to San Fran, I'll have something that's much more impressionable, and I'll have the pitch ready.

Oh, and we got profiled by Temboo, whose API we used because, we needed SSL for text SMS!

Texting to Victory at TechCrunch Disrupt

"David was aiming to build something to give peace of mind to his elderly father, who often worries that the stove has been left on when he leaves the house."

Um, it's actually about giving back some sanity to me, my mom, and my brothers. But I'm not one to quibble.

Gotta give kudos to Temboo though. Part of the problem with a straight IOT device text sms is the requirement with Twilio to do it with encryption using SSL. But there isn't really a good, fast SSL library that will run with a tiny memory footprint on most microcontrollers, and when you go up that high in microcontroller power, you've got a very overpowered device doing a very simple task. Budget wise, that's not smart. Enter Temboo, a NYC IOT API based startup, whose rep's Claire and John were walking around the floor. And I think we're the only ones who used their API...

Anyway, they came to our rescue, handling all of our encryption. These guys are generous with their API and access.

Up this week, getting the parts in, and then heading to Fog City!

OK, now that was a surprise. I went up to the TechCrunch NYC Disrupt 2015 this weekend largely to see what a Hackathon is, and to show a bunch of software/app types what hardcore hardware hackers can do, and to meet the Hackaday folks for the first time.

And for $#its and giggles.

Mainly for $#its and giggles.

I've done something similar to a hackathon, which are the Demoscene parties way, WAY back in the day, as in the 1990's day, where a bunch of coders would get together for a weekend of demoscene coding and competition. That was graphics, music, and art, with a ton of gaming. Back then, I used to go to Montreal for NAID (1996), and I was a digital artist. Given that Wikipedia lists the first hackathons as occurring in 1999, which I would dispute heavily, given that the demoscene has had hackathons for far longer than 1999, I guess you could say I'm the hipster of hackathons.

In fact, you can see my artwork back in the day in this video. It's the first that comes up, a kung fu practitioner on the screen. I was part of a group from Boston University, Miracle.

Anyway, cut to today, I'm a hardware hacker.

I met marcino239, https://hackaday.io/marcino239, who helped me with some of the code for interfacing with the internet. Marcino239 is a great guy and very sharp on microcontrollers. He's also an expert with artificial neural networks, and after a few hours messing around with first the 8 bit Arduino, when we saw the memory was too small, we went with a teensy LC, we got the thing working.

And we ended walking away with the top Twilio prize for a round trip all expense paid trip to San Francisco for Twilio's Signal conference. And it was the only travel related prize in the contest.

WTF happened?!

Oh, and the stove top sensor got its foundations.

Here's the video of the presentation.

Stove Top Sensor for Paranoid, Stubborn Older Parents

I Had A BLAST!

I used to be a Science teacher for grades 4-8th at a place called Nature's Classroom and being on the stage and entertaining kids, teachers, and parents was a rush that I absolutely loved. Next time I do this, I'm wearing my Lucha Libre mask.

And I met Ken, https://hackaday.io/Kenp, another great hackaday guy. He took pictures of the event, which you can see here.

Disrupt 2015

Meeting Mike, Bill, Sophi, Jasmine, Amur, and the rest of the Hackaday gang was a blast too! And Kenji, https://hackaday.io/kenji, brought the hardware beat down with his amazing mobile electronics lab!

[KENJI LARSEN] SHOWS OFF THE ULTIMATE HACKING KIT

You can see some video of our midnight antics here. Yes, the moment the TechCrunch host talked smack about New Jersey (My State!, though I was born in Philly), I had to give him a proverbial crude sign.

Midnight Hacking at Disrupt NYC 2015

I also got word from @Mike Szczys that my device cleared the first hurdle in the Hackaday 2015 competition to get rewarded a PCB manufacturing prize! Next up, manufacturing the first sets of prototypes! Mainly because my Dad is now demanding I set it up for him after seeing the video.

Yep. No rest for the weary. The primary reason for this device is ever present...

I'm a sketch artist. I've spent most of my life doodling or sketching, and I always carry a sketchbook, a box of colored pencils and graphite, and a watercolor pan with brushes. Funny thing is, while I've spent most of my life sketching my main favorite subjects, which is pinup art and motorcycles - I even have a deviant art gallery here: My Gallery, I also have a thing for technical readouts and diagrams, flow charts and mind maps. So, naturally, when forming the concept designs for this product, I reach right away for my sketch book and box of colored pencils, and came up with this.

What a lot of people don't realize is that engineering is a form of technical art. In fact, the term "technology" has its root in the greek word, "techne", which means "art with practical application."

I consider the highest form of expression in the high tech space is one who's able to take technology, and creatively express it. That is art. Coming up next, the concept function flow...

A lot of times, especially if you're a tinkerer, when it comes to the beginning, we just prefer to dive in and start messing with stuff. This has its advantages, but it also has its disadvantages. If you're on a time limit, going about it this way isn't the best way to do it. Having worked as a program manager for a NASA project, and as a manager/developer/instigator of a good number of other products both technical and non technical, a lot of times it makes far more sense to start with a more formal beginning. And that beginning means outlining your objectives. For me, that means creating what's called a BFT, or a Business/Functional/Technical Requirements Document.

The Business Requirements are the answers to the question of "What need are you trying to fulfill?" For example, let's say we're designing the Smart Cat Bowl. What's the primary need for the Smart Cat Bowl to fulfill?

We want the Smart Cat Bowl to let us know that the cat is eating. Brilliant! Typically, Business Requirements are stated in plain language to show how the product is fulfilling a need. I need to know my cat is eating. (note, I don't have cats. I have dogs. But this'll work the same)

Next, the Functional Requirements answer the question "How are you going to fulfill those needs?"

Notice the numbering of the Functional Requirements gets a decimal. This helps group the functions according to a class structure. When writing out your Functional Requirements, you want to group them into general groups of functions, for example,

• When the Cat is at the bowl, the bowl sends a signal that the cat is there
• When the Cat is not at the bowl, the bowl sends a signal that the cat is not there
• The bowl device is user friendly
• The bowl device is durable to water, dust, shock, hairballs, and catpuke

I've grouped the user friendly and durable parts to a class "2", because those are mechanical requirements. User interface requirements would be their own class. You want to create groupings in accordance to both the engineering and design group that will address that particular group. For a team, this makes it a lot easier to delegate and divvy up the parts to the particular expertise of your team mates. Or if you're doing this alone, it helps you focus on just what needs to be done, one group at a time, so that a delay in one part doesn't necessarily delay the other.

Next, we have to attach arrows to the business requirements, which allows us to see how they're related.

The arrows are important because you get an overall picture of how the parts are related to each other.

Next, the Technical Requirements answer the question of "How will the technology fulfill those functions?"

This is where you get to flesh out what makes up the functional component. As an example, for 1.1) which is "when the cat is at the bowl, the bowl sends a signal that the cat is there."

So how do we fulfill that function technologically? Here's the list.

• The bowl uses a PIR sensor to sense the cat
• The bowl uses a wifi transceiver to connect to the home wifi router

You don't want to get into the specifics of exactly what technology, eg. what chip, what sensor maker, etc, to use. It's not necessary. What is necessary is specifying exactly what the core technology is supposed to do. This gives you flexibility, so if a part doesn't work out, you can sub in another part that does the job.

Once you've populated the functional technical requirements, it's time to add the arrows to understand their relationship, and where you put your priorities.

You'll notice there's a lot of arrows coming from "The bowl device is user friendly." There's a good reason for that. A product is only as good as its ease of use for its intended purpose. While the technology parts are important, human interface, user experience is much more important. And it's something engineers often get wrong. The beauty of using the BFT is you can see the emphasis on the functional requirement, and know where to focus to get it right.

Finally, you can include what are the technology specifics that answer the questions of "What chip, what algorithm, what hardware, software, etc do I need to make this technical requirement work?"

Here, you can get into the nuts and bolts of how you want to approach the technical requirements. This is particularly handy for the mechanical engineering and asthetic design portion of the product. Once you've defined your Technical Specifics, once again, connect it with arrows, like so.

Once you're done, the overall BFT diagram should look like this:

This is a clean, thought out plan for approaching your product. Now, for what I'm working on, the IOT device for my Dad, my BFT looks like this.

Coming up next week, algorithm development, and coming up with the bill of materials to build! And please do leave feedback, how to improve this, suggestions, etc. If you're a teacher, feel free to refer your students to my blog, and do let me know that you're doing so. All I ask is once they've built their stuff, if I can stop by to check it out!

Addendums: Software used is Dia. I run Linux on my systems, so it's easy to get, and I think it's been ported to all software platforms.

https://wiki.gnome.org/Apps/Dia/