ads' corner

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?

Created a new Telegram Group for testing, and wanted to know the Group ID to send messages to the group using a bot.

One quick way (there are other ways as well):

• Go to: https://web.telegram.org/
• Login using your phone number
• Telegram sends you a confirmation code to your client on your mobile device
• Once you are logged in: click on the group
• The URL changes to something like: https://web.telegram.org/#/im?p=g1234567
• Pick the number after "p=g" (in this example: 1234567), and negate it (Group numbers in Telegram are negative)

The group number is: -1234567

As mentioned in my previous openHAB blog post: it seems to be too much to ask to have a reliable and working display in the kitchen.

Another problem I found is that the weather data occasionally does not update. Everything seems to work, no errors in the log, just no updated data. Of course this results in outdated weather info in the kitchen, and the threat that "someone" will buy a regular weather station and render my 7" Raspberry display useless.

After fighting with logs and debugging and not finding any real clue, I decided to tackle this problem from another angle, and regularly check if the weather data is up to date.

Another Ansible upgrade, another Playbook failing.

I have a number Playbooks which run on virtual machines. Some tasks are "outsourced" to the physical machine where the VM is running on, using "delegate_to". One of the tasks (which I haven't used in a while, because I rarely touch this machine) stopped working, and instead throws a "variable undefined" error. But from the beginning, here is the VM Playbook:

- block:
  - include: server-part.yml
  delegate_to: "{{ ansible_host }}"
  delegate_facts: True

That's the short form of it, and the $ansible_host variable holds the physical server address. That part is working. In "server-part.yml" I have the following:

# re-do the gather_facts task for the host
- action: setup

- name: Determine network interface name
  set_fact:
    main_interface: "{{ item }}"
  with_items:
    "{{ hostvars[physicalhost]['ansible_interfaces'] }}"
  when: item is match("^e[tn]")
  changed_when: false

- name: Verify interface name is set
  fail:
    msg: "Could not determine network interface name!"
  when: main_interface is not defined

The only physical network interface in this server is "eth0", that's still the case. There are a couple reasons why I still scan the list of interfaces, instead of just depending on "eth0". The main reason however is that this part also works with the enumeration systemd is doing with network interfaces (they have "en" names, instead of "eth"). But suddenly $main_interface in the next step is no longer defined.

Digging deeper (aka: -vvvv) it shows that Ansible is setting the correct interface name in the "set_fact" task, but then the variable is no longer defined immediately after that. What? I'm not sure I had to use this Playbook since my host was upgraded to Ansible 2.8.3, but I couldn't find any issues matching this problem either.

Don't you love it when things suddenly stop working?

In my openHAB installation I have a check which verifies that the weather data is up to date. Otherwise it restarts the openhab2 service. And this check stopped working ... Leaving the kitchen display not updated for a longer time. The same display where I expect the entire installation to "just work", and don't create so many different problems. Seems to be a hard problem to have an openHAB installation without any trouble ...

openHAB is a stream of pure joy when it comes to debugging. Especially when all I want is a small display in the kitchen, working autonomous and without the need to restart it all the time or login to fix issues.

The latest installment of that endeavor was a black screen in the browser, with no way to even get to the usual HABpanel controls. After some debugging, it turns out that the file "habpanel.config" (/var/lib/openhab2/config/org/openhab/habpanel.config) on the openHAB server was destroyed, or more accurate: shortened to 4829 bytes. Lucky me I have this file in my Ansible playbooks, and whenever there is a change, a copy of this file is fetched to my Ansible host. From there it goes into my backups, and I can restore a couple dozen versions back, if needed. So not all is bad, but still something is not working as expected. First I installed a copy of this file from my backups - but turns out shortly later the file is shortened again. Later I figured that the file is always shortened when the openHAB service restarts. This particular instance was still running openHAB 2.4, and I used this opportunity to upgrade to 2.5, test my Playbooks (and exclude the one config file from everything) and see if the problem persists. It does. Except that after upgrading to 2.5 the file is no longer shortened to 4829 bytes, but to 4875 bytes.

Every time that happens, the file ends somewhere in the middle of the HABpanel panel configuration - and naturally the HABpanel service can no longer read that file and shows a blank screen. I would wish that it rather shows an error message, or does something useful here, but oh well.

For a while (and mostly because I was busy with other tasks) I helped myself by changing the owner of "habpanel.config" and the directory this files lives in to "root:root". This threw a couple other errors into the logfile, but helped somewhat because the config file got no longer destroyed when the service restarted.