Not sure what you mean by this - Nabu Casa has a Zwave device already called ZWA-2 which is fully supported.

A strong mesh is a better way to go to me - ensuring you have a mesh of router devies between the coordinator and the end device has worked well to ensure that no matter where the device is it works. A better antenna may help but all it takes is a glitch like your 2.4 wifi moving to overlap with the Zigbee range and the device drops out.

I have a tubesb Zigbee device with an external antenna and I’m not sure I’ll benefit from the ZBT2 but the 2.4ghz band is very busy here. I’m tempted to try it and see if it makes any difference. I find my Zigbee network ‘slow’ - like sensor updates take 1-2 seconds before HA receives them.

Bcache can’t differentiate between data and metadata on the cache drive (it’s block level caching), so if something happens to a write-back cache device you lose data, and possibly the entire array. I wouldn’t use bcache (or zfs caching) without mirrored devices personally to ensure resiliency of the array. I don’t know if zfs is smarter - presumably is can be because it’s in control of the raw disks, I just didn’t want to deal with modules.

For your second scenario - yes you can use md under bcache with no issues. It becomes more to configure but once set up has been solid. I actually do md/raid1 - luks - bcache - btrfs layers for the SSD cache disks, where the data drives just use luks - bcache - btrfs. Keep in mind that with bcache if you lose a cache disk you can’t mount - and of course if you’re doing write-back caching then the array is also lost. With write-through caching you can force disconnect the cache disk and mount the disks.

I work around this with the uptime integration then conditions in automations that uptime must be over whatever time I want.

You could try using not_from in your state trigger but I’ve had limited success with that working recently. Something like this:

#…
  - trigger: state
    entity_id:
      - event.inovelli_on_off_switch_config
    not_from:
      - unavailable
      - unknown
#…

Check out Decoupled https://decoupled.app/

Based on what I’ve seen with my use of ZRam I don’t think it reserves the total space, but instead consumes whatever is shown in the output of zramctl --output-all. If you’re swapping then yes it would take memory from the system (up to the 8G disk size), based on how compressible the swapped content is (like if you’re getting a 3x ratio it’s 8GB/3=2.6GB). That said - it will take memory from the disk cache if you’re swapping.

Realistically I think your issue is IO and there’s not much you can do with if your disk cache is being flushed. Switching to zswap might help as it should spill more into disk if you’re under memory pressure.

YouTube blocks it. There are extensions to allow it (like Vinegar) but by default it’s blocked. Brave might work around YouTube’s block in the same way.

You can try adding

continue_on_error: true

to the scene action so it doesn’t kill the entire automation. Note that if later parts depend on this action then they’ll fail in weird ways. The best thing is to fix the Zigbee network so the device doesn’t drop off but I know that’s not easy.

Check with your provider for SIP server, username and password, and if they have a suggested app (even if you don’t want to use it, it means they have some kind of support). It’s probably in their support pages somewhere.

I think it’s not quite as well known or prevalent as other services (as say SSH) so likely doesn’t have anything automated attacking it yet. If you check something like http://shodan.io/ against your ip, I’d guess the service has been found.

Home Assistant likely won’t come under any kind of attack until there’s a very easy to exploit, unpatched zero-day vulnerability in the wild. Given how many people (myself included) who have HA exposed publicly it’s really a matter of time. The best mitigation is not exposing publicly if possible, and staying up to date.

In my case I don’t expose HA over 8123, I have a proxy on 443 where HA is not the default host name, meaning if you don’t use the right host HA doesn’t receive the traffic. As I’d expect that automated attackers wouldn’t what my host is it’s a reasonable layer in the security onion. I don’t expect anything would realistically protect from a targeted attack but I’m also not important enough to be targeted.

We can’t ever stop this kind of stuff, but with something like fail2ban you can set it up to block on too many failures.

Really though - ensuring your system is kept up to date and uses strong passwords or use a SSH keys is the best defence. Blocking doesn’t prevent them from trying a few times. Moving SSH to a non standard port will stop most of the automated attacks but it won’t stop someone who is dedicated.

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.

Without looking at it it’s probably making a unique request to a resource on a NextDNS subdomain and watching where the request comes from. Like pulling an image from (unique _string).check.nextdns.com. This requires nothing special on the client, it’s making a standard request, and as part of that it needs to do a DNS lookup.

If the source of the and your IP are similar then it’s likely the same network, otherwise it can correlate the source with known resolvers.

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.

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.