This page attempts to show a broad overview of what I'm trying to accomplish with my home automation softare project.
- Redundancy. Don't depend on one single server or service. Everything should be replaceable. Upgrading something on-site, or hunting down a bug, shall not cause the bathroom light to not turn on.
- Simple programming model. Small tools shall accomplish exactly one task.
- Active configuration. All systems shall access some common on-line configuration storage; updates to that config shall become "live" immediately. There shall be no "Reload" button, let alone "Restart".
- The config system shall know which state each device is in and which state it should have (and why). There's no other state stored anywhere, this when the whole system gets restarted everything will be as before.
- Back-end systems which access a common medium shall monitor and/or replace each other, if at all possible. Thus, a wireless system shall have a receiver which monitors the sender, wired systems shall have more than one bus master (active if possible, passive if not).
- Wireless systems are only used when absolutely necessary. I don't want to fight other transmitters, or replace batteries.
- Good alarm handling (fire, intruder) needs to be part of the design.
- I want to have intelligent heating control.
How do I plan to get there?
- Static configuration (everything that's to be restored as-is after a power failure) and state (temperature, …) will be stored in etcd.
- Intents and errors are treated the same way as states. They're just going to be deleted when their goal is reached or the problem is fixed.
- Dynamic communication (RPC, PubSub) will go through RabbitMQ. Its main selling point is the fact that it also talks MQTT, which is great for connectiong to OpenHAB, or mobile devices.
- Small-voltage periphery will be connected with 1wire, preferably using the "MoaT" slave device code.
- The "Gira Dual" smoke alarms have a decent serial interface which has been reverse-engineered. Also, they can be powered externally.
- Mains power is controlled using the KNX bus.
- Build an interface for the Gira, and a 24V PWM module for controlling the valves of my radiators.
So … all of this requires software. And some hardware.
I'll write a small RPC system on top of AMQP. It'll support redundancy, discoverability and monitoring/debugging.
- The base code is done.
- Code to attach to RPC or PubSub is refreshingly simple.
- Some tools are missing.
I'll write a snall controller+monitor to talk to etcd, allowing me to monitor events on whatever level I want.
- Basic code is done.
- Code for change monitoring is somewhat rudimentary and too complex.
- Tools: ?
Data in etcd need to be structured and well-laid-out.
- hardware level (KNX addresses 1/2/x are beind the bus attached to system 'xyzzy')
- functional level (the hallway light is controlled by a bit at KNX address 1/2/3)
- state (the hallway light is on)
- intent (turn off the hallway light because it's past dawn)
- priority (the wall switch shall always toggle the light, but the presence sensor may do that only when it's dark)
State: preliminary thoughts.
Talk to 1wire and the devices behind it.
- The old MoaT code has support for 1wire, but it's too convoluted and error prone.
- Missing: autodiscovery of MoaT devices.
- Preliminary code for MoaT device's alarm handling.
Same for KNX.
- Talking to the physical bus is handled by knxd. State: works, mostly.
- Instead of autodiscovery, KNX has a really convoluted XML project file which needs to be parsed. State: preliminary code.
Visualization: error display, etcd data structure browser. * there's a rough GTK-Frontend. * Some web frontend would be nice.
Hardware: prototypes exist; the heating controller works, Gira needs software which is not yet written.
Seriously: I do not plan to market this commercially.