The simplest way to back up my Mastodon and Matrix servers, which run in a separate LXCs, was to set up snapshot-type backups on the Proxmox datacenter level and be happy, but snapshotting the database files is not the right way. You can catch your Postgres in the middle of the transaction and leave it corrupted after the restore. The right way was to make a dump of the databases, for example, with pg_dump, because "It generates a consistent snapshot of the database at the time the command is executed, even if the database is being used concurrently, without blocking other users."

But what about the other files? Configuration files, secrets, media storage? Sure, we can rsync them off the server along with the database dump and be happy, but what about backup versioning, retention, and deduplication? As I already had a Proxmox Backup Server to handle those, my plan for backing up a server was simple:

1. Make a database dump to the file system of the server
2. Make a snapshot-type backup of the server to the PBS

This way, I'd have consistent daily backups with a database dump and all needed files. And the restore procedure would consist of the same two steps, but in reverse:

1. Restore the server from PBS
2. Restore the database from the dump on the server's file system

I'm not claiming to be an inventor of something new; I just think it is a good way. Loosing or corrupting several media files during this process is far less critical as missing database records or ending up with a corrupted database.

So I ended up with two separate tools to make a backup. First is a pg_dump CLI tool on the server, and the second one is a Proxmox Node to perform an LXC backup. Syncing those two, relying only on the time and delays, felt like a bad idea, so I decided to use Ansible from another Proxmox LXC to connect to my servers, make a database dump, and trigger a Proxmox backup job.

Tailscale SSH​

To make that work, I needed an SSH connection between my "guard" server with Ansible running and the other two servers to back up. Sure, I could generate new SSH keys, make an exchange, but I already had Tailscale on my Proxmox guests, so why not use Tailscale SSH for that?

The hardest part of Tailscale SSH configuration is to configure access rules, because Tailscale SSH between Tailscale devices is disabled by default. To enable it, I created two ACL tags in Tailscale:

1. "ansible-control-node" to assign to the "guard" server
2. "ansible-managed-node" to assign to the Matrix and Mastodon servers

Then, in the Tailscale Access Control, I just created a new rule for Tailscale SSH to allow SSH connection from "ansible-control-node" to "ansible-managed-node".

Playbook​

On the "ansible-control-node", I installed Ansible Core 2.19 (at the moment of writing), created a playbook.yaml and an inventory.yaml.

After some research and documentation reading, my playbook.yaml ended up with two plays.

Database dump​

- name: Database dumps
  hosts: postgres
  remote_user: root

  tasks:
    - name: Dump all databases
      ansible.builtin.command: pg_dumpall -c -f /var/lib/postgresql/db_dump_all.sql
      become_user: postgres
      become: true

hosts here is a group containing servers with installed PostgreSQL.

I used the ansible.builtin.command task to create a dump of all databases on the server to a file, becoming a postgres user. This system user is created by default in Ubuntu or Debian when installing Postgres from the apt repository.

Proxmox backup​

- name: Backup Proxmox nodes
  hosts: localhost

  tasks:
    - name: Backup matrix and mastodon node
      community.proxmox.proxmox_backup:
        api_user: ansible@pve
        api_password: ***************
        api_host: ***.***.***.***
        storage: pbs # PBS storage ID
        backup_mode: snapshot
        retention: keep-monthly=6, keep-weekly=4, keep-daily=7
        mode: include
        wait: true
        wait_timeout: 240 # Wait fro x seconds before throwing a timeout error
        vmids: ## Proxmo guest IDs to backup
          - 109
          - 111

hosts here is a localhost because we will trigger the Proxmox backup job through the Proxmox API.

I created a separate user for this task on my Proxmox VE, giving him the VM.Backup role for selected guests and Datastore.Allocate plus Datastore.AllocateSpace for the PBS storage.

Schedule​

The last step was to run this playbook daily. I used a cron job. As the path to apps installed with Python was added to the PATH environment variable through the .bashrc, it is not available for the crontab, so I used a full path to the ansible-playbook. Use whereis ansible-playbook to get the full path.

0 1 * * *  /root/.local/bin/ansible-playbook /root/ansible/playbook.yaml -i /root/ansible/inventory.yaml > /var/log/backups.log 2>&1

This job will be executed every day at 01:00 and write the result of the execution to /var/log/backups.log. The log file will be rewritten in this case. If you want to append the log on each job execution, change > /var/log/backups.log to >> /var/log/backups.log.

I already had the Synapse Matrix server hosted in my personal domain. And I thought that it was stable enough for me to allow other users to register. With registration tokens, I'll provide, of course. But my personal domain represents a part of my second name. "Who wants a Matrix account in the domain that represents a part of someone's second name?" - I thought.

That's how my Matrix server has migrated to a newly purchased glitchy.social domain. Actually, that was not a migration, but rather starting from scratch. I dropped the database of Synapse and Matrix Authentication Service, changed the homeserver name in all configs, and started fresh.

You can chat with me now at @yehor:glitchy.social.

Then I started to think about how people will know how to join. Or even will know about Glitchy.Social itself? "I need a landing page. Or a website!" - I concluded.

yevi.org is a Dcusaurus-powered website. And I really like its flexibility. It is as simple as adding or editing markdown files, but at the same time, you can write your own JavaScript components using ReactJS. Isn't it cool?

So I present you today a shiny result of a one-night work: www.glithcy.social!

"Hey! That's a nice logo you have there," you'll suddenly exclaim, at least in my head. And I appreciate that reaction, because it is not an AI-generated slop. It is several hours of Inkscape with two project managers beside me: my wife and my daughter. I think they are still unsatisfied with my work, but we will improve it someday. For now, it is done, and it is nice in my opinion.

The font is Cal Sans by Mark Davis, and the glitch effect is inspired by a guide from Nick Saporito.

There is some info on the Matrix server on the website, primarily on how to request a registration token. Also, the Terms of Service, which I wrote by myself, felt disgusted, then asked AI for help, felt disgusted again, combined those two disgusting pieces of human and machine minds, and now you are forced to read it before joining. Sorry about that.

This is how it started, and I'm going to deploy a Mastodon instance in that nice domain as well. Maybe other services later, who knows.

I want to warn that this is not a full step-by-step guide. It is rather notes on the process and steps I followed.

Installation​

There is documentation on the installation process at Hetzner. There are options, and I chose the first one - installing Proxmox VE on Debian. So, according to the docs, I booted a Rescue System and installed Debian with the installimage. Then I followed the guide from Proxmox Wiki to install Proxmox VE. There is a step where you first install a new kernel and reboot to activate it. I was forced to reboot the server twice to make it appear online again. Have no idea why.

Network​

Now to the hard part. The initial plan was to have all LXCs in a single local network to allow internal communication. Also, the host and some containers should have public IPs for external access.

I reviewed a lot of network configuration options around the internet and chose a bridged setup with masquerading (NAT).

For the network I edited /etc/network/interfaces like this:

auto lo

iface lo inet loopback

iface lo inet6 loopback

iface enp5s0 inet manual

iface enp5s0 inet6 manual

auto vmbr0
iface vmbr0 inet static
        address <Public IPv4>/26
        gateway <Public IPv4 gateway>
        pointopoint <Public IPv4 gateway>
        bridge-ports enp5s0
        bridge-stp off
        bridge-fd 0
        up route add -net <Public IPv4 gateway - 1> netmask 255.255.255.192 gw <Public IPv4 gateway> dev vmbr0
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
        post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp -d <Public IPv4> --dport 21074 -j DNAT --to 192.168.50.3
        post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp -d <Public IPv4> --dport 21074 -j DNAT --to 192.168.50.3

iface vmbr0 inet6 static
        address <Public IPv6>/64
        gateway <Public IPv6 gateway>

auto vmbr1
iface vmbr1 inet static
        address 192.168.50.1/24
        netmask  255.255.255.0
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
        post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1
        post-up iptables -t nat -A POSTROUTING -s '192.168.50.0/24' -o vmbr0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '192.168.50.0/24' -o vmbr0 -j MASQUERADE

Let's see what's going on in here.

For the containers that don't require a public IP, I choose vbmr1 bridge, set some IP from the local IP range (192.168.50.x), and use host local IP as a gateway:

For LXCs that require a separate public IP, I choose the vmbr0 bridge, set the IP, gateway, and MAC address provided by Hetzner.

The route with the <Public IPv4 gateway - 1> is a route from the official Hetzner docs. That doc was updated while I was writing this post, and the line was removed from the example network configuration there. Some network configuration guides across the internet still have it, so I'm leaving it as is for now. If your public IP gateway is, for example, 67.11.34.23, the route will be

up route add -net 67.11.34.22 netmask 255.255.255.192 gw 67.11.34.23 dev vmbr0

The next lines enable IP forwarding across networks:

post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

And here is an example of forwarding a port 21074 from the public IP to the local IP of a single LXC:

post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp -d <Public IPv4> --dport 21074 -j DNAT --to 192.168.50.3
post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp -d <Public IPv4> --dport 21074 -j DNAT --to 192.168.50.3

For the local network vmbr1 the next lines are needed to make Proxmox Firewall work properly:

post-up   iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1
post-down iptables -t raw -D PREROUTING -i fwbr+ -j CT --zone 1

Network security​

Ports 8006, 22, and 8007 are opened on the Proxmox host in the Proxmox firewall, but explicitly closed in the Hetzner firewall. That way, I can use Proxmox VE and PBS web UI only from the Tailscale network, but, in case of an emergency or misconfiguration, I can open critical ports in Hetzner firewall to get access using server's public IP.

Public Reverse Proxy​

I know it is not the best practice to install anything directly on a Proxmox host, but this looks like a perfect decision, as it already has a public IP address, and I can't unassign it because this is the only way to access the server in case of failure. So I decided to install Caddy directly to a Proxmox Host and open ports 80 and 443 to it. Caddy handles requests and then proxies them to the local IPs of LXCs:

git.nicelycomposed.codes {
        reverse_proxy 192.168.50.3:3000
}

Tailscale and Internal Reverse Proxy​

They call it "bastion host". A single point of connecting to your internal resources that you don't want to expose publicly. I have an LXC for this with Tailscale and another instance of Caddy installed. Let's see how it works on an example.

I want to securely connect to the Proxmox VE web UI using a valid SSL certificate at https://pve.int.example.com.

First, to make Tailscale work inside an LXC, additional configuration should be made on the Proxmox host. LXC configuration file can be found at /etc/pve/lxc/<CT_ID>.conf. Those two lines should be added to the file:

lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file

Then just restart the LXC.

Then, I installed Tailscale and Caddy on my "bastion host". Then I created a DNS record to point pve.int.example.com to an IP address of my bastion host in the Tailscale network:

A      pve.int.example.com      10.11.12.13

Then, in the Caddy config, I proxied pve.int.example.com to the local IP of my Proxmox host and port 8006, using HTTPS and skipping TLS verification because of Proxmox's default self-signed certificate:

pve.int.example.com {
        reverse_proxy 192.168.50.1:8006 {
                transport http {
                        tls
                        tls_insecure_skip_verify
                }
        }
}

Now I'm able to point my browser to https://pve.int.example.com while connected to my Tailscale network.

I can add other internal resources hosted on other LXCs in the same way:

dockge.int.example.com {
        reverse_proxy 192.168.50.4:5000
}

element-admin.int.example.com {
        reverse_proxy 192.168.50.8:8080
}

Proxmox Backup Server​

It was the simplest part. I know this is not the most recommended method, but my Proxmox Backup Server is installed on the Proxmox VE host. After installing it and configuring it to use Backblaze S3 storage, I just added it as a storage to Proxmox VE using the local IP of the host.

Conclusion​

Have no idea why everyone wants to write a conclusion for each post nowadays. It looks like a forced conclusion to a school physics problem in most cases: "Solving this problem of moving trains, we found out that trains can move".

Have a nice tinkering.

The victim​

First of all, even after enabling "Wake up on PCI event" or something in BIOS it was not working because WoL was still disabled on a software level. It can be checked with:

ethtool enp1s0

Where enp1s0 is a physical network interface of a Proxmox node, not a bridge.

There should be Wake-on: setting among others. In my case it was Wake-on: d, which means that wake-on-LAN is disabled, according to ethtool documentation:

p  Wake on phy activity
u  Wake on unicast messages
m  Wake on multicast messages
b  Wake on broadcast messages
a  Wake on ARP
g  Wake on MagicPacket(tm)
s  Enable SecureOn(tm) password for MagicPacket(tm)
d  Disable (wake on nothing).  This option clears  all  previous
    options.

We need to set it to wake by the MagicPacket(tm).

for Proxmox 8 or older​

We need to create a config file for this to be enabled on system start. But first we need to:

ip link show enp1s0

and write down our network device MAC address. Then create a file:

nano /etc/systemd/network/90-wakeonlan.link

with the next content:

[Match]
MACAddress=<mac-address-here>

[Link]
NamePolicy=kernel database onboard slot path
MACAddressPolicy=persistent
WakeOnLan=magic

for Proxmox 9​

We need to create a systemd service that will be launched on system start and change the WOL setting with ethtool.

Create a file:

nano /etc/systemd/system/wol.service

with the next content:

[Unit]
Description=Enable Wake On Lan

[Service]
Type=oneshot
ExecStart=/usr/sbin/ethtool --change enp1s0 wol g

[Install]
WantedBy=multi-user.target

changing enp1s0 to your interface name. Enable the service:

systemctl daemon-reload && systemctl enable wol.service

then​

After that we need to reboot and check WOL status again:

ethtool enp1s0

Now Wake-on should be set to g.

The one who bothering​

On another node we need to install an util that will be sending a magic packet:

apt update
apt install etherwake

Now we can power the victim off and try to wake it with:

etherwake -i vmbr0 <mac_address>

Where vmbr0 is a bridge network interface of current Proxmox node, and <mac_address> is a MAC address of the victim's physical network interface.

If it works, we can now add a cron job to wake our victim upon current node startup, adding some delay to make sure the network is ready:

crontab -e

Cron job line to add:

@reboot sleep 30s && /usr/sbin/etherwake -i vmbr0 <mac_address>

So first of all I went to Settings -> VPN on my UniFi Cloud Gateway Ultra, switched to a VPN Server tab, and added a new Wireguard VPN server. I let UniFi decide on the client's IP range.

Then I added a client, which will be my VPS. And downloaded a WireGuard interface config file there:

Then I connected to my VPS through SSH to make some Linux command line magic.

On my VPS I have Ubuntu 24.04 installed.

So, to the command line. Install WireGuard:

sudo apt install wireguard

Create a config file:

sudo nano /etc/wireguard/wg0.conf

Insert the configuration downloaded from the UniFi VPN client creation step:

[Interface]
PrivateKey = ***************************************
Address = 192.168.4.2/32
DNS = 192.168.4.1

[Peer]
PublicKey = ***************************************
AllowedIPs = 0.0.0.0/0
Endpoint = ***.***.**.**:51821

Now edit it to look like this:

[Interface]
PrivateKey = ***************************************
Address = 192.168.4.2/32
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820

[Peer]
PublicKey = ***************************************
AllowedIPs = 192.168.4.0/24,192.168.50.0/24,192.168.1.0/24
Endpoint = ***.***.**.**:51821
PersistentKeepalive = 10

PostUp and PostDown are commands to be executed when the WireGuard network interface connects or disconnects. In my case, this is to add and remove iptables rules for WireGuard traffic routing through the default network interface.

AllowedIPs should be edited to your needs. Here is my needs:

• 192.168.4.0/24 allows access to any IP address on the same subnet as the VPS would be placed after connecting
• 192.168.50.0/24 allows access to any IP on my other subnet
• 192.168.1.0/24 allows access to any IP on my main subnet (I'm not sure about this, but anyway the access is blocked on the UniFi Firewall level)

These rules are loose because the Firewall on my UniFi Gateway blocks any cross-subnet traffic anyway allowing only limited communications.

This should be enough to bring the connection up with wg-quick:

sudo wg-quick up wg0

To see the status:

sudo wg show

And now to make it work through server reboots we need to down the interface:

sudo wg-quick down wg0

And up it back with a system service, also enabling it:

sudo systemctl start wg-quick@wg0 && sudo systemctl enable wg-quick@wg0

Further interface control should be performed through systemctl as well like systemctrl stop, systemctl restart or systemctl status.

There is a lot of automation you can do with this data, but today I want to write up a short guide on how to safely get the information from the UPS connected to your NAS via USB into the Home Assistant.

UPS server​

After connecting the UPS to the NAS we need to enable Synology NAS UPS server that will allow other machines to get UPS information over the local network. In your Synology DSM go to Control Panel -> Hardware & Power -> UPS tab. Here you can set up a UPS connected to your NAS via USB (or via SNMP protocol if you have enterprise-grade UPS for data centers). Assuming you did that, it is time to enable the UPS server by checking the "Enable network UPS server" checkbox.

Also, you need to click the "Permitted Synology NAS Devices" button and add your Home Assistant local IP address there:

After that, you need to make sure the port for the UPS server is open in the firewall on your NAS. Go to Control Panel -> Security -> Firewall tab and click the "Edit rules" button. Here you need to edit an existing rule for the TCP protocol that has a list of apps in the Ports column:

In the editing window click the Select button near "Select from a list of built-in applications" and make sure the UPS server is selected:

Home Assistant integration​

The integration that will allow us to connect to the UPS server on Synology NAS is Network UPS Tools.

In your Home Assistant go to Settings -> Devices & services and click the "Add integration" button. Search for "nut" there and choose "Network UPS Tools (NUT)".

In the configuration window that appeared you need to set your NAS's local IP address as a Host and leave the Port number unchanged.

Hit Submit and you are done.

We will use Proxmox VE API and Home Assistant RESTful Command integration for this.

Proxmox user and permissions​

Let's do things right and don't allow Home Assistant to log in with the root user to your Proxmox environment. We will create a role first. Go to your Datacenter view in Proxmox web UI choose Permissions -> Roles and hit Create.

We will create a PowerManager role with Sys.PowerMgmt privileges. This will allow our user to execute shutdown/restart commands through Proxmox API, but nothing more.

Next, we will create a user. In Proxmox web UI go to Permissions -> Users and hit Add. Give him a username and password, and choose "Proxmox VE authentication server" as a Realm:

Next, we will go to our Datacenter view in Proxmox web UI choose Permissions and hit Add. Here, we will set /nodes/<node_name> as the Path, select our newly created User and our newly created Role for him:

Lastly, we will need an API token to make API calls. For this, we will go to Permissions -> API Tokens and click Add. Choose our newly created user, give the token an ID, and disable Privilege Separation.

After clicking Add we will see the token. We need to write down the token ID and token itself to use it in Home Assistant later.

Home Assistant integration​

Now to the Home Assistant. We will need to edit our configuration.yaml file as currently, this is the only way to add RESTful Command integration. Here is an example:

rest_command:
  spacedock_one_shutdown:
    url: "https://192.168.99.3:8006/api2/json/nodes/spacedock-one/status"
    method: post
    headers:
      Authorization: PVEAPIToken=pwrmngr@pve!power=73892874-ad34-4b98-83e2-7be787f9bee3
    content_type: "application/x-www-form-urlencoded"
    payload: "command=shutdown"
    verify_ssl: false

The url should have the next format: https://<proxmox node IP>:8006/api2/json/nodes/<proxmox node name>/status.

The authorization header should have the next format: PVEAPIToken=<proxmox username>@pve!<API token ID>=<API token>

You can use shutdown or reboot as a command.

After restarting Home Assistant you will have a new service available. In our example, it would be rest_command.spacedock_one_shutdown. Calling it will do the trick.

It's been a long way to my current home lab configuration. There were several Intel NUCs, Nextcloud, and so on, but at the end (or just for now) I have Synology NAS and it allows me to host not only my personal cloud but other services as well. This blog is one of them.

RandomPlace blog is running in the Docker container. In Synology DSM it is a Container Manager package. To be honest, I'm not a big fan of the everything-in-containers approach. Bare-metal installation is much better in terms of maintainability and flexibility, but it is clear why Docker containers become so popular across our home labs. It is much easier to get something up and running with a single command instead of resolving dependencies and configuring your OS. So when this blog was hosted on Intel NUC with Ubuntu OS, it was not in containers. Now, with a new-for-me DSM software, it is easier to get something up and running with a single command instead of resolving dependencies and configuring my OS =)

I know there is a way to run NodeJS apps on Synology DSM, but this is something I need to discover. I'm also not sure I'm ready to SSH to my NAS and start to edit system files. Stability is the main reason why I'm currently with Synology.

Let's get back to our main topic. All further instructions are from DS423+ and DSM 7.2. But I'm sure it would be the same for many other NASes.

Prepare​

First of all, we will need a Container Manager package to be installed from the Package Center

Then we will need some folders to be created. After installing a Container Manager, you will have a new shared folder created for you: docker. A good place to put all your container's data in. We should create a new directory there with any name you want. For example blog. This would be the root of our future project. Then, let's create a content directory inside it:

Lastly, we will need to know the volume number where our directories are placed. For this open File Station, right-click on the docker folder and choose Properties. The Location property in my case tells me that the docker folder is placed on a volume1.

The Database​

The Ghost requires the MySQL database to work. For the database, we have two options. The first is to have a database as a separate docker container. This option is the simplest. Another one is to use the MariaDB Synology package to have a single database service for all your projects. This will require us to install the phpMyAdmin as well to create and manage databases and users. This option enables the ability for a simple database backup solution because the MariaDB package with all data and settings could be included in Hyper Backup. Also, we will avoid having several containers with the same database service in the future.

With the second option, after installing MariaDB and phpMyAdmin from the Package Center on our NAS, let's log in to phpMyAdmin with the root user and password we set upon installation and create a new database for our blog and name it, for example, "my_blog":

Now we will need to create a user for this database. Choose your newly created database on the left and navigate to the Privileges tab. You can find the "Add user account" link there.

Selecting "Any host" for the "Host name" field upon user creation will allow the Ghost container to connect to the database even from the bridged network. But also allows connection from any host within your local network (assuming that you didn't open MySQL port to the public internet which you shouldn't do in any case).

Don't forget to tick "Grant all privileges on database my_blog." on the same user creation page.

Hit Go in the bottom and we are done here.

Create​

Now the time has come to create a new project in Container Manager. Launch it, open the Projects view from the left, and hit the Create button.

Here we need to give our project a name, choose a previously created path for it, and provide a docker-compose.yml.

And here is our docker-compose.yml:

version: '3.1'

services:
  ghost:
    image: ghost:5.71.0 # Choose the version here: https://hub.docker.com/_/ghost/
    container_name: the_blog_ghost
    restart: unless-stopped
    ports:
      - 43332:2368 # Some random port mapped to a default Ghost port inside container
    volumes:
    # This is the path to our directory created at the beginning, mapped to a content directory inside the container
      - /volume1/docker/blog/content:/var/lib/ghost/content
    environment:
      database__client: mysql
      database__connection__host: 192.168.1.2 #This should be the local IP address of your NAS
      database__connection__user: blog_ghost #Database user we've created previously
      database__connection__password: '12345' #The strongest password you can imagine 
      database__connection__database: my_blog #Database name we've created previously
      url: https://blog.randomplace.online #Your future blog domain, you definitely already bought

The next step will allow us to create a web portal for our container on a port we mentioned in docker-compose.yml

We should accept this option and hit Next and then Done to start the container and navigate to a Web Station to configure a Web Portal:

Here we need to create a Name-based portal and use our domain as a Hostname. Also, we should force HTTPS (redirect all HTTP requests to a secure HTTPS connection) with the HSTS option:

The last thing we should do is generate a new SSL certificate to serve our blog through HTTPS.

Go to Control Panel - Security and choose the Certificate tab. Here we can request a new free SSL certificate by clicking the Add button and choosing "Add new certificate".

Then "Get a certificate from Let's Encrypt" and fill in some fields:

You'll get an email notification on the address added here when there will be time to renew your free certificate.

After certificate generation, we should open Settings on the same Certificates tab, find our domain service, and choose the newly generated certificate for it.

That's it!

Components used​

1. The housing from Broadling RM Pro+
2. Wemos D1 mini development board
3. Wemos IR shield
4. USB to micro-USB cable

Assembling​

First of all, we need to make our shield work with all transmitting LEDs and the pins we need. In this example, we will use D3 for sending and D4 for receiving.

Now lets put the board into the housing with cable connected and glue it all:

Then put the shield on top:

Finally, close the housing:

Using​

In ESPHome let’s create a config:

esphome:
  name: ir_receiver
  platform: ESP8266
  board: d1_mini

wifi:
  ssid: "WiFi"
  password: "************"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "IR Receiver"
    password: "************"

captive_portal:

# Enable logging
logger:
  level: DEBUG

# Enable Home Assistant API
api:
  password: "************"

ota:
  password: "************"

remote_receiver:
  pin:
    number: D4
    inverted: true
  dump:
    - samsung

As you can see it is set up to dump only Samsung-specific codes. You can read more about reading other codes on esphome.io. Also pay attention on logger section. It is set to DEBUG level.

Compile, flash, open logs and start firing into our device with your IR remote. You’ll see something like this:

[17:34:48][D][remote.samsung:055]: Received Samsung: data=0xE0E007F8
[17:34:51][D][remote.samsung:055]: Received Samsung: data=0xE0E020DF

You can now use this data with the ESPHome Remote Transmitter component to build, for example, something like this.

saw several solutions to this problem.

1. The easiest, but boring and expensive, is to purchase an improved model of my amplifier with IR remote control.
2. Сheap and the one that looks right is to add a digital potentiometer to the amplifier input and control it with Wemos D1 mini I already have in my amp.
3. Most inaccurate but fancy and the one you will use to impress your family and friends is to add a stepper motor that will rotate the knob for you.

I think you already guessed the way I choose, so let’s see how I achieved this.

Components​

As I already have Wemos D1 mini and a relay in my amplifier, you could see more components than you expect on photos, but, for simplicity, I’ll list only those components used to control the knob in this article.

1. WEMOS (LOLIN) D1 mini WiFi board (wemos.cc)
2. AC-DC 220V to 5V Step-Down Mini Power Supply (amazon)
3. ULN2003 stepper motor driver
4. 5V 28BYJ-48 stepper motor

Connections​

• 5V DC power from power supply, 5V pin of Wemos D1 mini and +5V input of motor driver are connected together.
• Ground of the power supply, GND pin of Wemos D1 mini and -5V (ground) of motor driver are also connected together.
• IN1 of motor driver -> D5 on Wemos
• IN2 of motor driver -> D6 on Wemos
• IN3 of motor driver -> D7 on Wemos
• IN4 of motor driver -> D8 on Wemos

Building​

The AC-DC power supply was connected to the AC power input of the amplifier.

Now to the knob. The knob actually rotates an analog potentiometer – a mechanical component with variable resistance. On my amplifier, all potentiometers have a hexagonal-shaped hole on the other side of the rotating element:

This made the connection of the motor as easy as a couple of rasp strokes. I mean the shaft of my motor was slightly bigger than the hole on the potentiometer so I took a rasp and made it smaller. Then I used a couple of plastic racks with nuts and a bunch of hot glue to anchor the motor on amp housing.

I know it is not the best binding but it works. I don’t think this solution is permanent because I relay want to use digital potentiometers instead. I made this more for fun, but currently, this is the only way to remotely control the volume in my living room. Just to give you an opportunity to change your mind before you start a similar project (or, who knows, maybe to improve it) here is a list of issues it currently has:

• It is impossible to determine the current motor position because its position resets on each boot.
• It is easy to brake reduction gears in motor and even the amp when rotating the potentiometer further than it could.
• It is hard to rotate the knob manually because you need to rotate the motor as well.

If you are still here lats go to the software part.

ESPHome​

ESPHome could rotate your stepper motors with Stepper Component. Here is my stepper config in ESPHome:

stepper:
  - platform: uln2003
    id: volume_motor
    pin_a: D5
    pin_b: D6
    pin_c: D7
    pin_d: D8
    sleep_when_done: true
    max_speed: 250 steps/s
    acceleration: inf
    deceleration: inf

The idea is to change the volume on a given relative amount of motor steps. This will simplify the adjustment to find the right volume step for you. I declared a new service in api section of my amplifier.yaml:

api:
  password: "*************"
  services:
    - service: set_volume
      variables:
        target: int
      then:
        - stepper.report_position:
            id: volume_motor
            position: 0
        - stepper.set_target:
            id: volume_motor
            target: !lambda 'return target;'

It would be exposed in Home Assistant as esphome.amplifier_set_volume service and will take the only parameter target. So in automation action increasing the volume in my case is looking like this:

Or in YAML:

service: esphome.amplifier_set_volume
data:
  target: 50

Decreasing the volume action is the same, but with negative target:

service: esphome.amplifier_set_volume
data:
  target: -50

Now I have passive speakers with a simple integrated amplifier, and it can’t be turned on or off without physical interaction. You need to press and release the button on the front panel to toggle amplifier power. So today we will add WiFi power control to Cambridge Audion AXA25 integrated amplifier.

It is not a complex task to simulate button pressing. We just need a relay and a delay. But we also need to detect the amplifier state because there are no differences in turning on and turning off actions. Fortunately, my amplifier has a USB port on the back to power some USB devices. Putting something with an LED indicator in this port helped me to detect that the port is powered only when the amplifier is on. Digital pins of ESP8266 boards are good tools to detect the current presence on a USB port. We will need a 5V power line and a ground line from the port. Here is a pinout of the USB port:

Let’s draw!

Components​

1. LOLIN (Wemos) D1 mini (wemos.cc)
2. 5V Relay Brick by Itead (itead.com)
3. AC-DC 220V to 5V Step-Down Mini Power Supply (amazon)

Wemos has a relay shield as well but it can commutate up to 10A current so the electromagnet consumes more power. It is better to use some low-current relay for low-current circuits.

As you can see I’m taking 220V AC power from the amplifier and converting it to 5V DC because we need to power the relay even when the amplifier is off. There is an always-powered low-current circuit that exists in the amplifier, but we can’t use it because of…. well, low current. Connecting a WiFi module and a relay to it will definitely destroy our amplifier.

Firmware​

MQTT​

If you want to use Arduino IDE to develop and flash the firmware to your Wemos D1 Mini board you’ll need to add an ESP8266 board manager and tools for Arduino. You can do this by performing several simple steps from the official ESP8266 repository. Then you can see the MQTT-based firmware sources I was using before migrating to ESPHome. It could be an example, or you can just use it all.

ESPHome​

ESPHome actually makes such projects much easier to implement, improve and support. It also has a very reliable Home Assistant plugin and integration. That is why I moved all my DIY projects to ESPHome and here is a configuration file of my amplifier:

esphome:
  name: amplifier
  platform: ESP8266
  board: d1_mini

wifi:
  ssid: "****"
  password: "**************"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Cambridge AXA25"
    password: "*******"

captive_portal:

# Enable logging
logger:

# Enable Home Assistant API
api:
  password: "******"

ota:
  password: "******"

binary_sensor:
  - platform: gpio
    id: amplifier_power
    internal: true
    pin:
      number: D2
      mode: INPUT_PULLDOWN_16

switch:
  - platform: gpio
    id: relay
    pin: D1
    restore_mode: ALWAYS_OFF
  - platform: template
    name: "Amplifier"
    id: amplifier
    lambda: |-
      if (id(amplifier_power).state) {
        return true;
      } else {
        return false;
      }
    turn_on_action:
      - if:
          condition:
            binary_sensor.is_off: amplifier_power
          then:
          - switch.turn_on: relay
          - delay: 300ms
          - switch.turn_off: relay
    turn_off_action:
      - if:
          condition:
            binary_sensor.is_on: amplifier_power
          then:
          - switch.turn_on: relay
          - delay: 300ms
          - switch.turn_off: relay

That’s it for today. Thanks for reading.

Components and planning​

The base of our project would be Wemos D1 mini – an ESP8266-based development board. Actually, it is possible to use any other WiFi development board you’d like, for example, NodeMCU. I choose the D1 mini because of its size and the nice IR shield it has. So the Wemos IR shield is the second part of our future IoT device. The main goal of the project is to receive commands through WiFi and transmit them to the TV using IR LED. So basically we want to build an IR remote where the buttons are replaced with commands through the WiFi.

Also, we will need 5V DC power for our board. We can’t use a factory USB port on our TV because it is not powered when TV is off. I really like to use mini AC-DC converters from Hi-Link in my projects and I really recommend it, but today I’ll need more power because I want to constantly power my Chromecast from the same power source. Because why not. So I found an old power supply that can handle up to 1.2A of current. Should be enough for a WiFi board and Chromecast.

Finally, we will also connect to the factory USB port of our TV. It is the best way to detect TV state (is it on or off currently).

In general, the parts of the project should be connected like this:

Now we will take a look at our TV from the inside.

Build​

Power Supply​

First of all, I removed the housing from my power supply. You don’t need to do this when using a Hi-Link power converter because it has places to solder the wires.

I’ll use a USB port to connect Chromecast to it. Also, I’ll use USB port pins to take power for my WiFi board.

You need to be careful detecting 5V and Ground pins on the USB port. Here is a little help:

From the other side of the power supply board, we have contact plates for AC power. That’s the place where we will solder AC power wires.

Our power supply is ready:

The board​

We are ready to build the mainboard now. Wemos D1 mini and its shields come separately from the pin legs. It is a good opportunity to make our device as small as possible.

But first, we need to solder some contacts on the IR shield. It has several IR LEDs as well as several options for a send pin. We will use only one IR LED – IR4, and D3 digital pin for sending IR signal, so we need to solder contact plates on the IR shield like this:

Also, we don’t need such long pin legs so we can shorten it with wire cutters.

And solder the legs finally.

Now the wires. We need 5V and ground from our power supply to be connected to 5V and ground pins of the WiFi board.

Also, we will need the wires to the factory USB port to detect the state of our TV. According to our plan, the 5V from the TV USB port will go to the D2 pin of the Wemos board, and the ground should go to the ground pin.

The firmware​

We can make it ourselves. That is what I’ve done in the past. It was a solution that takes BASE64 encoded IR data through MQTT protocol, decodes it, and sends it to the IR led. You can check it on my GitHub. I also had a separate IR receiver to read IR codes from IR remotes and encode them using BASE64. You don’t need all these sources if you are using ESPHome. With ESPHome we will have a simple YAML config for our device:

esphome:
  name: living_room_tv
  platform: ESP8266
  board: d1_mini

wifi:
  ssid: "WiFi"
  password: "************"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Living Room TV"
    password: "************"

captive_portal:

# Enable logging
logger:

# Enable Home Assistant API
api:
  password: "************"
  services:
    - service: volume_up
      then:
        - remote_transmitter.transmit_samsung:
            data: 0xE0E0E01F
    - service: volume_down
      then:
        - remote_transmitter.transmit_samsung:
            data: 0xE0E0D02F
    - service: switch_source
      then:
        - remote_transmitter.transmit_samsung:
            data: 0xE0E0807F
    - service: hdmi1
      then:
        - remote_transmitter.transmit_raw:
            carrier_frequency: 38029
            code: [+4497,-4497,+552,-1657,+552,-1657,+552,-1657,+552,-552,+552,-552,+552,-552,+552,-552,+552,-552,+552,-1657,+552,-1657,+552,-1657,+552,-552,+552,-552,+552,-552,+552,-552,+552,-552,+552,-1657,+552,-552,+552,-552,+552,-1657,+552,-552,+552,-1657,+552,-1657,+552,-1657,+552,-552,+552,-1657,+552,-1657,+552,-552,+552,-1657,+552,-552,+552,-552,+552,-552,+552,-47858]
    - service: hdmi2
      then:
        - remote_transmitter.transmit_raw:
            carrier_frequency: 38029
            code: [+4523,-4497,+552,-1709,+552,-1709,+552,-1709,+552,-579,+552,-579,+552,-579,+552,-579,+552,-579,+552,-1709,+552,-1709,+552,-1709,+552,-579,+552,-579,+552,-579,+552,-579,+552,-579,+552,-579,+552,-1709,+552,-1709,+552,-1709,+552,-1709,+552,-1709,+552,-579,+552,-1709,+552,-1709,+552,-579,+552,-579,+552,-579,+552,-579,+552,-579,+552,-1709,+552,-579,+552,-43993]

ota:
  password: "************"
  
remote_transmitter:
  pin: D3
  carrier_duty_percent: 50%
  
binary_sensor:
  - platform: gpio
    id: tv_power
    internal: true
    pin:
      number: D2
      mode: INPUT_PULLDOWN_16

switch:
  - platform: template
    name: "Living Room TV"
    id: living_room_tv
    lambda: |-
      if (id(tv_power).state) {
        return true;
      } else {
        return false;
      }
    turn_on_action:
      - if:
          condition:
            binary_sensor.is_off: tv_power
          then:
          - remote_transmitter.transmit_samsung:
              data: 0xE0E040BF
    turn_off_action:
      - if:
          condition:
            binary_sensor.is_on: tv_power
          then:
           - remote_transmitter.transmit_samsung:
              data: 0xE0E040BF

remote_transmitter is a part where we are declaring our IR transmitter.

binary_sensor is a sensor that will read the voltage from the TV USB port to tell its current state.

switch section is our main functionality. It will be exposed as an entity in Home Assistant and will allow us to control our TV. As you can see from lambda it takes the state from binary_sensor and uses an IR transmitter to send IR “power” command to the TV when turned on or off. It also checks the state of binary_sensor before sending IR command to avoid turning off the TV when it was turned on several times, for example, from automation or service.

data field for remote_transmitter.transmit_samsung can be discovered using a simple ESPHome IR Receiver built with the same Wemos D1 mini and IR shield. You can even do it with the same board we are using for this project as was mentioned before.

I also want to be able to control TV volume and switch input sources through WiFi. So I’ve added a services section in api. All those services would be exposed as esphome in Home Assistant.

You can see hdmi1 and hdmi2 services have transmit_raw instead of transmit_samsung. This is because I don’t have such buttons on my TV remote to discover the codes so I found the codes in pronto hex format and was able to convert it to raw data with frequency detection using IrScrutinizer.

That’s it. Compile it and flash it with ESPHome Flasher.

TV​

Placing the board​

Let’s find our TV IR receiver. Usually, it is where the red light is flashing on it. Disassembled my TV more I found it on the bottom edge. We need to put our WiFi board as close as possible to the TV IR receiver pointing our sending IR LED (IR4) in the direction of IR receiver.

While the power from the power supply is not connected yet, we can power the board from a micro USB, power our TV and make the first test.

When trying to put the TV housing back on with the WiFi board inside I discovered that I need to make the device even smaller. So I removed IR receiving LED as I have an IR receiver as a separate device. Also, I was forced to solder all wires on the same side of the board.

Now we are ready to use our favorite tool – double-sided adhesive tape, to put the board in its constant living place.

Factory USB port​

Here it is on the factory board:

On the other side of this board, we can find the pins where we will solder the wires from the WiFi board – one from D2, and the other from the ground.

Power​

Now let’s take a look at the AC power connector on the TV. We can find the pins on the opposite side of the board and solder AC wires from our power supply to it.

Before placing our power supply inside the TV we need to make sure it is isolated from its metal body. I’ve put a layer of plastic under it.

So the overall picture is looking like this:

First of all, we need to set up notification service via GSM modem following the official documentation. This will allow us to send SMS messages by calling the notify service, for example in automation action:

action:
  - service: notify.sms
    data:
      message: Hi!

But also this integration allows reading SMS messages sent to the modem phone number by listening to the sms.incoming_sms event.

trigger:
  - platform: event
    event_type: sms.incoming_sms

In automation action, we can now parse the message by searching keywords in it:

action:
  - choose:
      - conditions:
          - condition: template
            value_template: >-
              {{'engine is off' in trigger.event.data['text']}}
        sequence:
          -  ...

Here we are checking for the engine is off text in incoming SMS to perform some action. For example, to set the value of some input_boolean.

See that little glass tube? That’s a reed switch. It operates under a magnetic field generated by the magnet inside the second part of the sensor. So, in general, it just closes the contact between two points of the electrical circuit. We can unsolder it and replace it with something else. A switch, for example. Or with a car seat pressure sensor, like this one:

It could be found on Amazon or our favorite Chinese store just for 5$. It has two wires that could be closed or opened according to pressure presence. So all we need is to solder this sensor to the Aqara sensor’s board instead of the reed switch.

I’ve removed the button cup from the top of the sensor to leave a hole for wires. Just remember to pair your sensor with whatever you are using as a ZigBee hub before doing this.

All we need to do now is to put our new sensor under the mattress. I have a bed with wood slats that is narrower than the pressure sensor so I decided to put the sensor on a cardboard sheet

I made two sensors to separately detect the bed presence of me and my wife. You need to experiment with the sensor position to get the most accurate results. Also, you need to remember that the “open” state of the sensor means “the bed is not occupied” and “closed” means that “the bed is occupied”.

The third sensor on the screenshot is a Home Assistant template binary sensor that represents unconditional bed occupation. In other words, it is on when someone is in bed, and off otherwise:

binary_sensor:
  - platform: template
    sensors:
      bed_occupancy:
        friendly_name: "Bed occupancy"
        device_class: occupancy
        value_template: "{{is_state('binary_sensor.bed_occupancy_door_side', 'off') or is_state('binary_sensor.bed_occupancy_window_side', 'off')}}"

automation:
  trigger:
    platform: sun
    event: sunset
    offset: -00:30
  variables:
    notification_service: notify.paulus_iphone
  action:
    - service: "{{ notification_service }}"
      data:
        message: Beautiful sunset!

It is very useful and fun feature but at first I didn’t realize how powerful it is. Today I want to show you an example how you can use variables as some sort of configuration for automation to avoid creating a lot of ifs and automation to handle identical tasks.

I have a lot of ZigBee wall switches. Previously I had a separate automation to handle each of them. Every automation was handling:

• First button press – toggle the lights with max brightness
• Second button press – toggle the lights with low brightness
• First button long press – increase the brightnress
• Second button long press – decrease the brightness

After implementing variables for automation I decided to store the mapping of device id, event (represents the button pressed and the type of press: long or short), corresponding brightness and light entity_id in variables like this:

  variables:
    device_map:
      00:15:8d:00:02:cb:1a:9b:
        light_entity_id: light.kitchen
        brightness_buttons:
          1001: -30
          1002: 50
          2001: 30
          2002: 100
      00:15:8d:00:02:c9:39:62:
        light_entity_id: light.hallway
        brightness_buttons:
          1001: -30
          1002: 55
          2001: 30
          2002: 100
      00:15:8d:00:02:e9:fe:9e:
        light_entity_id: light.living_room
        brightness_buttons:
          1001: 30
          1002: 100
          2001: -30
          2002: 60
      00:15:8d:00:02:cb:64:b4:
        light_entity_id: light.hallway
        brightness_buttons:
          1001: 30
          1002: 100
          2001: -30
          2002: 60
      00:15:8d:00:02:c9:37:7d:
        light_entity_id: light.bedroom
        brightness_buttons:
          1001: 30
          1002: 100
          2001: -30
          2002: 24
      00:15:8d:00:02:58:61:74:
        light_entity_id: light.bathroom
        brightness_buttons:
          1001: 30
          1002: 100
          2001: -30
          2002: 40

So now I can take the brightness value from my device_map by device id and event. Also, I can take entity_id of the light each wall switch should control.

Also when I’m toggling the light I need to use brightness_pct service data to set the brightness, but when changing the brightness I need to use brightness_step_pct. So I added another variable to set the brightness service data name:

variables:
  brightness_attr: '{% if (trigger.event.data[''event''] == 2001) or (trigger.event.data[''event'']== 1001) %}brightness_step_pct{% else %}brightness_pct{% endif %}'

So when the button held the event is 2001 or 1001 (first and second button) and I need brightness_step_pct. I’m getting brightness_pct in another case.

Now we can use all these variables in action:

action:
  - data:
      '{{brightness_attr}}': '{{ device_map[trigger.event.data[''unique_id'']].brightness_buttons[trigger.event.data[''event'']]}}'
      entity_id: '{{ device_map[trigger.event.data[''unique_id'']].light_entity_id}}'
    service: light.{% if (trigger.event.data['event'] == 2001) or (trigger.event.data['event']== 1001) %}turn_on{% else %}toggle{% endif %}

Here we are using the most of variables – we are getting the right brightness value by the unique_id of our device and by the event that is representing the button and the type of press:

{{ device_map[trigger.event.data[''unique_id'']].brightness_buttons[trigger.event.data[''event'']]}}

Also, we are getting light entity_id by unique_id of the switch:

{{ device_map[trigger.event.data[''unique_id'']].light_entity_id}}

And the full automation:

- id: wall_switch_handler
  alias: Wall switch handler
  trigger:
  - event_data:
      event: 1001
    event_type: deconz_event
    platform: event
  - event_data:
      event: 1002
    event_type: deconz_event
    platform: event
  - event_data:
      event: 2001
    event_type: deconz_event
    platform: event
  - event_data:
      event: 2002
    event_type: deconz_event
    platform: event
  condition:
  - condition: template
    value_template: '{{''wall_switch'' in trigger.event.data[''id'']}}'
  action:
  - data:
      '{{brightness_attr}}': '{{ device_map[trigger.event.data[''unique_id'']].brightness_buttons[trigger.event.data[''event'']]}}'
      entity_id: '{{ device_map[trigger.event.data[''unique_id'']].light_entity_id}}'
    service: light.{% if (trigger.event.data['event'] == 2001) or (trigger.event.data['event']
      == 1001) %}turn_on{% else %}toggle{% endif %}
  variables:
    brightness_attr: '{% if (trigger.event.data[''event''] == 2001) or (trigger.event.data[''event'']
      == 1001) %}brightness_step_pct{% else %}brightness_pct{% endif %}'
    device_map:
      00:15:8d:00:02:cb:1a:9b:
        light_entity_id: light.kitchen
        brightness_buttons:
          1001: -30
          1002: 50
          2001: 30
          2002: 100
      00:15:8d:00:02:c9:39:62:
        light_entity_id: light.hallway
        brightness_buttons:
          1001: -30
          1002: 55
          2001: 30
          2002: 100
      00:15:8d:00:02:e9:fe:9e:
        light_entity_id: light.living_room
        brightness_buttons:
          1001: 30
          1002: 100
          2001: -30
          2002: 60
      00:15:8d:00:02:cb:64:b4:
        light_entity_id: light.hallway
        brightness_buttons:
          1001: 30
          1002: 100
          2001: -30
          2002: 60
      00:15:8d:00:02:c9:37:7d:
        light_entity_id: light.bedroom
        brightness_buttons:
          1001: 30
          1002: 100
          2001: -30
          2002: 24
      00:15:8d:00:02:58:61:74:
        light_entity_id: light.bathroom
        brightness_buttons:
          1001: 30
          1002: 100
          2001: -30
          2002: 40
  initial_state: true
  mode: parallel
  max: 10

I have not only wall switches so I’m using template condition here to make sure the switch is the wall switch:

  condition:
  - condition: template
    value_template: '{{''wall_switch'' in trigger.event.data[''id'']}}'

Also, this automation should be able to run in parallel to make it possible to handle several switch clicks at the same time in different rooms by different persons:

  mode: parallel
  max: 10

If you still want to use IFTTT, you are welcome to continue reading.

Home Assistant IFTTT webhook​

First of all, we need to create a webhook for IFTTT in our Home Assistant instance through Integrations. Go to “Configuration” -> “Integrations” in the Home Assistant web UI. Find “IFTTT” in the “Set up a new integration” section and click “CONFIGURE”. You will be provided with a webhook URL to use in IFTTT applets. It should look similar to this:

https://ha.mydomain.com:8123/api/webhook/e7cd74856399e8934b8f5beffeeeaee4c351cdc8373647585ec040c7b69c2b999

Save this URL somewhere because you will not be able to see it again in your Home Assistant UI.

Home Assistant Entities​

For presence detection, I’m using binary_sensors with device_class: presence. Also, the state of those sensors depends on the corresponding input_boolean. It is made to be able to switch someone’s presence on and off manually by adding input_boolean to UI and switching its state. Don’t set the initial state for input_boolean. It will make it possible to save and restore its state on HA reboots. Also, I set these sensors to have different pictures depending on their presence.

input_boolean:
    is_yegor_home:
      name: “Yegor’s presence”

binary_sensor:
  - platform: template
    sensors:
      presence_yegor:
        friendly_name: "Yegor"
        value_template: "{{ is_state('input_boolean.is_yegor_home', 'on') }}"
        device_class: presence
        entity_picture_template: "/local/yegor_picture_bw.jpg"

IFTTT applets​

Next. There is an official Google WiFi service in IFTTT and it can create IF’s like “If some device connected/disconnected”. That’s exactly what we need.

Open IFTTT website and log in with your account. Go to “My Applets” and click “New Applet” in the upper right corner.

Then hit “+this”, search for “Google WiFi” and click it. You will be asked to authorize IFTTT in your google account. After that you will be able to select one of the triggers Google WiFi can send to IFTTT:

Let’s start with “Device connects”. Click it and select the device name you want to track in the next step.

Next, you will be asked to create an action by clicking “+that”. For action, you need to find the “Webhooks” service and choose the only action it provides – “Make a web request”.

Now we need to fill all the fields for web request:

URL: [The url of our Home Assistant webhook we created recently]

Method: POST

Content Type: application/json

Body: { "action": "call_service", "service": "input_boolean.turn_on", "entity_id": "input_boolean.is_yegor_home"}

Handling IFTTT requests​

The last thing we need is to create a handler in Home Assistant for web requests from IFTTT. It will be new automation:

- id: 'ifttt_webhook'
  alias: IFTTT Webhook
  trigger:
    platform: event
    event_type: ifttt_webhook_received
    event_data:
      action: call_service
  action:
    service_template: '{{ trigger.event.data.service }}'
    data_template:
      entity_id: '{{ trigger.event.data.entity_id }}'

This automation will handle any requests from IFTTT that will have action: call_service in their body with service and entity_id in it.

For disconnecting from Google WiFi we need to create another applet in IFTTT. It will be the same except for two things:

1. We should select “Device disconnects” from Google WiFi services when creating “+this” for applet.
2. We need to replace input_boolean.turn_on with input_boolean.turn_off in web request’s “Body” field when creating “+that” to make it looks like this:

{ "action": "call_service", "service": "input_boolean.turn_off", "entity_id": "input_boolean.is_yegor_home"}

Automation based on presence​

Assuming we’ve set up presence detection for everyone living in our home, we now need one variable to know if there is nobody home now. It would be helpful when creating automation that should be triggered when there is nobody home or when someone is back home. So we will add all our presence sensors in a group in groups.yaml:

presence:
    entities:
        - binary_sensor.presence_someone
        - binary_sensor.presence_yegor
        - binary_sensor.presence_someone_else

Now we can rely on that group’s state to check if there is nobody home. I’ve added a delay of 10 minutes to make sure this automation will not be triggered when I simply reboot my device or there was a short connection lost to a router.

- id: 'nobody_home'
  alias: 'Nobody home'
  trigger:
  - entity_id: group.presence
    for:
      minutes: 10
    from: 'on'
    platform: state
    to: 'off'
  condition: []
  action:
  - data:
      message: “Looks like there is nobody home now”
    service: notify.push

That is all for now. Thanks for reading.

All my Aqara ZigBee devices are connected to Home Assistant via ConBee II and deCONZ.

First of all, let’s create a script that will be executed when the button is pressed. In your scripts.yaml:

doorbell:
  alias: Doorbell
  sequence:
  - data:
      entity_id: media_player.googlehome4615 #Your Google Home device
    service: media_player.turn_on
  - delay: 00:00:03 #To make sure we are connected to Google Home
  - data:
      entity_id: media_player.googlehome4615 #Your Google Home device
      media_content_id: https://your.homeassistant.domain:8123/local/doorbell.mp3
      media_content_type: music
    service: media_player.play_media
  - delay: 00:00:05  #The same as doorbell.mp3 file ledgth
  - data:
      entity_id: media_player.googlehome4615
    service: media_player.turn_off

To make doorbell.mp3 available by that URL you need to place it to /config/www in your Home Assistant.

Now we need to create a handler of the Aqara button in automations.yaml:

- id: doorbell_notify
  alias: Doorbell notify
  trigger:
  - entity_id: script.doorbell
    from: 'off'
    platform: state
    to: 'on'
  condition: []
  action:
  - data:
      message: "Someone near your front door"
    service: notify.push

My air humidifier has no automatic turn on and off, no timers, only a regulator that also works like a switch. The idea is to make it WiFi-friendly and work with Home Assistant through MQTT.

Actually, I was pretty lucky with this device because there are other models of it with built-in sensors, screens, and other stuff so the hardware was prepared to connect additional modules. But we don’t want to measure humidity inside the humidifier right? So the sensor will be a separate part of the system.

Teardown​

So it has an AC/DC power supply. Now we need to find 5v power line for our additions. All internal parts are powered with 12V DC so we need a step down module. In my case there was an empty 12V connector right on the factory board:

Assembling​

So we will connect there a regulated power down module and set it up to a 5V output:

Now the main hardware. It is a Wemos D1 Mini ESP8266-based board (well almost because in my case it is a no-name copy of it, don’t buy it please) and a beautiful relay brick from Itead Studio:

Connect it all together. Wemos D1 mini can be powered with stable 5V DC power connected to its 5V pin:

Now we need to unsolder the wires from a factory button or switch and connect it to our relay:

The last step will be gluing all new parts inside our device. Don’t repeat my mistake and glue the WiFi board with micro-USB port pointing outside of the humidifier, not inside it:

Improvements​

The final version of my humidifier also checks the state of the factory switch and reports the state to MQTT binary sensor in Home Assistant. Here is a final diagram of this project:

The software was also improved. There was WiFiManager for ESP8266 boards added to make it possible to configure WiFi and MQTT settings without flashing the board.

The code​

The old code was missing long time ago.

Home Assistant​

An example of MQTT platform switch configuration in Home Assistant for humidifier:

switch:
  – platform: mqtt
    name: "Humidifier"
    state_topic: "edwin/humidifier/state"
    command_topic: "edwin/humidifier/power"
    state_on: "on"
    state_off: "off"
    payload_on: "1"
    payload_off: "0"

ESPHome migration​

And finally here is a YAML configuration of my humidifier after it was migrated to ESPHome:

esphome:
  name: humidifier
  platform: ESP8266
  board: d1_mini

wifi:
  ssid: "****"
  password: "************"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Edwin Humidifier"
    password: "************"

captive_portal:

# Enable logging
logger:

# Enable Home Assistant API
api:
  password: "************"

ota:
  password: "************"

switch:
  - platform: gpio
    name: "Humidifier"
    pin: D1
    restore_mode: ALWAYS_OFF
    
binary_sensor:
  - platform: gpio
    name: "Humidifier state"
    pin:
      number: D5
      mode: INPUT