Connected mousetrap

Bothered by mice living in our attic, we have set up simple mousetraps and caught multiple mice every winter. This has spawned two problems based on mousetraps not being checked systematically or frequently:

  1. In some cases a mouse has been caught and left for weeks or even months unnoticed. This is a quite undesired discovery when finally checking.
  2. In other cases a mouse has successfully eaten the bait without having been caught. This has (also) left the mousetrap out of function for longer periods.

To accommodate both problems and optimize the “mousetrap operational uptime” I wanted/needed a connected mousetrap. I researched online, but was not able to find any attractive solutions. After complaining about this at a Christmas party, a friend of mine, Thomas Jørgensen, came to the rescue with a custom-made hardware solution.

Hardware and configuration

It is based on a microcontroller connected to a HAT on a Raspberry Pi Zero WH which acts as a gateway for this custom long-range RF communication:

The sensor will register any movement. So I just let it touch my old-fashioned mousetrap, and when the trap is moving, the sensor will be triggered and send a small packet to the Raspberry Pi Zero WH.

The Pi will listen to serial communication with a small Python script and receive a small JSON payload from the microcontroller:

	"sensortype": "mousetrap",
	"messageid": "10",
	"guid": "0x00000001",
	"seq": "27",
	"status": "0x01",
	"mousecount": "134",
	"batteryvoltage": "304",
	"temperature": "20",
	"rssi": "-57",
	"snr": "11",
	"freq": "868900",
	"freq_error": "-1246",
	"sf": "10",
	"bw": "125"

The script will parse this and use MQTT to inform openHAB about any state changes for mousetrap triggered, temperature and battery voltage (converted to approximate level in percent). Every seven hours a payload will be sent even if sensor wasn’t triggered. This is quite battery-optimized and also makes it possible to monitor if it’s operating correctly, temperature and remaining battery life.


Rules implemented in openHAB makes sure I get notifications when:

  • The mousetrap has been triggered (on cellphone and TV).
    • On cellphone a picture will be included (from a Hikvision surveillance camera).
  • It has been more than sevens hours since last payload was received.
  • When payload has been received again after previously missing.
  • When battery is low.

A notification could look like this:

Power consumption

The Raspberry Pi Zero WH with HAT uses ~0.6 W in this configuration. It’s connected through Wi-Fi, not Ethernet.


I started using this setup in October 2020. Since then caught 3-4 mice and quickly reloaded traps at least as many times without a successful hit. The last part is important as this increases the chance of actually catching the small rodents when traps are always operational and loaded with bait.

Denon receiver plugin for Yatse

I probably made my most niche thing ever today: A plugin for an Android app. I found out yesterday that a new API for Yatse was made available, so today I took on the challenge, and created a plugin for my Denon A/V receiver. I can now control the volume on my receiver directly from Yatse. In a few days I might clean the code up and finish it, so it can be released either here or on Google Play.

Update, August 8th 2015: I’ve just released the plugin!
Get it on Google Play.

Raspbmc and NFS permissions

NFS is often used for accessing network shares from Raspbmc, due to its low overhead. Many tutorials describe how to set this up, for example with a Synology NAS. One subject isn’t covered much, though: A setup with restrictive permissions.

On my Synology my media files are usually owned by me, and has ‘dlna’ as group with read-only permissions. Example:

drwxr-x---  9 jacob dlna   4096 Jun 15  2012 video

On the NAS I have created a user for Raspbmc and made it a member of this group:

DiskStation> cat /etc/group | grep dlna
DiskStation> cat /etc/passwd | grep raspbmc
raspbmc:x:1046:100:Raspberry Pie XBMC:/var/services/homes/raspbmc:/sbin/nologin

To get this to work on the Raspberry I’ve first had to synchronize the GID/UID’s. Since the NAS is the master, I’ve done this on the Raspberry (logged in as the pi user):

pi@raspbmc:~$ sudo groupadd -g 65536 dlna
pi@raspbmc:~$ sudo usermod -a -G dlna pi

After enabling root access, I’ve changed the pi user to match the UID of the raspbmc user on the NAS:

root@raspbmc:~# usermod -u 1046 pi

(For this to work I had to kill a number of processes first)

Changing UID of the pi user will cause a lot of trouble for Raspbmc, which expects the user to have UID 1000. This is hardcoded in at least two scripts:

  • /opt/xbmc-bcm/xbmc-bin/share/xbmc/addons/script.raspbmc.settings/
  • /opt/xbmc-bcm/xbmc-bin/share/xbmc/addons/script.raspbmc.settings/

Fix this by adding:

sed -i 's/getpwuid(1000)/getpwuid(1046)/g' /opt/xbmc-bcm/xbmc-bin/share/xbmc/addons/script.raspbmc.settings/
sed -i 's/getpwuid(1000)/getpwuid(1046)/g' /opt/xbmc-bcm/xbmc-bin/share/xbmc/addons/script.raspbmc.settings/

to /etc/rc.local so the scripts are automatically fixed during startup. Replace 1046 with your pi UID.

Without this fix automatic updates won’t work, and you’ll see script errors during startup – and can’t launch the Raspbmc settings.

Playing multi-channel FLAC’s on Raspbmc

About a year ago I bought a Raspberry Pi and installed Raspbmc. I wanted to use this cheap little gadget as a media center, filling some of the holes in my existing home entertainment setup. One of the things I was hoping to get out of it was the ability to play multi-channel (5.1) FLAC’s through HDMI to my surround receiver. However, I never got this to work. The same goes for the primary goal – being able to playback my DVD collection from ISO files, but that’s another story…

The setup:

  1. The FLAC’s are 24 bit with a sample rate of 96 kHz.
  2. I’m using NFS for efficient file transfer from my NAS.
  3. The average bitrate for the files is below 10 Mbps.

Raspbmc will try to play the files, but immediately chokes or freezes. I’m ruling out network limitations, since the Pi is wired and able to stream 1080p video at higher bitrates. I had completely given up, thinking it was a shortcoming of Raspbmc itself, when I suddenly, by coincidence, discovered that one of my albums played perfectly. So I started investigating the difference between this album and the all the others that didn’t work. The difference was the bitrate, which was only 48 kHz for the working album.

The next step was to downsample a song from 96 kHz to 48 kHz – and this turned out good as well. So now I’ve downsampled all my albums, and can play them all on the Pi. A bit of research led me to SoX, one of the best free tools for downsampling audio — amongst a lot of other things. I use it like this:

sox -S orig96.flac -r 48000 -b 24 conv48.flac

I had to compile it myself, because the version included in my CentOS installation didn’t support FLAC. This was completely straight-forward (configure, make, make install), probably because I already had libFLAC installed. The only think I’m unsure about is if I’ve missed some option to get the best quality downsampling.