BTRFS has RAID built into the file system - instead of using MD you use BTRFS profiles which tell the system how to handle data.

For instance

• file system data (critical for the file system to function): raid1c3 which means 3 copies of core P file system data on 3 different devices
• user data: raid1 (so duplicating all your data on two different devices)

With this set up you could lose one device (of n, the total doesn’t matter), and not lose any data, and still be able to boot to recover with too much hassle.

BTRFS does block checksums, can scan for bit rot and recover from it, and generally tries to make your data safe. It technically supports raid5/6 for user data, the issue is around unclean shutdowns and a potential write hole where you could lose data, but if your system has a UPS backup and is on a relatively recent kernel it’s not any more dangerous than MD raid5/6 as I understand it.

Phillips SonicCare for 20+ years. I think it’s helped me a lure with my dental care. Various models as the batteries wear out. The latest has Bluetooth that I never use but that doesn’t affect the cleaning part.

The phone or browser may be using DNS over HTTP (aka DoH), check if you can disable it for the wifi network. You may have to disable it on the phone or browser to get your desired behaviour - look up directions for your browser.

If it’s logs, there’s a package called log2ram - it’s designed for small form factor systems to reduce writes to SD cards but does apply anywhere you want to log but not hit disk immediately. It syncs logs to disk on a regular basis so you don’t lose much if the system crashes.

From a Linux command line it would be the command called arp, you need to add a static arp entry. I don’t know how that works on sense, but on Linux it would be something like arp -s IP MAC

Maybe there’s a module in opnsense to help. The way I’ve done this before is using a machine connected to the same network at my target to wake up by logging into that machine and issuing the wake command.

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.

Try searching for your automation.entity_id - like in my case it’s something like automation.notify_washer_done (the original entity id of my automation, found via the developer - states tab). Then if I search using that in my YAML I’d see entity_id: automation.notify_washer_done, and add the context to see the full service call:

service: automation.turn_on
target:
  entity_id: automation.notify_washer_done
data: {}

Assuming it’s an automation or script your should find it in the related .yaml file and can scroll up to see the actual automation or script source.

Turned off or Turned on is the disable or enable action. If it’s changed by something in HA it should show what the trigger was too (like a user or other automation).

Here’s an example - it shows the automations that enabled our disabled this automation, and their trigger.

To prevent the automation from being changed you can rename it, that should break anything automatic that’s changing it. You can also try to chase down what’s changing it from logs (once renamed you should start seeing errors in your HA log file), or by searching for the entity_id in your yaml configuration files.

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).

In general, if you haven’t taken steps to expose your service to the Internet, it’s not accessible over or to the internet. Your router that connects you to the Internet should have a firewall that blocks all inbound, unsolicited requests, and you also need to do something explicit with most self hosted service to expose them, they will not announce themselves to the world.

In addition if you’re using an ipv4 network address that’s likely a private address (like 10.x.y.z, 172.x.y.z, or 192.168.x.y), which also isn’t accessible outside of your network.