WoL packets are usually sent to the ip broadcast address for the network as they’re not ip based. I don’t know if this would ever work well across networks. Can you do send the wol packet from the opnsense router instead? Does it work then?

If you’re sending it to the IP of the server, it likely works soon after your turn the machine off because the ARP entry hasn’t timed out yet, but once it times out it won’t work anymore. The router doesn’t know how to get to the machine. You may be able to add a static arp mapping to get it to work long term.

The add-on store that’s managed and updated via the supervisor. It does the same thing as your setup, but integrates into HA nicer (automatic connectivity to HA for the containers, when they need it). If you’re happy with how your setup works then there’s no compelling reason to switch.

I use an Emporia Vue device, it uses an ESP32 internally and you can find instructions on how to flash it with esphome code onto it. No cloud dependency, just wifi.

You can get various kits for one/two/three phase mains, and monitor up to 16 individual circuits via passive current clamps.

Set the wait to have a timeout and it will work.

Your wait needs to wait for a time, and decide if you want to proceed if you don’t get a response. Right now the wait for a trigger is expecting the event to be ready when it starts (before you’ve even seen the notification), and when it’s not the automation is stopping because continue on timeout is false. A wait for a trigger without a timeout doesn’t wait forever.

Make sure you’re not using any of the strapping pins for the interface with the AHT22 - take a look at https://esp32.com/viewtopic.php?t=5970 for a read. It basically means leaving GPIOs 12, 0, 2, 4, 15, 5 floating during boot or the esp will not boot correctly.

These pins control the boot process (like going to the boot loader instead of your code).

Yes. There’s no support (hopefully just yet) for multiple Home Assistant instances with the same account.

It’s called Badges - edit the dashboard page, then click on the edit button beside the tab.

apropos to search man pages, otherwise I use man

Why not set up an automation for when it disconnects (goes into unavailable or unknown state probably) and send a notification? That’s relying on the actual problem (Nest goes offline) rather than a side effect of the problem (notification that the integration is broken).

Try executing just /config/backup.sh - the config directory is mapped into the HA container under /config, not under /root.

I’m not sure how consistent it is but the static binaries I have for btrfs-progs are about 2x larger than their dynamic counterparts. If you statically compile it only the functions actually used are included in the binary, so it really depends on how much of the library is used.

Zigbee is a mesh network so it’s a bit different. Zigbee devices can be an end device, or a router device (in addition to whatever it actually does likes controlling a plug). Routers contribute to your zigbee mesh, and devices connect through the mesh. This means you need more router devices to have a strong mesh. I use a few plugs where my network is weak, but otherwise have found that devices are stable. I can’t see on the zigbee2mqtt site if they’re a router or end device, but most powered devices are routers. ZHA and Zigbee2mqtt both tell you the device type if you go digging.

If they’re zigbee devices I don’t think they can be flashed with esphome. They’re not normal esp devices and that would likely disable the zigbee networking.