Premature Optimization during Design

As I design my embedded software, I am always looking for the most efficient tools and design. We have limited resources and must therefore constrain our designs.  Or do we?

I remember struggling to get Donald Knuth's TeX typesetting system to compile and run on the big DEC2060 timesharing system back in 1984. It was a beast of an application and not written to run on anemic platforms. It was Knuth's idea to solve the typesetting problem, not write an application that would run on limited hardware.

Now, TeX (same sources pretty much) can run on your Android phone.

Back in 1986 I was trying to get Richard Stallman's Emacs to compile and run under Unix. It was a big, bloated and slow beast  (but worth it for all the power it gave me -- I was already an Emacs addict for a couple of years).

Now, I install it on every Linux/BSD laptop I use and fire it up as needed.

These systems (and others) were not designed to work on minimal hardware, but over the years hardware caught up with them.

I am not advocating that IoT devices use big bloated tools, but as far as "basestations" go... why are we constraining ourselves to RasPis and Beaglebones?

Mutter... Adventures in VOIP/messaging systems

Over the past couple of years I've been playing around with a "toy" Mumble server I developed.
Mumble, if you don't know, is a popular gamer VOIP and messaging system.  It is open sourced and has clients running on Windows, Linux, iOS (iPhone) and Android (I prefer Plumble).   It has a published spec for communication so it is relatively easy to build a minimal server.  I've built one in the past in Erlang and have recently started one in Lua(JIT).

Why would I want to implement my own Mumble server (I'm calling it Mutter) when a perfectly good one exists as part of the Mumble project?  Well, I am curious how many interesting things I can do with a compliant server without touching the client software.

Some of my experiments involve creating additional levels of authentication (e.g. a query response from a server bot, additional detection of client OS/hardware stuff, etc) as well as the potential to bridge to other VOIP or messaging systems.

Other things I am curious about playing with is "adhoc" conference calls that could spawn quickly and privately in the cloud. 

Right now it is mostly for fun. I've got basic messaging and TCP voice channels working. I am not interested in building a full blown Mumble server (that already exists!) but curious as to what can be done minimally....

S.A.F.E: An IoT compatible Manifesto

My home monitoring projects/products follow a manifesto I call SAFE.  SAFE is an acronym for Set And Forget Engineered.  It follows the basic tenant that home monitoring systems should be reliable and not require lots of care and attention.  You set it and then forget it.

This manifesto doesn't exclude IoT (Internet of Things) devices, but it has some rules. Let's consider the class of devices to include: Flood monitors, Stove usage monitors, Motion detectors and Entry/Exit monitors.

1. If you don't run off of AC, your nominal battery life should be 5 years.  Assume 2 years of worst case (power consumption-wise) performance.   Do you check/change your smoke alarm batteries religiously every year?  Maybe not.  If you can't guarantee 2 years of performance (and you are a critical monitor) then you should run off of house current (AC).
2. If you need to run when power is loss, then you should have backup batteries that last at least a couple of days. This is particularly important for Flood monitors, etc.
3. If you can't automatically recover from a power failure, use backup batteries to keep the system running or use persistent memory to snapshot states.
4. Your device should have some "local" alert capability and not rely 100% on the Internet for notification.  If I am in the house, there should be an audible alarm and not reliance on my smart phone being notified via the Internet.
5. If Internet notification is critical, don't trust Wi-Fi.  Let's use an analogy:  Your car's critical systems (engines, steering, braking, locks, etc) should, by design, run on a separate network than your Entertainment system (radio, etc).  Your IoT device probably should follow that same rule. Wi-Fi can get congested, it can have password changes, it is a common target for attack.  But what can you use instead of Wi-Fi? Consider ZigBee, XBee or other more robust protocol (no, not Bluetooth!) as the delivery transport to the home router. All home routers still feature Ethernet ports so your transport receiver can be plugged in there. You still rely on the monitor but you are not affected by all the issues with Wi-Fi.  Now, of course, you should consider encryption and authentication too when using a non-Wi-Fi protocol...
6. Don't design for over the air software/firmware updates. This is a HUGE security hole and although you may have thoroughly thought it through -- you haven't.  Get your software as  correct as possible and consider doing updates through a computer or smartphone "directly" and "physically".  Things that can be controlled through the Internet will be a nice fat target for people who want to control your stuff through the Internet.  Don't advertise your house as hackable!
7. No SD cards. Nope. SD cards are not designed for reliability or longevity. Use persistent memory that has at least a 10 year retention.
8. No rechargeable batteries.  How long do you really get on a L-ion/poly?  Two years? Five years?
9. Avoid LCD/button interfaces as much as possible. What is this, the 1990s?  If you need a way to silence an alarm or (temporarily) disable a sensor use touch or tap and a simple indicator. 
10. No disabling or critical manipulation through the Internet.  Sorry, see #6.
11. Know thy hardware. Don't just choose a Raspberry Pi or Arduino unless you know exactly how each critical component is rated (e.g. environmentals, write duration, etc).
12. Know thy software. Don't just load up a Linux and go. Are there processes running you don't understand? Update software maybe? 

I try and to design to these tenets. I am surprised how many commercial IoT devices seem to ignore them.