Home Automation in Python & MQTT

Hey everyone

tl;dr (I waffled too much :laughing:)

  • I built home automation system in python, find it here
  • pre_release_2 is prob stable
  • Don’t use it with stuff that can break from glitches just yet, let me make it a little more stable than wet sand
  • Feedback, suggestions & help are very welcome, this system is a waste if it only work for me :wink:
  • WARNING: I am a “commit whore”(?), so please excuse the several billion commits a day :blush:

Great Wall of Text

I finally was happy enough to make my home automation project public, hoping one day it could be used at makehackvoid as well but main purpose is to stop my lights from turning on at 0600 on a weekend :smile:

So so far I have implemented basic input handling and some limited doco, been grinding away on writing unit tests so that I don’t break people’s houses when I have a max-brain-fart :blush:

In it’s current state it’s possible to make light switches and make them turn on individual lifx lights and groups (via mqtt files, sorry my doco is scarce at the moment)

Also it is possible to make it execute arbitrary code (either through a python script or through a bash script)

On my road map is making it a bit more smarter, i.e. implementation of conditional rules to enable smarts like
Monday - Friday turn on lights at 0600, but only if I am not on leave

Usual heads up, I am a commit whore, so please excuse the 20,000 notifications a day caused by me commit-brute-forcing travis :wink: if the notifications annoy you, turn on digests :stuck_out_tongue:

My main bugs are that travis is a little painful because it doesn’t like having to create folders, will spin up a barebones VM and check to make sure that I haven’t done something stupid like “chmod -R 777 ./”

As previously mentioned doco is a little scarce at the moment :’( been trying to strike a balance between burning myself out on writing tests & writing doco and giving myself coders block from too much coding

Suggestions & Ideas & feedback are warmly welcome, I am trying to make this thing as “white label” as possible, its a waste if it only fits in my little patch of civilisation :frowning:

pre_release_2 should be stable enough to use, note that the trunk is so fresh it’s still eating the salad on the plate so please do not connect it to your HVAC system, I don’t want your A/C compressor dying a horrible rapidly cycling death at the hands of my derpy code :smile:

p/s holly great wall of text :blush:

1 Like

That looks cool! I just have a couple of thoughts I’d like to share - feel free to ignore them or whatever, don’t let me bikeshed your project into oblivion :slight_smile:

  • If you switch to the python logging API rather than printing to stderr, you won’t regret it! Let the user configure their logger in the config and you’ll allow a lot of flexibility and ease distro packaging, if you ever want to do that.
  • consider http://supervisord.org/ rather than start/stop shell scripts. I can help you set this up some time but it’s pretty easy - suddenly it makes your project feel grown up when you can control it with your distro’s service/systemctl commands :smiley:

Once again, these aren’t high priority suggestions or anything, you probably have more urgent priorities right now, just thought I’d share my initial thoughts.

It’s very much appreciated :slight_smile: and ta for the kudos

I was wondering what the best way was to go about suppressing output :slight_smile: During unit testing its a tsuami of text :frowning:

Also proper logging would help the end users troubleshoot glitches and find rouge traffic

Ta for that :smiley: that looks alot easier than writing init.d scripts (and writing scripts to STOP stuff without exploding other processes :laughing:)

The python logging API idea is really handy as it will make troubleshooting tests alot easier, I haven’t fully looked into it but I am assuming that I can seperate streams, i.e. have a seperate log for “raw debug output” vs “general logging”

That’s correct, I usually configure separate loggers for debug vs “production” log messages. I’ve just whipped up a barebones git repo demonstrating my usual pattern. Whether it’s anything even remotely matching accepted python best practices, I have no idea… https://github.com/csirac2/python-logger-example/