Design by Teardown: What you will find inside of my Panoptes home monitor basestation

First... It is about time I named this monitoring system.  I'm code naming it "Panoptes".

I'm struggling a bit with the power consumption on my wireless sensors (previously mentioned here).

I've chosen an C8051F912 as the MCU (extra 128 bytes needed for my OTA encryption scheme), but I can't seem to get the sleep mode down below 20uA. (That doesn't sound like a lot of power consumption, but it adds up when considering that I want the batteries to last years.)

So, I am taking a break from low power design to focus a bit on my base station. (For those coming into this blog entry cold, I am designing a Internet-ready home monitoring system with a focus on keeping track of independent elderly people, specifically those who are candidates for nursing homes but aren't quite ready for that transition yet.)

I've decided to approach the base station design from a post-implementation perspective: What would someone find if they did a teardown on my device?

Why come from this perspective?  I would hope that what a savvy engineer would find the implementation sound and even respectable. So, why not base my design decisions on this point of view?

Now, I am not just talking about a hardware teardown, but a software one too. But, I won't get too wrapped up on how my code looks or how it is structured.  I am more interested in interoperability: How does the software interface with the outside world -- in particular, the end user and the Internet.

Let me preface this with one of my primary design goals: Set and Forget. 

This is not a system to be played with or to constantly probe from a web browser.  The typical customer is a caretaker or adult child of an elderly person.  This is about applying modern IoT technology to an old problem.  But, this is not a Nest. This is about the kind of IoT (Internet of Things) that operates discreetly in the background of your life -- you just want to know when interesting things happen, otherwise it isn't on your daily radar.

I have said before that even the base station can host sensors, so for this particular teardown, we will look at a single use: Someone buys the basestation plus a water flood sensor to monitor their laundry room.  This example isn't solely "elderly" oriented but does represent the case where someone would want a true "set and forget" sensor.  (I won't cover "wireless sensor nodes" here, since while necessary, they are bound to a lot more hassle that I'll address later -- things like RF interference/jamming, etc.)

I am trying to bridge the world of industrial strength monitoring with the IoT.  I expect the sensors to be "integrated" with the house. You will want to install them properly (mount them) and permanently. These are devices that should last for years.  The mantra is that they "must work".

The water flood sensor is a good example of a "must work" sensor.

So, this is a long one. Feel free to jump ship here, otherwise, grab a cup of coffee, sit back and ... here we go:

Contents

The water flood sensor is a pair of gold plated probes on a 2x4" plastic plate.  The plate can either rest on the floor, be glued or attached to a baseboard with screws. Two thin wires connect it to the sensor node (in this case the base station).  The base station can be mounted on the wall. It is about the size of a desk of cards. On the side are 6 screw terminals (for 4 sensors plus +DC and ground.  The water flood sensor attaches to two one of the sensor screws and ground.  The user is expected to use the full length of wires or to trim and strip them to a desired length.  You can connects up to 4 water flood sensors if you want to place them strategically in a room (e.g. under the sink/tub, next to the water heater, etc).

(First critical question: Why screw terminals instead of modular connectors?  Answer: This allows the user flexibility in where they mount the base station. It can be several feet away from the sensor. A module jack would fix the length of the wire.  I am assuming either a professional installer or someone comfortable enough to run wires.)

The base station hosts 2 AA batteries for power failure backup (which should run a couple of weeks before needing to be replaced).  Lithium or alkaline are recommended for maximum shelf life.

The base station is normally plugged in to an AC outlet (via a standard USB 5VDC power supply). Since the station uses Wi-Fi, it wouldn't run very long on batteries.

Configuration

The USB port is also used for "configuring" the base station. Once plugged in, it shows up a disk drive.

Then you go to the product website and enter data into a form.
You can associate a screw with a type of sensor (in this case a water flood sensor). You must also enter the SSID and password for your wi-fi router.  Additionally, for notification, you must provide an email address.  None of this data is retained by the website and is all done over https.

Once entered, this data is downloaded as a file. You must save the file (or drag it) to the attached base station.  The LED will blink rapidly and if all goes well it will remain lit.  A slow blink indicates an error.

Once installed and turned on, the base station contacts the wi-fi router and you are sent a "startup successful" email.

Operation

The base station will send you once per week "heartbeat" email to indicate that all is well. If you want check "on demand" you can send it email and it will respond with status.

If water is detected, you are sent email.

That's it. Set and forget.

Hardware Teardown

There are 4 phillips head screws holding the unit together. The case is UL94-5VA flame rated.  Two flanged holes support mounting the enclosure to the wall.  When mounted, the battery compartment flush against the wall. This is a light form of security to prevent someone from taking the batteries out.

The screw terminals are side mounted.  There is a small recessed reset button on the bottom of the enclosure.

Inside there is a small circuit board hosting the three main components: A TI C3000 Wi-fi module, a Nordic nRF24L01P low power RF transceiver (for wireless sensor nodes) and a C8051F381 USB MCU. The Wi-Fi modules is tethered to an antenna that traverses the inside edge of the enclosure.  The screw terminals are connected via  ESD protection diodes to the MCU.

(But, why an 8-bit MCU?  Why not an ARM Cortex? The C8051F381 is essentially an SoC. There are very few outside components needed. Panoptes uses the internal precision oscillator, so there isn't even an external crystal.  There is a built in 5VDC-in regulator and USB support. And, for what the system does, an 8-bit is adequate. Plus, the fewer the parts, the simpler the design.)

There is a small piezo buzzer mounted over a small hole piercing the front of the enclosure. A small red LED next to it pulses every few seconds. This is to indicate that the unit is on and connected. If it cannot connect to the wi-fi router or cannot reach the Internet, the LED blinks rapidly.

Measuring power consumption of the unit shows that it consumes around 105mA when idle (not sending a notification) and peaks at about 250mA, briefly,when sending notification. Most of this current is due to the Wi-Fi module.  The 105mA suggests that the base station maintains a connection to the Internet at all times.

Pouring water upon the floor (thereby triggering the sensor) cause the unit to beep loudly and send a notification email.  After 10 minutes the beeping stops and the unit awaits to be reset. It blinks rapidly red during this time.  You can cease the alarm by pressing (and holding for 3 seconds), the reset button on the bottom of the enclosure.

If the AC power is pulled from the base station (e.g. a power outage), the unit falls back to the battery, sends an alert email, powers down wi-fi and beeps for 5 seconds.  The base station is still fully functional, but is expected to only last a few days without AC power.

The current measures steady at around 500uA at this point.  Any water sensing event will cause both the beeping alarm and an attempt to send an email notice (in case the wi-fi router itself is battery backed).  Every 2 minutes the station beeps to remind anyone near by that the unit is battery powered. 

Pressing and holding reset at this point will cease the beeping but the alert capability remains.

Internet Connectivity

The base station is connected 24x7 to a server running in the "cloud". This connection is via TLS/SSL and it is the cloud host that sends notification emails.  Why not send email directly? The cloud server ensures mail delivery (caching and doing multiple delivery attempts as needed). Plus, for sensors that need correlation outside of simple alerts, the cloud server does all of the logic and interfacing. 

Email is used as the primary notification (and status query) mechanism due to its ubiquitousness. Email is everywhere and doesn't require any special software to be loaded on your PC or smartphone.

No software updates are pushed to the device. Nor can the device be remotely controlled. It is a monitoring sensor. This IoT base station is one way.

In conclusion

Panoptes is designed to be a part of your house. It isn't sexy, but it is indeed a player in the IoT. Outside of 802.11b/g and TLS/SSL , it is bound to no particular Internet standard that may go away in the near future.  You can use it with low power RF based sensors or simply standalone with up to 4 wired sensors.

Despite the low BOM, Panoptes is a high quality product designed to last.  At $100 per base station, $10 - $20 per wireless sensor,  and $2 per month cloud based subscription, it is a worthy investment considering the repair costs of house flooding.

The only thing missing seems to be Zigbee support. But, until low cost wireless sensors are offered in the Zigbee space, the nRF24L01P is adequate.

Thanks for reading!

EDIT: Looking seriously into the Kinetis K20 again as the base station MCU. I could use a little extra help with the Internet protocol side of things and the 8-bitter suffers there.

EDIT2: The TI CC3000 Wi-Fi module has an OTA configuration scheme called SmartLink. This rids me of the need for USB support as I can  configure the AP and password over the air.  I still need to figure out how to send email address and other config stuff, but I should be able to do that over the air too.

IoT: Real "servers" (PCs) are in your future (as base stations)

While Nest and others using embedded ARMs as base stations for your home "Internet of Things (IoT)", I see a real server in the future. There is only so much you can do with these embedded (usually ARM based) servers when you don't have a disk or memory management.  In particular, with the greater demand for these base stations to talk "native" Internet/Cloud (e.g. more heavy protocols like AMQP, XMPP, etc), it starts to tax an unadorned ARM SoC.

While a "PC" sounds like overkill, I am expecting to see more and more Intel Atom and ARM based, fully solid state, base stations with all the usual bells and whistles we are used to getting with a PC.
What bells and whistles?  Memory protection/management, robust storage, system busses, rich peripheral support, etc.

Let's call them SBCs (Single Board Computers) , which is what they really are.  Until now, SBCs were firmly in the domain of the industrial embedded market.  You don't mess around with unreliable consumer tech like SD cards and low end Chinese market chips (e.g. All Winner, etc) when you are building a security base station for an office building or other 24x7 "install and forget" monitor and control systems.

I've played with the wonderful Olimex ARM boards (like the OLinuXino LIME), but they are "new". There are hardware glitches, limited driver support (I can't just buy a wi-fi  board and expect it to work) and I don't feel that the Linux distribution is fully baked yet. Plus, I have to cross compile (from my Intel based laptop) and I run into all the "this isn't ported yet" problems that come with cross compilation.

With the coming of the Minnow Board MAX, Intel based SBCs are getting cheap enough (and low power enough -- No fan!) to become serious alternatives to the crop of low end ARMs.

What is wrong with the current crop of Cortex A based embedded systems?  The biggest problem is reliability (or at least the perception of) and OS support.  Sure there are Linux based distributions but are they as reliable and mature as their Intel based cousins?  I'm talking about real embedded distributions. I don't need or want X windows with a bunch of media apps.  But, are Intel SBC based Linux distributions any better?  Maybe. But that isn't what I am recommending.

Ubuntu/Debian/Fedora/etc server editions are (perhaps) ideal here.  They, for the most part, are already rock solid (when you have thousands of servers running 24x7 in a data center, you might as well say the OS is "embedded" grade since you can't practically login and deal with OS "issues").

I can see running Ubuntu 14.04 server (stripped down a bit) on a Minnow Board.

Now, the target market for the Minnow Board is for those who want to play with SPI, GPIO, I2C, etc -- they make a point of saying it is an "open hardware embedded platform" and not a PC. But, it seems to have specs to the contrary:  64 bit Atom, 1GB RAM, USB,  SATA2 support, ethernet, etc.

That sounds like a PC to me.  And, if I can run Ubuntu (or Debian) Server on it, it fits my IoT base station needs.   These days, most peripherals I interface to (including my own homebrew ones) can be accessed via UART (via a USB adapter) or native USB.  Do I really need to put my Bluetooth or GPS receiver on SPI these days?  (IMHO, Linux is pretty clumsy when accessing bit banged devices that don't already have kernel support.)

And, at $100, it certainly competes with the current crop of ARM boards.
Then again, if you can accept a Fan in your base station, it is hard to beat a repurposed ASUS Chromebox ($149) which comes with 2GB RAM and a 16GB SSD.

Building the first (of many) wireless sensor prototype...

I've ordered a bunch of parts, so now I am committed to start building prototypes...

I've been doing X10 (RF sensors) and Linux on an SFF/SBC Intel-based computer (base station) as the prototype for my elderly monitoring system.  Stuff has been running for almost a year now but I am not satisfied with two aspects of this system:

1. X10. Ugh. Ultimately a dead end.
2. Intel-based computer.  Too big, too much. Overkill.

So, once again I am looking into a completely home brew solution.

First up: Wireless sensors.

I am throwing together prototypes centered around the ridiculously cheap NRF24L01+ (go ahead, google it and look at the ebay bulk prices -- they are between $1-2 each in lots of 10).  I am pairing these with the ridiculously low power ($1 per unit) C8051F986 (Silabs 8051 w/ 4K flash & 512 bytes RAM).  All these sensor nodes have to do is read some switches (e.g. motion sensors, doors, etc) and transmit a byte or two to the base station. I am coding it using MyForth (which is still my favorite Forth variant).

The BOM for a single wireless sensor node (sans sensors) is about $8 (including generic enclosure).  Add a PIR motion sensor for $17 (low current is expensive!), a magnetic door switch/sensor ($5) and maybe a water level detector (oh, and temperature comes for free with the C8051F986!) and you've got a wireless multi-sensor node for $30.  That's a bargain. I am currently using (screw) terminal blocks so you can hook up short runs of sensors (e.g. monitor the front door AND front hallway from one sensor node).

Next up: Base station

The base station will come in 3 variations:

1. Wi-Fi
2. Ethernet
3. GSM/SMS

I am tackling the Wi-Fi variant first.  I am using a TI CC3000 eval board ($35 from Digikey).

The NRF24L01+ boards in my possession uses a trace antenna, so I am not sure if I'll get the range I need.  For the base station, I ordered a slightly costlier variant that supports an SMA connector.

I am still waffling on the brains for the base station.  Cortex M4 sounds like a no-brainer. In particular, I am fond (and familiar) with the Kinetis K20 series (via the $20 Freedom board).

But, I am NOT happy with the M4 development eco-system.  You either drop a lot of cash (>$1000) or use not-quite-baked free tools.  Yes, GCC has wonderful support for the Cortex processors, but getting down to the vendor specifics requires a lot of work (unless you opt for the IDEs which not only do all the work for you but manages to "hide" most of the hardware from you... I don't want this).  

Kinetis has a free GCC/Eclipse based IDE.  It takes up 1GB on disk, runs slow and isn't fully cooked (it is beta until later this summer). 

And, oh, don't get me started on the debuggers (e.g. OpenSDA, EzPort, OpenBDM, etc). Wow. The chips are amazingly cheap, but the support around the chip is going to cost you (if you don't want to be spoon fed:  mbed, Kinetis IDE, etc -- I am looking at you).

I've been using MPE Forth at my day job when I do Cortex M4 work.  It has worked nicely with the K20 Freedom board.  But, I can't afford MPE Forth right now for my CFT projects.

So, waffle, waffle, waffle.  Last night I threw together a quick base station prototype board (because I need *something* to test the sensor's NRF24L01+ against).  The brains for the prototype is a C8051F930 I had in my junk box.  It has 64KB flash and 4KB RAM. This is quite beefy for an 8051. It also has ridiculously low power needs.

Honestly, it has all the horse power and space I need to do the base station task. Plus I get code sharing with the sensor nodes.  But, an 8051 as the brains?  Shouldn't I go with something more capable?

Well, here is an interesting observation:  My prototypes are already rich with 8051s.  The NRF24L01+ has an 8051 as it's core. The TI CC3000 (Wi-Fi module) does too.  Do I need more horse power than a modern 8051 (Silabs  8051 based CIP-51 cores executes 70% of instructions in 1 or 2 clock cycles)  to just control these two modules and do a little bit of logic?

Industrial Product: Forth + Bare Metal + Cortex M vs C++ Linux + Cortex A

File this is in the category of "spending way too much time thinking rather than doing"...

This is a long post about building an "Industrial Strength" product.

I sit poised between rebooting my "Home Alone" Elderly monitor using a micro-controller  or a microcomputer based solution.

It isn't a very sophisticated setup: A few PIR motion sensors, a water detector, a magnetic switch for door open/close detection and a means of notifying me when something interesting happens (e.g. mother-in-law wanders out of the house when we are not at home, is up in the middle of the night, left the water running, etc).  The notification method is still "up in the air": Do I uses a GSM modem to send SMS to my smartphone or do I maintain an Internet connection and send it email?

I have previously implemented a prototype in LuaJIT and ran it on a small form factor PC (using off the shelf X10 RF sensors).  It sent the data to a cloud server and notified me of events via email. You can read about it in my other blog: http://eldermonitor.blogspot.com/.  This prototype is too heavy (small form factor PC + cloud services).

So, now, for the "make it lighter" reboot, I've been looking at the very interesting A10-OLinuXino-LIME (something of a more industrial quality Raspberry-Pi).  Industrial is the enticing bit. I want this thing to work. I don't want to design my own board (yet). I would like the prototype to work and work "for a long time".  This isn't to say that the Pi wouldn't, but I've had very good experiences with Olimex boards when doing embedded stuff at my day job.

But, here is the thing: Software.

Debian is stable (and used quite a bit in the embedded and server based arena), but is this LinuXino Debian build solid?  I don't know.  I do know that this stuff is still mainly "enthusiast" supported.  For this project, I am not an "enthusiast". It must work.

(An aside: If it "must work", how can I rely on X10 RF stuff?  I've run the sensors for over a year now in my house and they are still going strong.  I haven't had to change batteries either. They aren't sophisticated, but they seem to work for the long haul -- at least for now.)

So, here I am, writing modern C++11 code on my 64 bit i5 dual core laptop and planning to recompile (port?) it to the 32-bit ARM (Cortex A8) ... and thinking... will this thing work reliably?

With the C++ I am thinking about abstractions and algorithms.  Am I making something inherently simple more complex?

Do I really want a full blown Linux here? Will it run for a year without fail (or crash)?

So, I sit here at my workbench and I am comparing the A10-OLinuXino-LIME board (argh, what a horrible name) and the Freescale FRDM-K20D50M (Cortex M4) board and wonder if I am not going light enough.  Getting the USB based X10 CM19a receiver to work on the Cortex M4 is not trivial.  (I may punt and go for hardwired sensors for the time being). And, C++ on the Cortex M4 means either fighting g++  (ugh, the linker config) or paying >$1000 for a serious compiler.

I've got and old (still functional) MPE Forth Stamp Compiler working with the FRDM board. It isn't free but it is solid.  Solid is what matters here.

I have visions of a simple device that once configured (and installed) hums along doing its job for months (...years!) without concern for whether it gets stuck in a reboot (e.g. Linux runs out of space due to a logging issue, SD card corruption, etc) or whether my C++ has some subtle memory issue (e.g. modern C++11 looks down upon "new" and "delete" but can still run out of space by auto allocating objects on the stack).

Forth is, well, Forth. On bare metal, I can completely *grok* my development environment.  Porting MPE Forth to the FRDM board was a pain, but now I *understand* the FRDM board.

What am I trading here?  A modern C++/Linux design vs something that I know will work (and how it works).

I'm an old Unix hand (been doing it since the mid-1980s), but I don't know if I am comfortable with a home monitor running a community supported port of Debian. Too many unknowns?

Personal UV Sensor reboot

Back in 2011 one of my CFT projects was to develop a personal UV sensor for those who are a high risk for skin cancer.  Due to the limited availability of tuned UV sensors (i.e. a reliable source for UV Index rating values), I had to abandon the project. I produced one prototype, as outlined here: http://toddbot.blogspot.com/2011/08/uv-index-monitor-prototype-1.html but had to put further prototypes on hold due to  sensor procurement issues.

Well, apparently there is a rumor that the forthcoming Apple iWatch will include a UV sensor ( http://www.macrumors.com/2014/04/08/iwatch-uv-light-exposure-sensor/).  This is great if you have an iPhone, lots of money and want a new watch, but this isn't my target.

But, the new UV chip they are using, fits my budget: http://www.silabs.com/Support%20Documents/TechnicalDocs/Si1132.pdf.

I want something small (and cheap) enough that you could clip it to a hat, a UV windbreaker, shirt or blouse. Oh, and it should be water resistant (wear it on the beach or by the side of the pool) or even water proof (go swimming with it on).  It should also allow you to set a timer (in hour increments) to remind you (via beeping) to apply more suntan lotion.

The only UI would be a capacitive touch sensor. Press to see (or hear through beeps) the current UV index. Press to set timer.  LEDs (matching UV Index official colors) and/or small buzzer would be the feedback mechanism.  It should cost under $20 and the battery should last a few years (at least 5) under moderate UI usage.

Why do this?  Well, why is every (new to market) useful sensor device required to work with RF and/or interface with your phone?  Why can't tech just "be there" when you need it, rather than be "gadgets" that work with other "gadgets".

Heck, give me a 10 year battery life and I'd say you just sew the thing into clothing.

Okay, I've said way too much.  Let's just say that I am working on it.... stay tuned.

Teaching Forth Programming to kids... is really dangerous...

Teaching Forth Programming to kids is irresponsible and may hinder their progression into the professional programming industry.

So, let's do it.

One rather curious thing I've noticed about aesthetic satisfaction is that our pleasure is significantly enhanced when we accomplish something with limited tools.   - Donald Knuth, Computer Programming as an Art 

Forth doesn't have a lot of modern facilities, but that forces you to figure them out yourself.  Better yet, Forth encourages that you solve the problem at hand (rather than build elaborate frameworks).

I've been called out, in this blog somewhere, for promoting archaic old principles that don't apply to modern development.  But, I don't actually want to force people to learn this stuff. Find your tool and if it helps you do amazing things, stick with it.  

I've been programming in Forth since 1984.  I've learned a dozen languages since.  Forth is still the one that focuses my attention on problem solving better than any other.

Why am I writing this now?  I'm a bit late, but I just discovered this: Gforth for Google Chrome.

It's a toy right now (apparently no persistent file I/O), but I want it to be real.  I want to fire this up in a classroom full of kids and get them hacking.  I want them to build their own abstractions. I want them to see what middleware really is (a bunch of layered restrictions with the goal of making things more structured and easy, while in reality making you conform to things they want to keep hidden -- okay a rant for another day).

Sure, underneath Gforth for Google Chrome there are layers upon layers.  But there is a lesson there too: Its all about simulation.  It's Turing machines all the way down.

Statically Typed Languages like C++ and Haskell are good for lazy programmers (like me)

I've seen my errors in production code. I'm doing a forensic analysis of some "embedded" software I shipped to a customer.  By embedded I mean there is no UI and it is supposed to run unsupervised 24x7.

Server (Cloud) software often meet this criteria, but sometimes we cheat and log in (to see how things are going) or restart the OS when things aren't quite right.

But, that's not quite embedded. By embedded I mean "It has to run without me or the user intervening." and "There is no such thing as rebooting to fix a problem."

Now, I love developing code in Lua, so this isn't a Lua criticism, but when I review my daemon logs and see that the process died because I was trying to add a number to a "nil" value, I cringe.

On this same system I have a Haskell process also running.  The only time I saw it had died was when I didn't handlebeing fed bad data from a corrupt database.  Not exactly the same class of bug...

The Lua code problem could have been caught with unit tests or code review (maybe), but I am sort of a lazy programmer.  I can fall back on lazy habits such as "this is so obvious it can't be wrong".

Haskell doesn't let me do this.  It won't let me go on tossing untyped variables here and there . It won't let me assume that I never pass a string as a number (or vice versa).  It forces me to be precise.

Compiling modern C++ (C++11) with warnings on (in clang++ or g++) is similar.

I hate to say this, but after continually abandoning C++ (in cycles: 1992, 1997, 2002, etc), I am back again and I like what I see in C++11.

I'm writing deliverable code at work using C++11 and I just tried my hand at using it, *instead* of a scripting language, to do some configuration file handling.  C++11 for scripting?  Yes. And it seems to work.  Not a pointer in sight. (Actually that would be the only sane way to do this in C++: rely on RAII.)

All that being said, and especially to any potential employer who may be reading this: I am not really a lazy programmer.

The IDE called Forth, or.. Forth I wish I knew how to quit you.

I've been playing with OpenFirmware. Yep, booting it off of a thumb drive (via Grub2). It takes less than a second to boot on a "fast" laptop up to the Forth "ok" prompt.  At that point, I can start playing around with low level hardware.  Open Firmware went so far as to provide a "GNU readline" like capability where I can use Emacs-like command line editing and completion of words.

But, wait, there is no command manual!  What does this word do?  Enter "see" and the word you are interested in and view disassembled source code.

People (still) underestimate the innovations built into a "classic" Forth.   Gforth still has some classic capability built in.

Here is what I had with Forth during the 1980s (on Commodore 64 and then Atari ST):

1. Full screen block editor.
2. "See" or equivalent for looking at source.
3. The ability to ask the block editor to locate the "real" source and let me edit it (i.e. Tags).
4. The ability to play around with graphics and other hardware facilities.
5. Very fast start up (or restart for when I crash the machine).

This was the basic Forth IDE.

I'm a long time Emacs user (25+ years)  and I still not at that same IDE productivity level I was with Forth back in the day.

Smalltalk (in particular Squeak) has been the only other things that has come as close (for me).

I know that machines are bigger and software is a lot more complex these days, but why can't I have that same feeling of "being one" with the machine?

Here is what I want:  I want to load up an interesting library (e.g. libpcap, OpenCV, etc) into a Forth (e.g. Gforth) and explore.  I want to play.  Lua, Perl and Python can get me half way there (i.e. bindings), but I still have to grapple with a REPL that doesn't seamlessly integrate with the editor.  

Yes, yes I know you can bend Vim or Emacs to do these things, but the resulting IDE isn't as natural (IMHO). You are still piecing together a generic editor, a command line (linux shell) and a programming language. (For example, how do you list a directory in the chosen language? Oh, you use the shell or editor? Are the results first class elements for the language?). 

Some would say that Visual Studio is a great example of a seamless IDE, but it is still working with a language that isn't naturally "interactive".

This is why I still hang onto Forth. It isn't about Forth building better apps. I don't care what an app is built in.   It isn't about the destination, its all about the journey.

Todd's 1 question test for all new "advanced" dynamic scripting/programming languages.

Whenever a new language comes out I have a simple test to see if it is worth looking at.  I came up with this test back in the 1990s after being frustrated by the state of "advanced programming languages".

In the 1980s, as a lowly FORTH programmer, twiddling 8-bit bytes, I was blown away with my first experience with Lisp. It was on a DEC2060 (running TOPS-20) and was called "Standard Lisp".

As a student, back in 1984, I coded up a small lisp function to compute the factorial of 120.

The terminal presented me with:

6689502913449127057588118054090372586752746333138029810295671352301633557244962989366874165271984981308157637893214090552534408589408121859898481114389650005964960521256960000000000000000000000000000

My mind was sufficiently blown.

Of course, the largest factorial computed by a programming language where the number/integer type is matched to the machine word size is much smaller.  I had already programmed in Pascal, FORTH, a bit of C and BASIC.  But, this was the first language implementation I had seen that wasn't bound by that machine word limitation.

(I quickly followed that exercise by coding for the factorial of increasing numbers until, by the time I was in the hundreds of thousands, the terminal responded with a message saying that it was taking too many resources and that the process was being "spooled" -- whatever that meant.  I went home and the next morning I was greeted with an email from the sysadmin requesting that I come get a "print job" from the ops center.  I rang the ops center door buzzer, the admin came to the door and asked what I wanted. I told him him who I was and he then frowned, told me to wait and closed the door. A few minutes later he showed up with a hand truck loaded with a big box of green bar printer paper.  Apparently, "spooled" meant the result was being submitted as a print job).

A couple of years later and I discovered that Smalltalk too had this "big num" (or arbitrary precision) feature.  Why wouldn't every language have that? (Yeah, I know... performance...but, still...)

Now, when I am presented with a programming language that is supposed to be the "next step",  I look to see if it supports bignum.  Now, when I say support, I don't mean surrounding the number by quotes and submitting it to a bignum library. That's cheating. I want to say something like:

X=6689502913449127057588118054090372586752746333138029810295671352301633557244962989366874165271984981308157637893214090552534408589408121859898481114389650005964960521256960000000000000000000000000000  / 19;

I don't want to type it as a string. That's saying that there is something "special" or "hard" about large numbers.  Why, in 2014, should I be concerned about whether a number fits into 32 or 64 bits (or in the case of Lua and Javascript: a 52 bit mantissa)?  I want tnative/natural support.

So, what other programming languages pass this bignum test?

• Erlang does. 
• Haskell does... sort of... got to choose the right type.
• Perl does (and has for a while.. just type "use bigum;"  and all following numbers are not bound by machine word size.

Now, don't get me going about native/natural support for rational types.

/todd

Perl is 26 years old?

I just read on Hacker's News that Perl turns 26 years old today.  My oldest piece of open source software is written in Perl. AFT.  AFT was coded in Perl 5 back in 1996 (which makes it over 17 years old).

I originally wrote AFT in awk (sometime during the early/mid 1990s) . I ported it to Perl by using the awk to perl translator (a2p) as a starting point.

Every once in a while I revisit AFT to see if there are any new tricks to add or just to clean up the code and make it a bit more Modern Perl.  AFT is still in the Ubuntu software repository, so you can install it under Ubuntu by simply doing   sudo apt-get install aft.

I'm still using Perl. I am doing some funky stuff with the AWS cloud (EC2 instances) and find Lincoln D. Stein's VM::EC2 package fits my needs.  Perl is still great for replacing nasty bash/sh scripts (although some would say I am replacing the nastiness of  bash with nastiness of Perl).

I'm not much of a CPAN user, but those who know me understand that I am very selective of libraries and frameworks. I prefer to avoid layering and loading lots of dependencies. What I find attractive about Perl is how much the basic distribution can get accomplished  (e.g. I don't have to resort to libraries so quickly as when I program in Lua).

I'm particularly interested in investigating Mojolicious for use in my elderly monitoring project.  I use LuaJIT primarily on the base station (with a bit of Erlang).  The cloud side is currently a fair amount of Perl.  But aren't there better languages to do cloud/web development?  Isn't Perl old hat?

For those folk who think that Perl is old hat and doesn't have a place in the modern Web, do you use DuckDuckGo?  It was developed primarily in Perl....

Power Considerations for an HVAC Thermostat (10 years off a couple of AA batteries?)

Hear a tick coming from your thermostat every time it turns on the heat or AC? Well, assuming you have an electronic/digital thermostat, you are hearing a latching relay.

Latching relays are wonderful power miserly switches. Unlike a solid state relay, which requires control current (anywhere typically between .25mA and 20mA depending on what you choose), a latching (mechanical) relay will latch (hence it's name) when pulsed.  A short burst of 100mA or so and you are done.  If your thermostat is switching the HVAC once an hour per day (which is pretty excessive), then you are still using a lot less power than a solid state relay.  Another potential problem with solid state relays is heat. They generate heat. They can overheat and if you don't choose and place your components wisely, they can affect the temperature sensor.

With latching relays,  your modern latching thermostat is not consuming that much energy.

Interestingly, I believe that the NEST uses solid state relays.

A quick google shows that some NEST customers are having battery issues. Here is an interesting one:

http://support.nest.com/article/A-low-battery-level-will-cause-Nest-to-disconnect-from-the-Internet .

This is the kind of issue I want to avoid.  The two household gadgets that I don't want to think about (battery) power problems are my smoke detectors and my thermostat. I'll check once a year, but beyond that...

Here is a target: Ignore UI and wireless for a moment. Once a temperature schedule has been set, can you design a thermostat that will run for 10 years off of a couple of Lithium AA batteries?  That is my starting point.

So, as boring as "Thermostat design" sounds, it poses an interesting power problem.  Add sophisticated 'internet-of-things' functionality and now you have two problems.

An Alternative Take on Thermostats

For most thermostats (including NEST), there seems to be a power/location problem.   At best you have 24VAC control lines you can parasitically suck for power or (worse case) you have some AA batteries that you hope will last a couple of years.  With batteries you start to seriously limit what your thermostat can do (a reminder htat your thermostat is NOT a general purpose computer).  With parasitic sucking off the control lines you start playing games with how to ensure that you always have enough power (OMG,  HVAC off for maintenance or power outage and what should the thermostat do?).

So okay, we've got a power management problem.

A question:

Why is your thermostat's primary User Interface (UI) mounted to a wall (and often in a place not where you are comfortably located)?

The location of your thermostat probably has a lot to do with the "best" place to measure room temperature (out of the sun) and where you can run HVAC wires.  There are other factors, but it doesn't matter.  I have to get up and go there to read or adjust the temperature. (Of course, with NEST and other networked thermostats you can change temperature from almost anywhere).

A proposal:

Don't put the UI into the thermostat.

What?  But where do we put it?  Surely not rely on the smartphone, right?  Yes. But consider this:

The thermostat will now consist of a small discrete box (hide it behind a picture frame or paint it to blend in) with a temperature sensor (maybe), the required solid state relays to control the HVAC, a couple of AA (or AAA) batteries, and an small RF transceiver (433MHz if you desire).

Pick a convenient location (or two) and install the UI there (and a temperature sensor too). It can be on the wall, on the kitchen counter, maybe a shelf, etc.  The only requirement is that you have AC power (see where I am headed?).

Now, let's rename this UI a "control center". This control center (still very small) can not only host the UI but can also support Bluetooth and/or Wi-Fi, so you can use your phone to control the HVAC from your bed or couch.

If we do the RF correctly it can be safe (validated/encrypted) and reliable.  Because the control center is plugged into AC, we don't have power management issues. The thermostat itself is running off of batteries or even parasitic power.  We still have some power mgmt issues, but we can duty cycle the RF to reduce the overall power consumption. (A thermostat's control loop is *never* under immediate control of your thermostat's UI -- you "advise" the control loop what to do, so a couple of second lag is okay).

Now, with this setup we can put a lot of sophistication into the control center. It can be a (shudder) computer and suddenly our thermostat can become something much more interesting...

Thoughts of a Haskell (or Erlang or Lua) powered thermostat starts to become more of a possibility.

/todd

A Better Thermostat (or is the Nest the best we can do)?

I've been reading about the Nest and I am convincing myself that it is too gadget-y.
I'm thinking about my household and the usual elder market that I am currently designing stuff for.

Do I really need my thermostat to be Internet enabled? Do I really need to become a honeypot for Black Hats?  Do I really want my thermostat to have software "updates"?  Also, it is yet another device to be managed whenever I swap out routers or change wi-fi passwords.

However, I do think that we can do a lot better than the HVAC's perception of what a digital thermostat is.   Honeywell Prestige 2.0 and Ecobee Smart are the current competitors for the Nest. But they seem to think that we all want bling in our thermostat interfaces. Lots of color, lots of funky icons -- yes! Just a slide of a finger.  Here is where I think the Nest got something right. Grandma can just turn a dial to get the desired temperature. No capacitive touch screen (what about those with crippling arthritis?) and no busy trompe l'oeil effects for those with bad eyes.

Nest, apparently, runs Linux on a Cortex A8. That is a power hungry beast. No wonder it has a rechargeable Li-po battery inside.   It uses the 24VAC to charge it. (If you don't have a Common wire, and I don't, it does this clever but dangerous trick of pulse the fan/AC/heat trigger line to complete the circuit and trickle charge the battery -- apparently that cause the start/stop ping of death on HVAC units that don't debounce away the false triggers).

Then there is the problem of what if you use the interface too much, run buggy software updates or spend too much time on wi-fi. You'll drain the battery, right?  (The trickle charge takes time and you are always running off the Li-po).

I don't think Linux is ready yet for 24x7 systems that run off of battery.  (A tickless kernel is a must for battery longevity, and that is just a start). But I could be wrong.

There are advantages to running an OS. It opens up development options: I'd love to try and get some Haskell code into an "embedded device".  Without thinking about embedded development issues, you can focus on the algorithms.

What about the power miserly Cortex M4s?  They are starting to come with a lot of RAM and massive flash spaces.  I've even seen Haskell (and Lua) running on STM32F4 Discovery boards. But we are still only talking about kilobytes of RAM. Until I see real applications run, just blinking LEDs and toggling a few GPIO pins doesn't convince me that you can write serious sized applications for it (where memory allocation can kill you).

For a smart thermostat, it is all about the algorithms. There are, at most, 3-5 interfaces to the HVAC systems. These are basically switches (relays or solid state relays).  It is all about when to turn these switches.

I've been toying with the idea building upon Forth to do smart thermostat stuff.  If I stick to an ANS flavored Forth, I can implement it on bare metal and eventually up port it to an OS when they become appropriate for battery based systems.

What about Wi-Fi and stuff?  I have more to say about that later (e.g. I'd be happy to just use my smart phone in local proximity with Bluetooth to control and data-mine the thermostat).

Haskell and the Embedded Programmer

Can you really use Haskell for Embedded Programming? Well, if you define your embedded platform as (at least) an Intel Atom based computer with gobs of memory... then probably. (Yes, I know about GHC ARM, but has anyone deployed real world apps with it?)

Ignoring the really cutting edge (academic) features of the language, Haskell seems ideal for the embedded developer. What? Wait. Hear me out.

First, let's define the class of embedded I am talking about.  How about my home monitoring application (http://eldermonitor.blogspot.com/). The base station is headless and should run 24x7, so I classify it as "embedded".

It currently runs mostly Lua (it used to run Erlang) on Linux, but it could have been Java on Android OS for that matter. If you accept the notion of a garbage collecting dependent app can run on an embedded platform, then you've made the leap (for good or bad) to modern embedded development.

Unfortunately, all of these modern embedded systems don't seem to run all that well.  My Android phone pauses every once in a while (garbage collecting I suspect) and my Roku crashes after a few weeks of up time.  I am starting to worry about the stability of my home monitoring system (although it has run for a couple of months before I intentionally reboot it for upgrades, etc).   Not just due to garbage collection, mind you.

Now, Haskell also does garbage collection, but the compiler is backed with a lot of type checking and other supports for determinism. The idea is that if you code "safely" (say it with me: catch all of those potential exceptions -- they will bite you later if you ignore them), you have a better chance of avoiding run time errors.  Avoiding run time errors are very important for systems that run 24x7 with no head (display).

Erlang's "expect to crash" approach is a good meta level approach to embedded design, but if you don't have a careful design or code, recoveries from random crashes is not a good thing. Your embedded code needs to be correct. Every crash situation is bad. It is worse if the problem is due to bad code logic (and not a perfect storm of resource conflicts).

Haskell is no panacea, but I've done 3 projects in Haskell thus far (one embedded in a commercial system) and I haven't been bitten by any type-based run time problems.

So, Haskell (or a sane subset of) appeals to me for embedded development.  But when is it overkill? I haven't done a lot of sophisticated stuff with it (yet), so almost everything I've done could have just as easily been done with Erlang or Lua.

Haskell was a bear on some of these projects, but I'm finding the results encouraging.  I feel better about the resulting systems.  Maybe it is time to revisit using it for my Home Monitoring system.

The 8051 won't die... will it?

The 8051 8-bit MCU architecture was introduced, by Intel, in 1980. It is still in wide production by at least a half dozen vendors (including my fave -- Silabs) at prices as low as a half a buck.  My current favorite is the C8051F988 (currently used as the brains behind my sensor nodes). This MCU costs about $1.60 (for low volume purchases) and is essentially an 8-bit SoC.

The C8051F988 comes in a couple of packages, one of which is hand solderable. It requires no additional passive components (an internal oscillator can run at 25Mhz), but I usually throw a capacitor on the power supply pin and a 4K resistor pulls up the RST line.  It has a mere 512 bytes of RAM and 4K of flash (a beefier version can be had for around 1 dollar more). I program it in Charley Shattuck's MyForth, so the memory doesn't feel so constrained.

The C8051F988 has an ADC, internal temperature sensor, a UART, SPI, I2C, etc.  It executes 70% of its instructions in 1 or 2 clock cycles.

Here is the power specs (from the datasheet):

Ultra Low Power Consumption
- 150 µA/MHz in active mode (24.5 MHz clock)
- 2 µs wakeup time
- 10 nA sleep mode with memory retention
- 50 nA sleep mode with brownout detector
- 300 nA sleep mode with LFO
- 600 nA sleep mode with external crystal

I'm impressed. But, of course, why bother with this when an ARM Cortex blows it away? (Ultra low power consumption 32 bitters are starting to arrive.)

A couple of things keep me interested in this chip (and other 8051 variants), and that gets us to what this blog post is about.

First, look at the part count: For under $2 (hobbyist pricing): the 8051 chip, an (ebay provided) SOP board, a resistor and a capacitor.  I have the old Silabs serial ec2 programmer (for initial flashing of a forth bootloader) and use Silabs free programmer under Linux WINE.  No ARM I know of has this simplicity.

Second, and most interestingly, the 8051 architecture doesn't seem to want to die.  Its a relatively simple chip (low gate count) and can be easily implemented as an FPGA core.  When you want to do simple things, it is very handy. It is built into *everything*: Keyboards, microwaves, the new Bluetooth LE chips (like the popular TI CC254x chips).

Start taking stuff apart and you are likely to run into an 8051.

They don't want to die. Somewhere there are engineers who sniff at the new 32-bit Cortex M series (meant to replace those old 8-bit 8051/AVR/etc processors) and then get their job done with assembly or C code that has run solid for the past 30+ years.

Scale if you must, but don't forget reliability

My home sensor base station is using STOMP to transfer sensor node messages into an AWS cloud instance (running RabbitMQ).  I am using STOMP because I can't find an AMQP binding that supports SSL (outside of Java and Erlang).  Or, more to the point: the sensor base station runs Lua and my AMQP binding for Lua is with  amqplib (which doesn't support SSL).  My pure Lua STOMP binding runs over SSL. But I digress...

The STOMP client runs 24x7, pumping messages into the cloud hosted RabbitMQ at a rate of 2-3 messages per minute.  This is not a lot of traffic, but I expect it to scale.

In order to develop (and test) the "server/logic" side of the system, I am running the consumer of messages on my laptop (it connects to the AWS RabbitMQ as a consumer).  The consumer is also talking STOMP.

However, when my laptop lid is closed, all consumption stops. So, for example, overnight I can accumulate a few thousand sensor messages.  Firing up the consumer in the morning should just suck all those messages down and pick up where it left off. Unfortunately, there is a glitch (in RabbitMQ?) where after a few hundred messages (all ACK based -- fault tolerance, baby!) it stops receiving new messages and the remaining messages are marked by RabbitMQ as "unacked".  Restarting the consumer happily consumes a few hundred messages before the same glitch re-occurs.

This is a serious problem and I need to figure out if RabbitMQ is the culprit.  Interestingly, I found that by slowing down my consumption rate (read/respond every 100ms) the problem is fixed. Argh.  Well, that won't scale, now will it?

So, until I figure out what the real problem is, I'll keep consuming as fast as I can.  But, what about the unacked messages? Well, this is where "reliability" comes in.  By default, all of my consumers do timed reads. If they don't receive a message in 60 seconds, then they terminate. (I don't use RabbitMQ heartbeats. I have an "application" level heartbeat that makes sure the whole system flow is working from base station to cloud. This heartbeat fires every 30 seconds).   Failure is an Erlang technique. The consumers are written in Lua, but I did learn one thing from Erlang: Failure is okay, just plan your recovery.

So, once the process terminates, Ubuntu Upstart restarts it.  The result: The system recovers on its own from this bug.  The system continues to run.  The unacked messages are requeued and delivered.

Scaling is great, but don't forget reliability!

Using Forth to question the Status Quo

Whenever I face a  tough problem I try and break it down to the essentials.

Often using traditional methods only leads you to traditional solutions.  Sometimes traditional solutions are just fine, but what if you need something special?

This isn't about programming in Forth. It's about taking the Forth Approach. This means looking at the problem in a different way.  You can use your own favorite language, but consider the path taken (time and time again) by Chuck Moore (Forth's inventor). His chip designs are novel. His approach to problem solving is stunningly minimalist.  Go ahead and google him, I'll wait...

Sometimes is worth it to think; "What is the simplest possible way to do this?".
In my mind, simple doesn't (necessarily)  mean easy.

Consider designing a wireless temperature sensor.  You want to mount them in every room in your house. Now before you whip out your Raspberry Pi, consider three factors: Cost, Power and Size.  This sensor should cost under $20 in parts, be discrete enough to attach to a wall, and should run for at least 1 year reporting temperature once per minute.

Now, thoughts of Wi-Fi enabled Raspberry Pi (too power hungry and expensive) wane. How about something with Bluetooth LE? ($15 at best; no money left for the board, battery and other parts, plus you have to deal a fairly complex "standard").

I've discussed my approach a year ago here (Why Forth still matters in this ARM/Linux...). It basically describes a $7 RF transceiver and a $3 MCU (that requires only a couple of resistors and caps to function).  The MCU has a built in temperature peripheral.   I hand wrote an implementation of RC4 for a modicum of security. I've coded this all in Forth, but I could have used C. The implementation language doesn't matter -- the approach is inherently Forth-ish.

A year later and I still can't find anything cheaper.  The status quo says I should go to Bluetooth LE (or at least Zigbee). But, at what benefit?

Update:
Okay, this is an even cheaper RF transceiver (just $2.99, but in the crowded 2.4GHz band): http://www.ebay.com/itm/HopeRF-RFM73-2-4GHz-Transceiver-/251209604525?pt=LH_DefaultDomain_0&hash=item3a7d425dad

Complexity and the Future: Revisiting technological foundations of Smart Phones

Every once in a while it is good to sit back, take a deep breath and look at the state of things.

As technology hurls forward we accept building complexity upon complexity.

The Internet is very complex. Fine. I would call it "deeply" complex. In that manner, it is similar to an organism. However, it is based upon a very simple infrastructure called IP (Internet Protocol). Upon that we have a host of other protocols with the most pervasive being TCP.   From there, the complexity escalates rapidly.  But that's okay.  Underneath is TCP/IP and I can always grab hold of it -- it is the earth, solid and firm beneath my feet.

Now, my phone is very complex. A Smart Phone is  made up of a bunch of software. Let's consider Android. Underneath is a Linux kernel (but you can't normally touch that -- imagine floating about the earth just a few inches but never touching ground). On top of that there are processes, a VM, and a bunch of apps.  Oh, and off to the side is the actual phone stuff (sacred and untouchable).

Every once in a while the phone gets slow or needs a reset.  It is indeed a complex beast.

I'm okay with the Internet being unfathomable by a single mind, but my Smart Phone is headed firmly in that direction. So many things working together, so complex. But, unlike the Internet, my phone's software is not self healing. There is no notion of routing around bad processes or chips. When bad things happen, the phone is nearly useless.

What if I want to just make a phone call? Or perhaps send a text message.  Maybe all I want is to message someone over the internet or read my email?

What if we stripped a smart phone of everything but the communication essentials.

Nokia is trying to (re)find a niche. They are offering a new phone for the third world: http://www.nokia.com/mea-en/products/phone/105
This will sell for about $20 in the European market.  The standby time is 35 days.

If there were a bunch of these phones deployed with free text messaging, what could you do with it?
What if there was a slightly better alternative to SMS (larger payload). Or perhaps a multi-segment protocol on top of SMS that the phone could parse.

Why does the entry level into the 21st century Internet require a Smart Phone ($$$)?  Why can't I have a slightly dumber phone that plays well on the Internet?

Home Alone Elderly Monitoring System now has its own Blog

Starting today, I'm posting all of my notes on my Elderly Monitoring system here: http://eldermonitor.blogspot.com/

All of the old home automation  material will remain here, but look for new stuff on the new blog.

A Pattern Language for Haskell System Programming?

Continuing on my previous blog entry (Haskell for the Working Programmer), it occurs to me that there needs to be a set of idioms to define a Haskell for System Programming.  Or, perhaps more strongly: There needs to be a Pattern Language for developing System Programs using Haskell.

When I say System Programs, I am stretching the term a bit to mean an application that touches the real world a lot. That is, it isn't so much focused on doing a ton of data manipulation or business logic, but spends most of its time interacting with the system (hardware, OS, or network) at hand.  This is the land of embedded development, network tools and server management.  Haskell can play here, but I don't see a lot of literature about how to do this.

Haskell is a rich ecosystem for implementing cutting edge ideas. This is its academic heritage and it keeps the language healthy and forward looking. But for us working programmers, we can't always be interrupted from our tasks to explore new mind blowing techniques (e.g. "Okay, I grok Monads, so let's get some work done... whoa, wait... Arrows? I need to start using Arrows?").

So, you want to build Home Monitoring base station (something to collect sensor data, analyze it and perform some action or notification via the Internet).  Oh, and it needs a built in web server for configuration.

How do you do this using Haskell?

That isn't quite a fair question. A Haskell newbie would not be advised to adopt such a big project until they've mastered the language a bit. So, let's ask again, but a little more focused:

I'm an Erlang/Clojure/ML/Scheme programmer (so I understand FP); I've played around with Haskell and now I want to implement my Home Monitoring base system. Where do I start?

That's better.

So, what is needed here is way to guide a developer towards their goal with just a subset of Haskell. (I've recently written over  3000 lines of Haskell for a commercial system. It doesn't sound like a lot, but since it was mostly system programming stuff, I leveraged lots of Hackage libraries and FFIs.  In retrospect, I would say that I used a fairly small  subset of advanced Haskell features to get the job done.)

An aside:  I mentioned  the phrase Pattern Language as opposed to Design Patterns.  I don't want to bring up an old war in the Pattern Community (is there an active Pattern Community these days?), but I am talking about a group of related Patterns (or Idioms) that you can select to help you build a specific thing. Patterns in a Pattern Language are not adhoc. Each Pattern leads to one or more Patterns you may choose to help you build the thing. Check out the original source for further understanding and information. (I'm too lazy to find a great example of a software Pattern Language for system programming, but you can look at my own 1997 contribution to the community: A Pattern language for User Interface Design for the general idea of what I am talking about.)

Now, where were we? Subset of Haskell...

This subset of Haskell wouldn't be restrictive. By all means, if an advanced Haskell technique helps get the job done or makes the program more manageable, then use it.  But Haskell has an ocean of ideas and new users are apt to drown in lieu of getting their project completed.

You don't need to master all of Haskell, just master what you need.  Just by using Haskell (in particular the type system), you are already on your way to constructing correct system programs.  (But, please remember to handle exceptions -- the monadic wrapped real world is full of unexpected behavior).

So, what next?  I don't know. I am wondering if something like The School of Haskell would be a good place to start building such a pattern language (where examples could be not only listed but tried out).