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?
CondorWonder
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.
Ohhh I haven’t seen that Zooz relay before, hopefully I can get it in Canada. Going to see about replacing the Shelleys I’ve got deployed then
The thermostat should be a passive device and is really just a relay on its own. It could be connected to the switch pins on a Shelly.
I don’t know of a compact zwave dry relay though - so this does mean 2.4ghz wifi.
If it’s like one I rented a few years ago, yes the thermostat just controls a fan, and the radiator is always hot or cold as it’s controlled by the building. I’d be inclined to use a Shelly or other dry relay with a virtual thermostat in home assistant now.
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.
Right now - easy, with the difficulty going up over time as the main Chromium codebase continues to change (and especially as it gets security updates). I think I’ve read that some variants (Brave?) have committed to supporting ManifestV2 for as long as possible, for instance with their own fork.
I do this with my desktop - I work from home so it’s really nice to have my PC ready by the time I get down to it. There’s a workday integration too, set your typical schedule and it’ll be true when it’s a workday - with a motion sensor as the trigger as my start time varies if I have meetings In the morning.
This is one of the first things I set up with HA for fun but the convenience is really nice.
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.
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.
You’ll need to use
| float(0)
in templates. All state values and attributes start out as strings. Also setting a default value in thefloat(#)
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) }}