One of the main design goals for JET, is that it must run well on very low-power Linux boards.
The reasoning is that you really don’t need much computing power at all to manage all the data flows involved with home monitoring and automation. It’s a very slow kind of real-time system, with at most a few events per second, and most of the time nothing else to do than collecting the incoming sensor data for temperature / light / door / motion sensors, etc.
Then again, a good responsive user interface which can update a flashy graphical screen and is able to show live graphs with potentially a lot of historical data is considerably more demanding. The insight here, is that all of this processing can take place in the browser, which is always very performant nowadays, on desktops as well as mobile platforms.
In fact, with modern “reactive” and “single-page” applications, we don’t even need a very capable web server - if it can serve 100% static files and handle a WebSocket connection on the side for all the (bi-directional) real time stuff, we’ll be fine. There’s no need for any server-side rendering of web pages, i.e. no templating, no embedded scripting language, nothing.
That means that on the server side, JET must include these functions:
- a message dispatcher, i.e. MQTT with Mosquitto
- accept incoming sensor data, via serial, gpio, i2c, LAN, WiFi, etc.
- keep raw data logs, i.e. the current “logger” module in the hub
- a scalable data store, in this case a key-value database using BoltDB
- a web server, serving static web pages, and JS/CSS/image assets
- websocket handler, tied into MQTT (either in Mosquitto or via the hub)
- the ability to run arbitrary tasks as custom JetPacks, launched by the hub
- optional extensions, such as statistics, historical data, and a rule engine
But that’s about it. As long as none of these pull in large applications, we really can keep it all very lightweight. And indeed, so far, it really is a very light load - after two weeks of running, the MQTT + hub have proven to require extremely few resources so far:
- the hub process (in Go) needs less than 5 MB RAM as working set
- Mosquitto (in C) needs well under 1 MB of RAM to do its thing
- on an Odroid U3, the hub uses 15 min/day of CPU, and Mosquitto 1.5 min/day
- that’s with 1,500 incoming messages per hour, about 3 MB of raw logs per day
This is a few percent of a Raspberry Pi - even an “ancient” model B is more than enough:
(model A is a bit inconvenient due to its lack of Ethernet and scarcity of USB ports)
Now let’s look at the software side of things…
The minimal JET setup has virtually no dependencies on other software, since
the hub is built as a fully static Go executable, and Mosquitto is a one-line
install (”sudo apt-get install mosquitto”) which also pulls in virtually no
other packages.
For a truly minimal Raspberry Pi setup, all you need is some small Debian or Raspbian build - version 8.x (“Jessie”) is the latest incarnation these days. For a tiny distro, check out pipaOS.
If you’re using HardKernel’s Odroid C1 board, which is really a RasPi clone, then you could use this 1.0-20160131-C1 image for it. It’s a very nice minimal setup, as described in this forum post. The result will fit on even a small 1 GB (µ)SD card, with enough room for a year’s data collection.
And that’s about it. Since the hub can be cross-compiled from Go on any machine (see the JET releases page for a few builds), and Mosquitto is ready to, ehm, go from the “apt-get” package repository used in Debian, Raspbian, and Ubuntu, there is not even a requirement to install the gcc compiler toolchain on such a machine. The hub’s installation has been described earlier.