This sounds like you’ll need to do a balance operation. Try this first and see if it helps:

btrfs balance start -dusage=0 -musage=0 /

If not you can increase the number to 5 or 10. This operation reallocates chunks on the disk and ensures they’re filled - check https://btrfs.readthedocs.io/en/latest/Balance.html for details.

I use HASS.agent to help manage my Windows desktop and expose various sensors to HA. It can suspend or hibernate the system. It does use MQTT as its connectivity plane.

You get easy access to their addons with a VM (aka HAOS). You can do the same thing yourself but you have to do it all (creating the containers, configuring them, figuring out how to connect them to HA/your network/etc., updating them as needed) - whereas with HAOS it generally just works. If you want that control great but go in with that understanding.

Yes I simplified. Some(? I’d hope all but probably not) new fobs do turn off (ignore the car broadcast) if they are not moved for a time. I proved this to myself with my 2020 car by putting my keys down by my car door, I could only unlock the car for a minute or two after I put it down, after that keyless entry didn’t work until I disturbed the fob to wake it up.

This is to mitigate the relay attack at home (and I’m sure other times, like if the key is in a purse), one avenue was that attackers would count on people hanging their keys by the door, so accessible to selective standing on the stoop with a relay. By turning off at rest they can’t be exploited this way.

Older fobs never turned off - so they are constantly broadcasting the signal for the car. Newer fobs do turn off when at rest so they’re less risky, but if say it’s in your pocket it’s constantly moving so someone could still relay it to steal your vehicle, assuming they get close enough to you.

The faraday bag is good for older fobs or if you think you’re at risk of a key relay attack.

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.

I’d have to check my iptables syntax again but I’m not sure you want the FORWARD between the networks unless C has a manual route to get traffic for the 192.168.15.0/24 network back via B. You just want to NAT A behind B’s IP on 192.168.38.0/24. I think the forwards are sending the traffic without doing NAT on A.

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.

All that yes. The Wooting One (original that uses IR light) let you use buttons to simulate controller axes, change how hard you need to press to activate, and add second functions to keys. It was an interesting idea but I found the gaming part the original keyboard to be only usable in a limited set of games as it’s not as sensitive as a controller stick, and as a keyboard it wasn’t great either. Hopefully V1 problems, I know they had through another version of the IR keyboard, and then came out with the Hall effect keyboard. I like the idea but never could get used to it, and when the spacebar was loose I retired it after fixing it.

Yes, the packet passes through routers at each stage and they direct the packet to the ‘closest’ path based on its destination, until the final router has the destination on its network. This can happen a few times (for something in your ISP network), or 10-30+ times for something further away.

apropos to search man pages, otherwise I use man

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.

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.