Technology

MQTT to Zabbix Gateway

0

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.

Updating Optiboot & CC3000 Firmware with an Arduino

2

Optiboot flashing in progress

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!

If you were following Texas Instruments guide you’d be using one of their products to do the update. With only Arduinos to hand, I ended up trying out CC3000Patch sketch from Chris Magagna.

Firstly, two things should be noted about CC3000Patch

  1. It requires almost all of your flash space
  2. 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.

CC3000 being flashed

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 :-)

Thinkpad X201S Fan Control

0

I noticed the other day (it was kind of hard to not notice, to be honest) that my laptop shut down abruptly when it overheated. This shouldn’t be the case, as the thermal controls on the mainboard should have spun up the fans.

After some poking around, I found that with the default ‘auto’ fan control, the top speed of ‘level 7′ only spins the fans around 4000RPM, even though when the feedback loop is disengaged (echo level disengaged > /proc/acpi/ibm/fan” they can spin up to 7000RPM, and bring the temperature down from the critical 100C mark.

This bug report suggests that something is completely amiss with the kernels thinkpad_acpi module, and nobody really knows why. The end result is that fans spin too slow on the Thinkpad range of laptops. This can, however, be resolved with a couple of edits and an additional package. The following instructions were tested on Ubuntu 12.10, most likely work exactly the same on all Debian versions and derivatives, and can be adapted for use on other Linux distros as well.

Firstly, enabled userland control of the Thinkpad fans with the following command –

echo options thinkpad_acpi fan_control=1 >> /etc/modprobe.d/thinkpad.conf
rmmod thinkpad_acpi
modprobe thinkpad_acpi

This will enable the new settings for your current session, and all future sessions too.

You should now be able to set the fan speed manually with commands such as –

echo level 0 > /proc/acpi/ibm/fan
echo level 7 > /proc/acpi/ibm/fan
echo level disengaged > /proc/acpi/ibm/fan
echo level auto > /proc/acpi/ibm/fan

The key bit here is to remember that ‘disengaged’ equates to ‘127’ on the grand scale of speeds.

Next step is to install the thinkfan package, and enable automatic startup –

apt-get -y install thinkfan
sed -i s/START=no/START=yes/ /etc/default/thinkfan

Now, as above, the default fan speeds are too slow. So even if thinkfan commands a level 7 fan speed, it won’t be fast enough to keep your hardware cool. To make it run up to full speed, you have to disengage the feedback loop and let it run in failsafe mode. Don’t worry though, thinkfan will bring it back into ‘auto’ mode once temperatures are back to normal, so you can have normal battery life and normal noise levels once your compute process is complete.

Edit /etc/thinkfan.conf, and at the end adjust the endpoint for level 7, and insert a new line for fan speed 127. My thinkfan.conf is as below –

(0, 0, 55)
(1, 48, 60)
(2, 50, 61)
(3, 52, 63)
(4, 56, 65)
(5, 59, 66)
(7, 63, 66)
(127, 66, 32767)

Save thinkfan.conf, and start thinkfan with this

/etc/init.d/thinkfan start
Once 66C is passed, it will enter disengaged mode, and run at full speed until it reaches 66C or below again.

My aging quad core i7 2.13GHz laptop will happily run BOINC now, at 97C, so I say it’s working :-)

MQTT Republishing Itch

1

So, I had an itch. A variety of data coming in from a variety of sources, all over different protocols and methods, with different names, heirarchies, and paths. For a while I’d been pushing the data into MySQL, but this seemed a bit of a hack, and it still didn’t really cure the problem as it was more of a historical record than an attempt at mapping between the source and the destination, as it were.

I’d been fiddling with MQTT for a while, and had started publishing data over it via my personal broker. And then I read Roberts post over at http://blog.hekkers.net/2012/09/18/mqtt-about-dumb-sensors-topics-and-clean-code/ about republishing it in a logical way.

So simple! So, I wrote a republisher. It’s very simple, and it scratches my itch (and hopefully Roberts too). Data comes in via whatever naming scheme or topic you like, and it gets republished in whatever fashion you want. The map is maintained in map.csv, and items are separated by commas. The MQTT spec doesn’t reserve any characters for the topic name, so I’ve used a comma out of CSV convenience.

The code is over at https://github.com/kylegordon/mqtt-republisher

Setting up the Squeezebox Receiver

0

I’ve got a variety of Squeezebox Receivers dotted about the house, playing synchronized music and audio on demand. Due to the lack of a remote control requirement (using the Android controller), I opted to get the receivers on their own. However, the setup procedure is highly dependent on the remote control.

To work around this, grab a copy of net-udap from https://projects.robinbowes.com/Net-UDAP/trac. Switch user to root, and then fire up ./scripts/udap_shell.pl. Switch the receivers into init mode by holding down the front panel button until it blinks red slowly. If you end up with it flashing red quickly, you’ve just reset it to factory defaults. No great loss, as the procedure is mostly the same.

Once in the UDAP shell, run ‘discover’ to scan the network for devices. After a while it will come back to the prompt, and ‘list’ will show you the discovered devices. Pick one to configure with ‘configure X’ where X is the item number.

I found that the factory installed firmware was pretty poor at doing DHCP. This may due to my lack of expertise with this equipment, or actual bugs in the software. Whatever it may be, I found the best option was to give it some static network address settings first, let it update, and then switch to DHCP.

Due to the high demands I place on my home network, I have GigE ethernet to every device. Wireless is solely for laptops and mobile phones. Consequently, the settings below are for a wired connection.

Remember… run this AS ROOT!!

=== STATIC DETAILS ===
set lan_ip_mode=0
set interface=1
set lan_gateway=172.24.32.5
set lan_network_address=172.24.32.123
set lan_subnet_mask=255.255.255.0
set squeezecenter_address=172.24.32.6

save_ip
save_data
reset

After you hit save_data, it will send the settings to the device, and the device will hopefully respond to confirm it. You should see “Raw msg:” followed by a hexadecimal dump. If that doesn’t appear, try save_data again after a short delay.

The flashing LED sequence will hint that it’s not configured, but it is. If it detects a firmware update is required, it will start pulling it down and installing it. It will indicate that this is happening by rapidly flashing the front panel LED a bright white colour until the process is complete. Once it’s in a safe state, and if it’s still not indicating its presence on the network correctly, pull the power connector out and reinsert and then visit the Logitech Media Server web interface. The device should then be listed in the player drop down.

Now that the device is on the network and working, it’s time to switch it over to DHCP mode. Yet again, hold down the front panel button until it slowly flashes red. Jump into the UDAP shell again, run a discover on the network, and then configure the device that it finds.

=== DHCP DETAILS ===
set interface=1
set lan_ip_mode=1

save_ip
save_data
reset

This probably also won’t give any visual indication on the front panel. Tail the DHCP server logs to make sure it gets an IP allocated. If it does, check the Media Server web interface again.

All being well, it should then be up and running using DHCP. Happy listening!

Go to Top