I use an acurite 06002RM temperature and humidity sensor with a rtl 433 compatible receiver plugged into home assistant and an rtl2mqtt add on. It’s indoor/outdoor and has worked well for all sorts of weather. Combined with a sun shade and it’s a good solution I think, and completely local.

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.

Check out this device. I have several and they work well. Zigbee temperature sensor in a cabled probe.

EasyDNS is Canadian based out of Ontario. I only use them for email and dns personally but they do web hosting also.

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.

I have a bunch of Tuya and Aqara buttons from AliExpress and I’m happy with them. I haven’t found anything similar on Canadian Amazon at least.

2,4,6 button variants of https://www.zigbee2mqtt.io/devices/WXCJKG11LM.html#aqara-wxcjkg11lm

4 button https://www.zigbee2mqtt.io/devices/TS004F.html#tuya-ts004f

You’ll need to use | float(0) in templates. All state values and attributes start out as strings. Also setting a default value in the float(#) cast will ensure templates don’t break when the value is invalid.

That means use this style: {{ state\_attr("light.kitchen\_sink\_ceiling", "brightness") | float(0) }}

We need more information to recommend anything. Do you need high voltage switching? Do you have zigbee, zwave, or only wifi available? How much integration or local on device control do you actually want or need?

It comes down to what are the developers willing or able to support.

For smaller teams they usually don’t want the responsibility of maintaining the package for distros, and HA developers have chosen to not support that option themselves. In their case I see it - what’s the benefit or incentive to them to maintain packages and the associated support costs or headaches. Containers mean they get a known state and don’t have to try to support unknown environments.

Some interested people can maintain the packages for their chosen distro - for instance I see one for Gentoo but it’s only up to 2024.6. It’s the first that came up in a search but there are likely more too supported by the community.

In my case, I also think that using HAOS on a dedicated box has led to a more stable experience as it’s not competing for resources on my other hosts, and attaching devices to it is much simpler. I think encouraging a solid base for people means a better experience overall when to be honest it’s hard to get started with it to begin with for many people.

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.

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.