JET development mode setup Feb 2016

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:

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:

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:

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:

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:

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.

Weblog © Jean-Claude Wippler. Generated by Hugo.