Simplest Wireguard Setup Ever

Wireguard - wired network pic by jordan-harrison-40XgDxBfYXM-unsplash-

Wireguard - wired network pic by jordan-harrison-40XgDxBfYXM-unsplash-

Wireguard

Wireguard is the newest way to setup a VPN for your home servers. What will this do for you ? It allows you to access your Raspberry Pi or other local servers located at home behind your router (or even your router itself) from outside your network by simply using a Wireguard client (either on a mobile phone or using a computer). You then access your local servers with the same ip addresses you do at home. For example, if my router is 192.168.1.1., I can be half way around the world and type in “192.168.1.1” and get my router control panel.

A recent podcast of Linux Unplugged “Back to the Freedom Dimension” had some really useful information on Wireguard and some interesting use cases. Paraphrasing one of the hosts, Wireguard is like having a very long ethernet cable into your home router.

The simplest method I have found to install Wireguard on Raspberry Pi is to use Docker following this post from The Digital Life.

Here is the somewhat modified docker compose file I use:

Wireguard Docker Compose file

Now it’s just a matter of typing “docker-compose up -d” and you have a running wireguard instance. Set up the clients as described in The Digital Life post.

Fix Your Smart Home – Stop Tasmota Devices From Switching Randomly

Lights Mysteriously Turning On ?

While working on fixing my KuLED light switches from magically but unexpectedly switching on, I found this great post and video from The Hookup regarding how to stop Wifi switches flashed with Tasmota open source firmware from seemingly being switched on by ghosts.

Me when my lights unexpectedly turned on at 2 AM in the morning.

MQTT Retain Settings

As Rob explains, most of the time this random switching is caused by MQTT retain commands that are not in sync between your hub (e.g., Home Assistant) and the Tasmota device.

A Ghostly Example

Rob gives a common example of the problem:

  1. Turn on your device using Home Assistant.
  2. Turn it off using the physical switch.
  3. Unplug the device, wait 10 seconds, and plug it back into the wall.
  4. Wait and see if the device turns back on.

I tried this on a Sonoff-modified desk lamp that was experiencing the random switching. After following the steps I re-plugged it into the wall, and after about 2 seconds it turned back on exhibiting this “ghostly” behavior.

Fix Your Retain Settings

The fix for 90% of cases is the following (for a detailed explanation and coverage of some specific use cases see The Hookup’s post)

    Change Retain to False in Your Home Assistant Configuration File

  1. Add “retain:false” to each of your Tasmota device switches in your Home Assistant configuration.yaml file.

    Change Retain Related Settings in the Tasmota Console of Each Device

  2. In your browser, navigate to the internal ip of your Tasmota device (e.g., 192.168.X.X, click on “Console”).

  3. Type in the following command (this is a one-line backlog command that combines the various commands that The Hookup provides):

    as shown below:

  4. Restart Home Assistant

  5. On one of my devices, I also had to delete the Tasmota device from my Home Assistant integration (Configuration->Integrations->Tasmota) before restarting Home Assistant.
  6. Delete Your MQTT Topics

    In addition to the above steps, I also had to use Mqtt Explorer (an excellent free MQTT client available in the Windows store) to delete the MQTT retain messages manually. Instead of hunting all the relevent topics down, I decided to delete ALL the MQTT topics held by the broker as all my devices will simply recreate them (your setup may be different or there might be historical data that you don’t want to lose so you may want to think a little before deleting all your topics).

    Without deleting the MQTT retain messages, my devices were turning OFF on a reconnect if the WiFi disconnected. If you watch Rob’s video he explains how the broker will keep MQTT retain messages forever unless they are manually deleted. The switchretain/buttonretain Tasmota commands in the second step above are intended to do that but they didn’t work for my KULED switches.

If the above doesn’t work for you, you probably have an incorrect value in one of your Tasmota settings. Try setting the Tasmota device back to its defaults and then configure your Tasmota from scratch. Then try the above again.

Using WP-CLI to Access MySQL Running in A LAMP Docker Container

WP-CLI is a great command line tool to help you manage WordPress.

I had trouble figuring out how to use WP-CLI to access a MySQL database that was running in a Docker container. I’m running a Docker LAMP instance locally using this set of Docker and Docker-Compose files from sprintcube.

The MySQL instance holding my local WordPress database is running in a Docker container. However, my WordPress core files are located located in a directory on the host’s physical hard drive defined as a Docker volume.

The trick is defining your DB_HOST environment value to be the IP address of your MySQL Docker container. You can do this either explicitly by the command line or in your WP configuration files (for a typical install in your wp-config.php file, in a bedrock install in your .env files).

Getting the IP Address of the MySQL Docker Container

You can find the IP address of your docker container by executing the following command:

Get your container name:

From this, I see that the Mysql container name is “lamp-database”.

d

Define DB_HOST Environmental Variable

Execute the following command substituting CONTAINER-NAME with your database container:

Define the Path to Your WordPress Install in Your WP-CLI Configuration Files

Create wp-cli.yml file in the directory you will be using WP or, alternatively create ~/.wp-cli/config.yml

The local alias should point to the WordPress file on your Docker volume as shown in this example:

To backup your WordPress database just type:

Note that this method is intended to be used for a LAMP Docker install with the WordPress files being simply installed in the document root kept in a defined volume on the host’s physical drive and WP-CLI installed on the physical docker host.

If you are using a WordPress container to run WordPress and/or WP-CLI, then you most likely want to use the ssh tag in wp-cli.yml. See the WP-CLI documentation regarding the ssh tag and brief discussion of the Docker scheme.