Computing stuff tied to the physical world

Archive for March 2011

Software evolution

In Software on Mar 17, 2011 at 00:01

With all the focus on sensors and embedded hardware, I’ve lost track a bit of the other side of the equation – monitoring all that incoming data, and (later on) using it to control devices. The receiving end – i.e. software running on a central PC (or embedded Linux box) has not kept up with the rest of the Jee world.

One reason was that my setup for collecting sensor data around the house has been running quite smoothly. Producing these graphs, updatable via a browser refresh:

See this, this, and this post for more details about how it was done. The JeeMon 2009 setup has been running almost non-stop on a low-power NAS, called the Bubba II (now replaced by newer models). There were only about half a dozen system restarts in these past two years, some due to power outages, some due to devices needing a reset, but that’s about it.

Trouble is… all development on this has stagnated. I did start on a JeeMon 2010 successor, but that has only been used for newer projects, such as the ookScope. In the end, I didn’t really want to disrupt my working data-collection setup and just kept the old one going. So now I’ve got two years worth of detailed logging and a local web site which is showing its age and not very useful for meeting my new requirements – let alone being able to perform more meaningful stats and controlling devices for home automation.

Last summer a student project was started at the nearby Utrecht University to try and come up with a general infrastructure which would be able to do a lot more than what I had. The result is a new system called “JeeBus” (more details coming soon on this weblog).

While JeeBus does provide a fair set of interesting features, one of the issues that kept bothering me is that normally in software development you have to either run the code or make changes to it. The “conventional” operation mode is to stop the server, edit the code, and then restart it to pick up the changes. With a bit of luck, there may be the option to re-install certain parts – but usually this is limited to “drivers” and “extensions”.

I find this stifling. Having to restart an app just to try out a one-line change is much more disruptive during active development than such a simple stop/re-start would suggest, because each time you also have to get the process back to the state you were working on. And with dynamic scripting languages, it’s a bit silly to have to jump through such hoops – which really stem from the edit-compile-run cycle of statically-bound environments, decades ago.

So I’ve started scratching my itch, and implemented a small core “hub” which starts up functionally empty with just enough capability to accept remote procedure calls (RPC‘s) and to inject plugins into a (local or remote) running process. The last version of each plugin is saved and is automatically loaded again after a restart. The result is a JeeMon process which starts off as a blank slate and evolves into a full-fledged app – web server, gui, hardware interface, background task, anything.

So far, development in a “live” process looks promising. There are less and less situations where I need to restart. I’ve set up a little tool to push all changed plugins to a remote hub, and that really completely changes the landscape of software development for me. No need to take down a real-time system anymore, which is what most of all this is about when it comes to physical computing and devices. Bugs generate stack traces, but the hub continues to function, so re-installing a fix usually solves the problem. And changing code in a working system has never been easier. This matters a lot, because I really really want to be able to “grow” a system over time.

Starting and stopping a process which is designed to run non-stop is odd. Let’s see if this new design will make it unnecessary in most cases – during active development as well as for tweaking a working setup at a later date.

Gas flow measurement artifacts

In Hardware on Mar 14, 2011 at 00:01

The raw gas consumption graph always looks a bit odd:

Screen Shot 2011 03 13 at 12.59.45

Green is gas flow, red is electricity consumption.

This is the same oddity I described two years ago on this weblog. The values are calculated from the last rotation time of the meter, but with gas flow things are a bit different: gas consumption is not continuous but a discrete on/off process, with some “modulation” once on.

So instead of each of those “tapering off” effects, what really happens is that the flow stops completely for a while and then resumes again later on.

This is an example of where the measurements need to be “fixed” (!), by injecting fake data points. It also illustrates how you can’t really know anything about consumption between disk rotation pulses.

The vertical grid lines in the above graph are spaced 500 l/h (resp. 500 W) apart, btw.

Power consumption

In Software on Mar 12, 2011 at 00:01

I’ve been working on some new software to better handle all the messages flying around the house. Took down the old system, and started collecting stuff with the new framework.

First one that always interests me, is the baseline power consumption. So I grabbed some values from last night:

Power 11 03 2011

That’s about 450 watts when all the lights are out and nothing is happening – shocking!

Uh, oh – 4000 kWh of vampire power on a yearly basis. Either my new calculations are way off, or some serious stuff has crept in here at Jee Labs which is drawing lots of power!

Update – Yeah, I was off by a factor of 4 in the low range. Forgot that I had added some fancy bit packing to get more resolution across in the metering sketch:

Screen Shot 2011 03 12 at 11.58.23

The lows are around 110 W. With the 24h “internet presence” (server + router + fiber modem) taking an estimated 30 W. Now that makes sense again!


In Hardware on Mar 8, 2011 at 00:01

There’s a brand-new “Modern Device” out, the BUB II !

Screen Shot 2011 03 07 at 22.21.15

Lots of options, also on the back (sorry for the color difference: pictures were taken in different contexts):

Dsc 2478

I’ve been waiting for some time for this one, since the old BUBs ran out quite abruptly not so long ago…

The important thing to note is that the BUB II is compatible with JeeNodes out of the box. No jumpers, no settings to tweak, nothing. Just solder in the header and you’re all set.

And of course, most importantly…

Dsc 2477

It’s now the same blue-and-gold as all the other boards at JeeLabs, and it even has exactly the same width as a JeeNode. One more step towards world-21.1mm-wide domination :)

I’ll update the shop shortly, all new BUBs are now sent out as this BUB II.

New USB power option

In Hardware on Mar 2, 2011 at 00:01

Ah, I’ve finally found a nice little CE-certified power supply for USB:

Micro usb

Extremely small (i.e. easy to ship), and very efficient. This thing will provide up to 1000 mA at a stable 5V level. Perfect for JeeLinks, JeeNode USB’s, and Arduino’s – or any other USB devices for that matter:

Dsc 2461

The power consumption when idle is a mere 0.20 watt, i.e. less than 1 mA of mains current. When plugging in a JeeLink, this increases to 0.32 watt, which is pretty phenomenal actually: the difference is 120 mW @ 5V = 24 mA, just about exactly what the JeeLink consumes with an ATmega running full-power and the RFM12B in receive mode.

I’ve added it to the shop and also added it as option to replace the AA board in the JeeNode Experimenter’s Pack in case you’d rather run off mains power.