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?
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.
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.
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.
This. Basically few addons are ‘fire and forget’, almost all of them need some sort of configuration that’s listed in the Documentation tab, or in the add-ons repo. You’ll need to read up on it and look at the Configuration tab to set whatever you need to allow it to work.
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.
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.
Yes, based on my migration from a Raspberry Pi to a mini x86 pc. A full backup contains a complete snapshot of that moment and all your configuration, history, and all add-ons and their data. I think HACS came across too, though I can easily be misremembering.
The restore looked like it tried to do everything but my large database add on (PostgreSQL) gave it grief so I ended up restoring components separately. The backups did work overall though, and after a few reboots everything worked.
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.
Iirc that’s where they start ERs yes - it’s easier to see, vote, and comment on them there compared to GitHub. It’s also the source for the month of WTF where it seemed like a lot of the easier ERs get addressed.
Not according to the integration documentation: https://www.home-assistant.io/integrations/recorder/
The recorder integration only supports: domains, entities, events, and entity globs right now. I think that’s a good idea though, should check or create an enhancement request!
First thing - exclude recording of the devices. My method was to use a glob so I name devices/entity IDs specifically and they don’t get recorded (in my case I used f_ as in “filtered” so devices become like “F Source Presence”), but you can add specific entities or use your own glob. In configuration.yaml I have this:
recorder:
exclude:
entities:
- sensor.excluded_entity_1
# AND/OR this (then of course rename entities as needed)
entity_globs:
# exclude all sensor entities that start with f_
- sensor.f_*
Then I created templates for my presence sensors, that just copy the state so I get history (yaml here, but can do through UI now too in the Helpers section, the import part is the template in the state key below):
template:
- binary_sensor:
- name: Real presence
unique_id: my_presence
state: >-
{{ states('binary_sensor.f_source_presence}}
availability: >-
{{
not (
states('binary_sensor.f_source_presence') == 'unknown' or
states('binary_sensor.f_source_presence') == 'unavailable'
)
}}
device_class: presence
You could also use a statistics sensor to get a moving average for numeric values and get history from them too (and reduce the noise by reducing the precision and having a larger time window). This is also available through the UI - Helpers.
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
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.