All posts by Thomas W-P

ESPHome ESP8266 connection issues with ASUS (XT8 and XT9) WiFi routers

This caused me a lot of pain with the ESPHome devices continually throwing up their own access points and refusing to join the wifi. I had full control of the devices when I could get them connected using Home Assistant – ESPHome Builder. The steps along the way that I took were:

  • Separate my WiFi in to an IoT 2.4G network and a 5.0G network for the house. This allows me to simplify the WiFi as much as possible and I think stops the Smart Connect from causing issues.
  • Turned off everything I could in the 2G network to keep it as simple as possible. I am not sure how much was neccessary but it is working perfectly now and I don’t want to backtrack.
  • Set wireless mode on the ASUS to “Auto” and tick the “Disable 11b“.
  • Add this section to esphome > on_boot in the ESPHome builds for ESP8266 devices (I have many smart sockets). I could always get them to connect straight away if I rebooted my WiFi:
esphome:
  on_boot:
    - priority: -100  # Use negative priority to run AFTER WiFi initializes
      then:
        - lambda: |-
            #ifdef ESP8266
              wifi_set_phy_mode(PHY_MODE_11G);
            #endif

Caddy reverse proxy

I was using Caddy with no problems but it suddenly stopped working after I switched my pihole 6 installation from a proxmox lxc (where it was lagging horribly) to a bare metal Pi3. I put it down to the DNS, and maybe that was the cause but the solution was to remove the wildcard at the top of the Caddyfile.

I was using a wildcard *.local certificate but Firefox rejected it because it didn’t match dns.local.

Removing the *.local section from the Caddyfile fixed it once I had installed the root.crt in Firefox. I use a proxmox script for the caddy installation and it puts the certificates in

/var/lib/caddy/.local/share/caddy/pki/authorities/local/

Ethernet Speed

https://serverfault.com/questions/207474/how-do-i-verify-the-speed-of-my-nic

Thanks to serverfault I found how to check link speed between two debian machines – iperf3

You can see the expected max speed using ethtool:

# assuming eth0 is the interface we care about
~$ sudo ethtool eth0 | grep Speed
        Speed: 10000Mb/s

To see real-time speeds install iperf3, then run one machine as server and one as client:

# on both machines
apt install iperf3 -y
# say no to the install at startup - this is just for occasional testing

# on machine A, which is 192.168.1.3
iperf3 -s

# on machine B - reach out to machine A's IP address
iperf3 -c 192.168.1.3

I got 250 Mb/s whilst doing a backup on the cabling I installed myself 25 years ago (before gigabit was a thing) to a USB ethernet 25m away from the switch, so I will take that.

WSL2, Docker Desktop and Shared Drives

A pain in the bum but I got there.

I was trying to share a NFS share with an immich docker container to have a play with importing videos. The Debian could see it but the Image could not. I am not sure if it is to do with the limit on the omv NFS IP address range or something but I knew if my Windows machine could see it then the damn WSL2 should be able to see it too, natively!

In PowerShell wsl --list --verbose lists which WSL are in use, and confusingly it gives two but the * suggested that this was the one to work with.

  NAME              STATE           VERSION
* Debian            Running         2
  docker-desktop    Running         2

I tried and tried to mount the NFS share there, but though the Debian could see it, the Docker image could not. I share the same folder using SMB so was able to get that in to WSL using:

wsl -d Debian
sudo mkdir /mnt/p
sudo mount -t drvfs P: /mnt/p

This makes the p: drive appear on /mnt/p which I could then get working in the yaml with:

    volumes:
      - /mnt/p:/mnt/p_drive

This worked so nicely that I couldn’t think why the NFS share worked so went back and tried it all over again. It immediately worked!

Argh.