Since JET is intended to remain always-on, at least as far as the hub is concerned, we need to be a little careful how we introduce changes. The way to do this in JET, is to treat the whole system as one, whereby development simply happens to be inactive some of the time:
The hub, and all the interfaces and JetPacks it has been told to activate, will continue to run no matter what (unless they crash or fail in some other way, evidently). This is what keeps the home monitoring and automation going at all times.
For development, we’re going to need a whole slew of tools:
- a command-line shell, to perform ad-hoc tasks
- a web browser client, to examine the public interface of the system
- NodeJS to (re-)generate all the client-side code and assets
- a programmer’s editor or IDE, obviously
- an SSH terminal session to connect to the machine running the hub
- Go, or whatever language environment we are using in our JetPack
- Git, to manage versions and revisions of all the source code
- … and probably a variety of other applications and “dev tools”
This is what it looks like on a dual-machine setup, connected via a (local) network:
There are a number of points to make here:
- a JetPack does not have to be running on the same machine as the hub - although this will depend somewhat on its role: it might need to access a hardware interface, for example
- the hub is not in charge of what happens on the development machine (shown here as being at the receiving end of the arrows) - it is not necessarily the parent of all JetPacks
- the hub does not need NodeJS, even when it’s serving web browser requests, but if you would like to use NodeJS functionality, you can install it there as well, of course
- the above dual-machine split is optional - when making sweeping (or risky) changes, or simply to try out JET first, this can all be set up on a single development machine
The development system at JeeLabs is a Mac OSX laptop, with the Homebrew package manager installed to grab all the pieces of software, and to easily keep them up to date. Currently, this is:
- ‘brew install go’ - Go version 1.5.3
- ‘brew install node’ - NodeJS version 5.6.0
- ‘brew install macvim’ - the Vim editor, as GUI variant
- ssh is pre-installed, gcc and git are in the standard Xcode command-line toolset
If you develop on a Windows or Linux PC, you’ll neeed to locate these packages for your system. Version requirements are not very stringent: try to use fairly recent versions of Go and NodeJS.
The one missing piece is cross-compilation for ARM and AVR µCs. Here are some options:
- for ARM, you can get good ready-made builds from the launchpad.net site
- or set up your search paths to use the gcc cross-compilers included in the Arduino IDE
- or you could choose to set up cross-compilation on the hub’s Linux machine -
this will be slower but can be automated with some remote commands through
ssh
More details about these different options will be the subject of a separate article.
Lastly, as example of a dual-machine configuration, here is a permanent-ish setup for the hub:
Actually, this is going to be used as the basis for a secondary test setup at JeeLabs. This should make it easier to experiment with more radical design ideas involving the hub itself. The “main” production setup is separate, and already running 24 / 7 on a battery-backed Odroid U3.
The components above are, in clockwise order:
- an Odroid C1+ with 8 GB eMMC, running a lightweight version of Debian Jessie 8.3
- also mounted inside the case: the RasPi RF board
- a JeeLink Classic with RFM12 @ 868 MHz
- an Odroid-branded WiFi stick
- underneath the JeeLink, a short USB cable to …
- a HyTiny-STM32 board, programmed to act as Black Magic Probe, driving …
- a second HyTiny-STM23 board, with RFM69 and OLED display
- a 10,000 mAh LiPo-based USB Power Bank - it’ll easily power all this for a day
- a small experimental node, based on an LPC824 and RFM69
- all mounted on … foam board!… with … tie wraps!
More options are likely to be added later, e.g. for trying out an ESP8266.
This configuration has multiple radios, so it can also be used to generate test packets and see how the receiving node (and hub) processes the data. And the OLED is a nice debugging aid.