Some notes regarding the installation of Boblightd on Ubuntu Trusty
sudo apt-get install portaudio19-dev libusb-dev libusb-1.0-0-dev libx11-dev libxrender-dev libxext-dev libgl1-mesa-dev
svn checkout http://boblight.googlecode.com/svn/trunk/ ~/src/boblight
Restore /etc/init.d/boblightd from backups
chmod +x /etc/init.d/boblightd
update-rc.d boblightd defaults
Restore /etc/boblight.conf from backups
For a while now I’ve been wanting to try and monitor home automation parameters by using Zabbix. I already use it to monitor, graph and alert on servers and services at work and at home, so it was a logical extension to use it for home automation. I hope to deploy TinyTX sensors around the house, and by using my mqtt-rfm12b gateway I *should* be able monitor and alert on their battery voltages when things start to run a bit low. Firstly though, something is required to push the data from MQTT to Zabbix.
The first thing that you’ll need is a working Zabbix instance. This is somewhat outside the scope of this blog post, and the documentation is fairly good. You’ll need a host configured, so add one and give it a name, or alternatively use localhost that I think Zabbix comes preconfigured with.
Clone my mqtt-zabbix repository, and you’ll find a XML Zabbix template that can be imported into your Zabbix install (import via Configuration -> Templates). It won’t do anything drastic other than 10 or so Zabbix keys.
Once the import is completed, Configuration -> Templates will contain a template called “Template App MQTT”. This has the 10 items, all of which can be edited to suit. The important part is the “Key” – which must match what you put in the keys.csv later on. Simply put, when Zabbix receives data with a specific key, it gets stored against the item with that key defined. It’s not terribly complicated
If you’re happy with Zabbix and the template import, follow the mqtt-zabbix README to get the rest of it installed. It’s really just a glorified script with some init scripts. Put all the files in the right places, edit keys.csv to match between your MQTT topic and your Zabbix key name, and start the application.
mqtt-zabbix subscribes to the root wildcard topic at /# so possibly isn’t very efficient on systems with massive amounts of traffic, but for home use it’s quite sufficient. I may change this method of working at a later date. In the meantime, the moment something arrives at your topic it will be forwarded on to Zabbix. A log of the event will also be found at /var/log/mqtt-zabbix.log and it will tell you if the key was successfully inserted or not.
To view your data in Zabbix, click on the host, click on Latest Data, and it should be listed under – Other -. You can then choose the graph option on the right, or you can edit your own custom graphs and include the MQTT items.
I recently purchased a CC3000 wireless board to play with on Arduinos, with an aim to use it on an Arduino Mini Pro to control some LED lighting I have. Rather than purchasing through Adafruit as I possibly should have done, it was ordered through Ebay. This turned it into a bit of a learning experience!
The Adafruit library does a firmware check to ensure it’s the most recent version that they ship, however the version I purchased from Ebay was of a lower version, and subsequently the Adafruit library would refuse to run tests. Although this could be tweaked in the code, I didn’t fancy making that change and would rather have hardware with at least a firmware version equal to or higher than the one that Adafruit use. Onwards to updating the firmware of the CC3000!
Firstly, two things should be noted about CC3000Patch
- It requires almost all of your flash space
- It needs newlines on the serial input
The flash space isn’t really an issue until you consider that both older versions of the Arduino bootloader and older versions of Optiboot will take up too much space. I was unable to flash CC3000Patch onto an Atmega328 with Optiboot from around January 2012, so I subsequently had to look at updating Optiboot before going any further.
I was using two Mini Pros to do the programming, and although the guides don’t really cover programming these the process is broadly similar. Hook up MOSI, MISO, SCK, IRQ, Reset, Power and some status LEDs, and then flash ArduinoISP to the host Arduino *before* connecting the target Arduino. I’d also highly recommend hooking up heartbeat, error and programming status LEDs to pins 7, 8 and 9 so that you can see what’s going on. Once you’re happy with that it’s flashed ArduinoISP correctly, and the heartbeat LED is pulsing quietly, *disconnect* the DTR line between your serial adaptor and the programming Arduino. This will prevent it from autoresetting just before the upload is triggered.
Next stage, plug in the target Arduino, and run “Burn Bootloader” from the Arduino IDE (I used 1.0.5). The *target* Arduino will reset, and programming LED on the programming Arduino will light up for a minute or so. Once it goes out, all should be good.
Optiboot on the Mini Pro, and time to try CC3000Patch again.
First off, make sure you wire up the connections correctly. It’s wise to use the Adafruit buildtest sketch at this point to make sure you have communication with the CC3000. If the firmware version is correct, it will tell you that… if it’s incorrect, it will also tell you that The good thing is that you have communication with the CC3000 at this point, and you can move on to updating the firmware.
The documentation for CC3000Patch is fairly good, and all you need to do is compile and upload the sketch to the Arduino, and then follow the documentation. However, if like me you use screen to communicate over serial, you’ll need to use control characters to send newlines to the Arduino before it will start listening to your commands. ^V^J (that’s Control+v, Control+j) are your friends, and you’ll be driving the text menus in no time. I believe the Arduino IDE has a similar setting somewhere in the serial monitor window, although I’ve never used that feature.
All being well the CC3000 will be quietly upgraded to v1.24 (or later), and buildtest from Adafruit_CC3000_Library will then tell you what version of firmware you have. Handy hint also… the SSID is case sensitive
So I wanted a place to store all my private Git repositories, without going down the paid route that is Github. Callum had just set up Gitlab at work, so I thought it might be wise to just use the same toolset.
What with it being installed on a VM at home, it didn’t quite have the same power, but that shouldn’t be too much of an issue. However, after the install and configuration check, I was plagued with Nginx gateway timeouts, blank pages, and no immediately apparent error messages other than the Nginx ones – until I looked at unicorn.stderr.log. The Gitlab process was timing out – yet the configuration check said all was good. Database connectivity was there, as was networking, etc. What gives?
This post however, suggested another problem – Unicorn timeouts. The process isn’t being given long enough to initialise assets, and is timing out. Simply increasing the ‘timeout’ parameter in config/unicorn.rb, restart Gitlab, and give it a moment.
Recently I decided to make some changes to the kitchen. It started off with a strip of warm white LEDs, and I thought “Wouldn’t it be cool if…”. I’ve now lost count of the number of guests asking how it works
There’s a variety of components at play here. Firstly, there’s a Raspberry Pi, followed up by a simple IRF530 MOSFET, a PNP transistor to pull it low, a PIR sensor, and a strip of LEDs.
It’s a a PIR sensor from Seeedstudio that I bought on a whim a while back. It handily runs off of 5v, and returns a 3.3v TTL compatible signal upon detection of movement.
On the Raspberry Pi, I have my own Python app, mqtt-gpio-trigger, running. It continuously monitors pins that are defined in the config file, and in the event of a change of state of any of them it will publish a message to a predefined topic, with the pin number as the final component of the topic, and the message contains the state of the PIN. Simply subscribe to that topic to watch whatever pin on the Raspberry Pi.
A strip of warm white LED lights are attached to pin 18 of the Raspberry Pi, via the IRF530 MOSFET. There’s a bog standard NPN transistor to help saturate the gate of the MOSFET, and it’s pin 18 as that’s the only pin on the Raspberry Pi that does hardware PWM. Using any of the other pins subjects you to vagaries of the CPU.
Controlling pin 18 is mqtt-pwm-lights, another one of my scripts. It simply sits and runs, and subscribes to yet another MQTT topic. When it receives a message with a value between 0 and 512, it fades the lights to that value. Due to the NPN transistor it’s inverted, so 512 is off, and 0 is on. A minor annoyance, but the home automation controller handles that.
In the middle
Producing the show is a small script that isn’t public. All it does is listen for MQTT events and reply with canned MQTT messages in return. It’s a stopgap measure until I find a better home automation controller. The main role of the script at the moment is to listen to events from the PIR, start a timer when triggered, and publish a lighting level request. When the timer expires, the lighting level returns to normal (ie, off)
So that’s it. Ambient automated lighting for the kitchen, and worktop lighting, all rolled into one.