ads' corner

The Huginn software is not only good for monitoring Twitter feeds, it can also be used to monitor websites for changes.

That's actually easy and needs only two agents:

• Website Agent
• Notification Agent - Email Agent, maybe

A very common use case for hooks in git is a "pre-commit" hook. This hook is used to verify the to-be-committed data before it is added to the repository.

One important note: hooks are not part of the repository itself. Everyone can install a hook on it's own checkout of a repository, but by default the hook is not there when you clone/checkout the repository. This avoids security problems by executing arbitrary code during "git commit", or any "git" operation.
Because of this implication it is common that developers install a hook from somewhere in the repository into the ".git/hooks" directory. And in addition, the server side (the repository) can run the same checks during "git push", to enforce the rules.

Hooks in git work in a simple way: whatever program or script is run as the hook has to set a return code. If the return code is "0", git proceeds. If it's not "0", git aborts the operation.

One of the things I'm using Huginn for is monitoring for Twitter keywords. Some of them might appear in pairs, as example people like to tag Tweets about PostgreSQL with both #postgresql and #postgres. When I was using IFTTT this always created two emails, one for each hashtag. With Huginn I can deduplicate the events, and only notify about the first occurrence.

I need the following agents for this scenario:

• Twitter Search Agent
• Trigger Agent
• De Duplication Agent
• Email Agent

Huginn comes with a number of Twitter agents, but before they can be used you need to authenticate them. That process requires multiple steps, and they are not well documented.

The basics are described on the "Configuring OAuth applications" Wiki page.

For the Twitter integration one must know that you are using a single Twitter app for all users, but every Huginn user can (and should) have this app authenticated against their own Twitter account. Therefore if you want to use multiple Twitter accounts in Huginn, you need multiple Huginn users.

Huginn is a great piece of software, but the documentation is ... a bit sparse. Especially when it comes to details of the agents. I'm going to blog about a couple more more examples in the future.

For another project I'm using Leaflet, a JavaScript library for rendering maps in a browser. New versions are released occasionally, and I want to know when it's time to update the project website. Huginn can do that.

After installing Telegraf and hooking up everything into InfluxDB, I was missing the status of my backups. Every system here creates encrypted backups every night, and stores them on a central NAS, and off-site. But I want to know statistics about the backups, and see if something is not working.

I'm using Restic for the backups (will blog about this another time). However Telegraf does not support Restic directly, I need a few workarounds. This blog post however is not directly about monitoring the backups, but about how to write your own plugin for Telegraf.

I have an InfluxDB up and running in my network, and decided to monitor all (well, all possible - the QNAP seems to be a problem) devices. That's quite easy to do by installing Telegraf as a server agent, and add some configuration. Everything is deployed using Ansible, so I can re-use the same Playbook for many devices.

I'm in the process of updating my entire home setup, and integrate everything properly. Part of this process is to automate everything, and use Ansible Playbooks to deploy devices and configurations.

Today: install Telegraf and send data to InfluxDB

Along the way something broke, and Ansible doesn't really like me anymore. But let's start at the beginning.

In the Telegraf configuration in "/etc/telegraf/telegraf.conf" one can specify output plugins. One of them (probably the most used one) is "InfluxDB". The InfluxDB instance(s) are specified as a [...] list. In Ansible I somehow need to have this list as a string, and write it into the configuration file. This happens:

TASK [Update telegraf.conf InfluxDB settings] ***************************************************
changed: [localhost] => (item={'section': '[outputs.influxdb]', 'option': 'urls', 'value': ['http://192.168.xxx.xxx:8086'], 'state': 'present'})
[WARNING]: The value ['http://192.168.xxx.xxx:8086'] (type list) in a string field was converted to "['http://192.168.xxx.xxx:8086']" (type string). If this does not look like what you expect, quote the entire value to ensure it does not change.

Looks nasty ...

For my openHAB system I installed InfluxDB (on a separate) Raspberry Pi. The Pi has a 32 GB SDcard, but that is not enough for storing all the data, and that Pi has additional work to do as well. For that reason I also attached a 1 TB disk to the Pi, and mounted it on /data. Now all I have to do is move the InfluxDB data directory to /data.

A while ago I upgraded openHAB from version 2.4 to 2.5. That comes with the usual share of problems, but eventually I got it working.

For an unrelated project I wanted to use the OpenWeatherMap setup I have to improve the daily weather forecast with icons.

The binding provices ids for the current weather condition and the current weather icon. That can be used to load the icon from the OWM website. Went to my setup and added two new Items:

String	homeCurrentConditionID	"Current condition ID [%s]"	{ channel="openweathermap:weather-and-forecast:home:current#condition-id" }
String	homeCurrentIconID	"Current icon ID [%s]"		{ channel="openweathermap:weather-and-forecast:home:current#icon-id" }

Used Ansible to deploy everything to the Raspberry running openHAB. And then wondered because only the "homeCurrentConditionID" item came online, not the "homeCurrentIconID". After searching around and browsing the community forum, it turns out that the "icon-id" channel is new in 2.5, and will not automatically installed if the OpenWeatherMap binding was already used in 2.4. WT* ...

One has to remove all the OWM things ("openweathermap:weather-api:home" and "openweathermap:weather-and-forecast:home") and reinstall everything, in order to get the new channels working. That is really unexpected, and not user friendly.

After mumbling a while over my options I went ahead, created a new backup, and then removed the two items. One did get stuck along the way, a long Java trace appeared in the logfile, and I had to force remove it. Then - for good measueres - I also uninstalled the binding, and restarted openHAB.

Afterwards I re-deployed my Ansible Playbook, which installs the binding, takes care of the binding configuration, and adds the Things again. After everything came online, the homeCurrentIconID Item is also populated. Why is everything in openHAB so complicated?