I’m about to try an update of my existing OpenHAB installation. Right now I’ve got a few things in a working state and in case I destroy anything I want to have a working backup.
Luckily, there’s an integrated backup script on my 2.4.0 installation I can use. I just need to install the zip package first on my Raspbian using
sudo apt-get install zip
Now I can run a backup using
openHAB 2.x.x backup script
Using '/etc/openhab2' as conf folder...
Using '/var/lib/openhab2' as userdata folder...
Using '/usr/share/openhab2/runtime' as runtime folder...
Using '/var/lib/openhab2/backups' as backup folder...
Writing to '/var/lib/openhab2/backups/openhab2-backup-19_11_21-19_24_30.zip'...
Making Temporary Directory if it is not already there
Using /tmp/openhab2/backup as TempDir
Copying configuration to temporary folder...
Removing unnecessary files...
Backup Directory is inside userdata, not including in this backup!
Removing temporary files...
Success! Backup made in /var/lib/openhab2/backups/openhab2-backup-19_11_21-19_24_30.zip
The backup includes the installed plugins as well as the used configuration. Quite easy and fun to use!
I’ve tinkered before with my Xiaomi Robot Vacuum but returned to the official Xiaomi app since the existing solutions felt uncomfortable. I even worked on adding Mac support for the dustcloud software but stopped using the rooted firmware.
A few days ago I’ve read about Valetudo. Valetudo is a web interface to the Xiaomi robot being self hosted on the robot. It allows easy extraction of the necessary control token and stops the robot from reporting cleaning and location data to Xiaomi. There’s also support for MQTT so that you can integrate it into existing home automation systems.
I followed the instructions on creating a rooted firmware and found a few problems and want to share my solution:
The firmware builder creates a firmware package along with SSH keys supplied during the build process. I could not login using those SSH keys and required the SSH key directly from the ~/.ssh folder of the user.
Flashing inside a VirtualBox Ubuntu VM doesn’t work, even when you use a bridged network interface. You maybe able to request the device token but the flash command always fail.
Flashing the robot may fail, if it isn’t completely reset to its default. You can reset the robot to factory default by pressing the home and reset button until you hear the chinese voice.
You should flash the robot while it is inside its charging station.
If you’re using a Mac, you can install python3 and the required python packages. This will allow you to flash the firmware directly from your mac.
Keep your machine close to the robot during the flashing process, because it might otherwise timeout.
Since I’m using a chinese version of the robot, I only hear the chinese voice. In this case you’ll need to convert the robot to a european version following these instructions. Once the robot is rebooted you’ll hear the english translation and can verify this from the Valetudo interface.
Now you’re ready to use Valetudo. I’ve added a link to the Valetudo homepage on my smartphone. It replaces now the Xiaomi app while it still provides access to the cleaning map, the maintenance hours for replacing parts as well as automated clean up plans. All in all its a really nice piece of software!
I’ve recently stumbled over an article in the german magazine C’T about visualisations of your Fritz!Box’s connection. The solution looked quite boring and outdated, since it used MRTG for the graph creation.
I’ve started searching for a better solution using Grafana, InfluxDB and my Raspberry Pi and found this great blog post. I’ve already explained how to install Grafana and InfluxDB in this post, so I’ll concentrate on the Fritz!Box related parts:
Start with the installation of fritzcollectd. It is a plugin for collectd.
Now create a user account in the Fritz!Box for collectd. Go to System, Fritz!Box-user and create a new user with password, who has access from internet disabled. The important part is to enable „Fritz!Box settings“.
Additionally make sure that your Fritz!Box is configured to support connection queries using UPnP. You can configure this under „Home Network > Network > Networksettings“. Select „Allow access for applications“ as well as „Statusinformation using UPnP“.
Next part is the installation and configuration of collectd:
Login to your grafana installation and configure a new datasource. Make sure to set the collectd database. If you’re using credentials for the InfluxDB, you can add them now. If you’re not using authentication you can disable the „With credentials“ checkbox.
Check if your configuration is working by clicking on „Save & Test“.
If everything worked, you can proceed to importing the Fritz!Box Dashboard from the Grafana.com dashboard. The ID is 713. Make sure to select the right InfluxDB during the import setup.
After clicking on import, you’ll should be able to see your new Dashboard. It might take a few minutes/hours until you’ve gathered enough data to properly display graphs.
Be aware though that if you start gathering this much data you’ll might end up with „insufficient memory“ errors. You’ll might want to tweak your InfluxDB settings accordingly.
A few days ago I’ve noticed that my influxdb installation wasn’t working properly. The server was crashing constantly.
I’ve checked the logs using
sudo journalctl -u influxdb -b
and found this
May 12 23:12:18 pi3plus influxd: ts=2019-05-12T21:12:18.440902Z lvl=info msg="Opened file" log_id=0FNU47~W000 engine=tsm1 service=filestore path=/mnt/databases/influxdb/data/_internal/monitor/342/000000020-000000002.tsm id=0 duration=14
May 12 23:12:18 pi3plus influxd: runtime: out of memory: cannot allocate 2121015296-byte block (16056320 in use)
May 12 23:12:18 pi3plus influxd: fatal error: out of memory
May 12 23:12:18 pi3plus influxd: runtime stack:
May 12 23:12:18 pi3plus influxd: runtime.throw(0xbc70be, 0xd)
May 12 23:12:18 pi3plus influxd: /usr/local/go/src/runtime/panic.go:608 +0x5c
May 12 23:12:18 pi3plus influxd: runtime.largeAlloc(0x7e6c15dd, 0x60101, 0x76f91a20)
May 12 23:12:18 pi3plus influxd: /usr/local/go/src/runtime/malloc.go:1021 +0x120
May 12 23:12:18 pi3plus influxd: runtime.mallocgc.func1()
May 12 23:12:18 pi3plus influxd: /usr/local/go/src/runtime/malloc.go:914 +0x38
May 12 23:12:18 pi3plus influxd: runtime.systemstack(0x1c4e3c0)
May 12 23:12:18 pi3plus influxd: /usr/local/go/src/runtime/asm_arm.s:354 +0x84
May 12 23:12:18 pi3plus influxd: runtime.mstart()
May 12 23:12:18 pi3plus influxd: /usr/local/go/src/runtime/proc.go:1229
May 12 23:12:18 pi3plus influxd: goroutine 27 [running]:
May 12 23:12:18 pi3plus influxd: runtime.systemstack_switch()
May 12 23:12:18 pi3plus systemd: influxdb.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
May 12 23:12:18 pi3plus systemd: influxdb.service: Unit entered failed state.
May 12 23:12:18 pi3plus systemd: influxdb.service: Failed with result 'exit-code'.
This happened because I’ve recently added statistics from my FritzBox with regards to my DSL line speed. The statistics have a high cadence, which means that many entries are created in influxdb in a short amount of time. Influxdb tries to create an index in RAM for these entries and is overwhelmed by the mass of data.