Computing stuff tied to the physical world

JeeMon? JeeBus? JeeRev?

In Software on Nov 22, 2011 at 00:01

For several years now, I’ve been working on a software project on the side, called JeeMon. Then something called JeeBus was created, and then JeeRev came along.

That’s a lotta names for a pile of unfinished code!

I’d like to explain what it’s all about, and where I want to take this (looking back is not so interesting or useful).

The Big Picture ™

With monitoring and control in the home and <cough> Home Automation </cough>, the goal is quite simple, really: to figure out what’s going on in the house and to make things happen based on events and rules.

In a nutshell: I want energy consumption graphs, and curtains which close automatically when it gets dark.

There are no doubt roughly one million different ways to do this, and ten million implementations out there already. JeeMon adds one more to the mix. Because I’ve looked at them all, and none of the existing ones suit me. Call it “Not Invented At JeeLabs” if you like, but I think I can help design / build a better system (please remind me to define “better” in a future weblog post, some day).

I’ve pondered for some time on how to present the big picture. Threw out all my initial attempts. This says it all:

Jeemon context

Let’s call the yellow box… JeeMon ! Forget about JeeBus. Forget JeeRev (it’s still there, under the hood).

JeeMon is the always-on software “switchboard” which talks to all this hardware. It can run on a dedicated little server box or on the router. The devices can be connected via serial, USB, Ethernet, WiFi, FSK, OOK, whatever.

Functionality & Features

The primary tasks of JeeMon are to …

  1. track the state of sensors around the house
  2. display this real-time state via a built-in web server
  3. interface to remotely operated devices around the house
  4. present one or more web pages to control these devices
  5. act as a framework which is easy to install, configure, use, and extend

Everything is highly modular, JeeMon is based on drivers and other extensions – collectively called “features”.

Some other tasks which are a natural fit for JeeMon:

  • configuration of each sensor, device, and interface involved
  • collecting and saving the full history of all sensor data and control actions
  • presenting a drill-down interface to all that historical data
  • managing simple rules to automatically make things happen
  • access control, e.g. to prevent “junior” from wreaking havoc

That’s about it. It’s that simple, and it needs to be built. JeeMon has been “work in progress” for far too long.

  1. Oh YES, it would be so nice if all that hardware that’s lying around here gets a pack leader!

    I hope you won’t be too much destracted by hardware things!

  2. I’m finding node.js ( quite attractive for this sort of thing. Its single-threaded event-driven architecture is quite well suited when everything happens at once. Using JavaScript on both the server and in the browser saves some confusion (e.g., potentially some common code, JSON natively at both ends).

    I have an instance running on a Debian Pogoplug logging information from a solar charge controller via Modbus over TCP/IP. I’ve had some hassles with one-wire (there are one-wire packages in Debian Wheezy but Wheezy fails somehow on the Pogoplug so I’ve had to go back to Squeeze) but should be able to get at least basic temperature logging going in it.

    In general, it ought to be pretty good at dealing with randomly arriving packets from Jeenodes and the like.

  3. I think the first step would be to port RF12.h to Linux as a kernel module. Wire up a transceiver to an ARM board running Linux and a webserver. The board then compiles/logs and constructs and serves the webpage.

    This demo uses the bmp085 kernel module, node.js, and processing.js. It is reading the values from sysfs and giving visual feedback on the webpage.

    I can imagine an interface to visualize whole-house sensor data (with history) and also to control remote nodes (motors, leds, etc.).

  4. (as I said: there are a million different ways to do this)

    Node.js and Tcl (and Python with Twisted) use very similar async event models. The JavaScript-on-both-sides is nice.

    As for RF12.h w/ Linux – that addresses one transport interface, doesn’t really affect The Big Picture ™.

    • ;-)

      I hope you stick with the Tcl/Tck approach as it runs on all OSses, meaning I can deploy this on my router, windows server & Mac’s.

      All I need in that case is to install JeeMon, plug in the JeeLink into the router/windows/mac and off I go!

      Remember that Arduino was made to make things simple!

  5. Interesting. I knew Twisted was similar but didn’t realise Tcl was.

Comments are closed.