JET, as seen from 9,144 meters Jan 2016
The JET project name is an acronyn for “JeeLabs Embello Toolkit”. And with that out of the way, please forget it again and never look back. A few more acronyms will be explained when the subsystems are introduced - none of them particularly fancy or catchy - it’s just because we can’t move forward without naming stuff. Names and terms will be introduced in bold.
As will become clear, this is a long-term project, but not necessarily a big one: this is not about creating a huge system. It’s more about making it last…
This has implications for the choices made, but even more for the choices left out, i.e. the options being kept open for future extension.
First off: JET is neither about picking a single favourite language or tool and imposing it on everything, nor about limiting the platform on which it can be used. Any such choices made today would look stale a few years from now.
But evidently we do need to pick something to work with. These choices will be made based on requirements as well as current availability and stability. With luck, we can avoid having to combine a dozen different languages & tools. But choices made for one part of the system won’t impose restrictions on the rest. How this is possible will become clear in the upcoming articles.
So what is JET?
JET is an architecture, in the sense that it covers a whole set of systems: a central machine, all sorts of remote “nodes” for sensing the state of the home, environmental data, nodes which control lights, appliances, curtains, etc, and a variety of controls and displays, from switches to mobile screens
JET is like a city - pieces come, pieces go, everything evolves as needed, and most importantly: the design embraces variation - old and new - it’s all about being able to use a heterogenous mix of technology, because over the years hardware and software is bound to change, again and again
JET is a conceptual framework, allowing us to implement a real working setup, without having to constantly revisit the choices made so far - there needs to be some level of consistency for different parts to be designed and built over time, in such a way that everything continues to inter-operate nicely
Some technical design requirements which will greatly affect the choices made:
- the core of JET is always on: it needs to run 24 hours a day, 7 days a week
- the (realistically) expected lifetime of this core must be at least 10 years
- it has to run on low-cost commodity hardware, e.g. Raspberry Pi, Odroid, etc.
- JET must be extensible enough to connect with just about anything out there
- there has to be a good way to evolve or migrate from one setup to the next
- all admin tasks must go through authenticated access to the central system
Here are a few more requirements, some of which are perhaps less conventional:
- the system must be self-diagnosing and self-healing, wherever possible
- it must be possible to run in unattended mode without any user interface
- web access is optional, with possibly more than one server setup in parallel
- support for reduced-functionality mode when the central machine is down
One could almost compare this to designing for a car or a comms exchange…
Or to put it in a somewhat different perspective: JET is for real use on Earth, by real humans, but its core has to be written as if it will run on Mars, in a very unforgiving environment!