Home Assistant Presence Simulation(github.com)
github.com
Home Assistant Presence Simulation
https://github.com/slashback100/presence_simulation
101 コメント
I've been running it for a year on a RPi 2, via WiFi, from a SD card *and* a Zigbee dongle, which is basically what everyone seems to say you should not do, and never had a single issue with it. I don't think these issues have anything to do with HA itself but rather the extensions people install on it.
I think it also has to do with how many devices you have on it and how often they update state. I have 300+ IP devices and have to run it on a mini PC because RPi was too slow. No custom plugins or extensions, just a few basic integrations.
I want to go the other way and say DO NOT use HAOS if you know anything about docker. If you have ANY experience working under linux/docker just don't bother with HAOS and save yourself the headache. You will have an incredibly better experience just running your HASS docker container by yourself.
HAOS caused so many issues for me while it tried to set up the other containers (such as Node Red), specially during home assistant updates, and it also made the whole UI extremely confusing because it would "redirect" some things to HAOS while others would be done inside HASS itself. With it auto trying to manage the containers it was also never clear when things were still booting/loading or crash looping and when you had issues the extremely limited access HAOS gives you was painful to deal with.
As with other personal anecdotes in this thread, it may not be relevant to you, but I'd share my own experience as well, as someone that has had HASS running for 6+ years now.
HAOS caused so many issues for me while it tried to set up the other containers (such as Node Red), specially during home assistant updates, and it also made the whole UI extremely confusing because it would "redirect" some things to HAOS while others would be done inside HASS itself. With it auto trying to manage the containers it was also never clear when things were still booting/loading or crash looping and when you had issues the extremely limited access HAOS gives you was painful to deal with.
As with other personal anecdotes in this thread, it may not be relevant to you, but I'd share my own experience as well, as someone that has had HASS running for 6+ years now.
As a counterpoint, I am very familiar with docker (I use it at my job as a backend developer / devops engineer), and I originally went with the docker based install, but eventually swapped to haos. I switched because addons are vastly simpler to install in haos, and any documentation you find typically assumes that is what you are using.
I haven't used Docker much at all, but I use Proxmox for everything at home (LXC containers for various web servers, Zoneminder, Plex, Pihole, etc. and the occasional VM for stuff like pfSense) on decent hardware. Which HA installation method would you recommend in this case?
My only prior HA experience was around 2017 before they had multiple options; I used a RPi which burned through microSD cards and it was pretty miserable. Gave up by 2019. Not making that mistake again.
My only prior HA experience was around 2017 before they had multiple options; I used a RPi which burned through microSD cards and it was pretty miserable. Gave up by 2019. Not making that mistake again.
I've been using HA since near the very beginning, and I recommend using the Proxmox Helper Scripts script that installs the HAOS VM. That's what I do. I disagree with the OP, HAOS simplifies a lot of stuff like addon installations, updates, backups, and migrations. It's the main supported way to run Home Assistant now and the one they spend the most time testing. HA is probably the most critical piece of software I run, so I want it to work, and I don't care about also running other stuff on the same system (other than addon's) because I can do that in a separate VM. Having spent years running it bare metal and in docker that certainly works fine, but HAOS made it a lot less effort to manage and has been very reliable when I ran it on a standalone machine and then when I moved it under Proxmox.
> I want to go the other way and say DO NOT use HAOS if you know anything about docker. If you have ANY experience working under linux/docker just don't bother with HAOS and save yourself the headache. You will have an incredibly better experience just running your HASS docker container by yourself.
If you don’t use HAOS you miss out on Home Assistant add-ons, which themselves sometimes integrate in Home Assistant.
If you don’t use HAOS you miss out on Home Assistant add-ons, which themselves sometimes integrate in Home Assistant.
You can install all of them as stand-alone docker containers.
Is there any documentation on how to do this, I've always wanted to try the voice related ones but there is no documentation to run them outside of the haos setup
Basically you need to run this docker compose file from below and enable "Wyoming" integration in HA (I think it'll detect piper & whisper and propose it automatically). Don't worry about picking model too much - you can change it later in HA UI.
version: "3"
services:
## wyoming
whisper:
container_name: whisper
image: rhasspy/wyoming-whisper
command: --model base-int8 --language en
volumes:
- ./whisper-data:/data
environment:
- TZ=Europe/Brussels
restart: unless-stopped
ports:
- 10300:10300
piper:
container_name: piper
image: rhasspy/wyoming-piper
command: --voice fr-siwis-medium
volumes:
- ./piper-data:/data
environment:
- TZ=Europe/Brussels
restart: unless-stopped
ports:
- 10200:10200I run with Docker and it has been fine for me, but one issue I have is that certain things aren't documented well. For example, when I played around with the voice assistant stuff, the documentation only explained how to set it up via addons. It took a decent amount of digging and trial & error to figure out how to set it up manually. Looking again, it doesn't seem much better now.
As a Linux systems engineer I’ve looked behind the curtain at HAOS and was very impressed by how well things are implemented. Been running it for years in KVM and have never had an issue.
The only thing I run into is that when HAOS reboots, or occassionally when I restart the core, the KVM host has a short disconnect of my Zigbee stick.
Love docker and have dozens of app containers running but so much easier to do the addins on HAOS
Counterpoint: I've been running HAOS on an RPi 2 and 3 for several years without a single issue, and I do use a z-wave dongle but no Zigbee. I only do basic stuff with it (a few automations for my z-wave thermostat and switches, AdGuard Home), but it's been rock solid for me.
I only had issues once, when I tried to run the Unifi Network Application addon. A RPi is not strong enough for that, but I just uninstalled it and moved on.
I only had issues once, when I tried to run the Unifi Network Application addon. A RPi is not strong enough for that, but I just uninstalled it and moved on.
i’d recommend buying “home assistant green”, it’s plug n play:
https://www.home-assistant.io/green/
https://www.home-assistant.io/green/
Low Cost Mini PCs https://news.ycombinator.com/item?id=41389931
Another "Been using RPi 4 for HAOS solidly for multiple years" anecdote chiming in here. Typically the SD cards are the unreliable bit, not the Pi itself.
You can boot and run a pi from a USB ssd, and now pi5 has easier nvme.
But yeah, then you're competing with a minipc. The pi5 now has niceties like a power button and you can battery backup the clock with a wired coin cell, but then it is more time and expense to get to what minipcs had basically forever.
But yeah, then you're competing with a minipc. The pi5 now has niceties like a power button and you can battery backup the clock with a wired coin cell, but then it is more time and expense to get to what minipcs had basically forever.
Yeah “easier nvme” requires buying a $40 hat and a special case with special fan because otherwise they interfere.
Which is crazy considering n100 boxes already have an nvme and a fan for ~$100
I've been using a Pi 3 for years and years, it's always been rock solid. The only problem was in the beginning, when I didn't use the official power supply, I'd get frequent brownouts, even with good bench power supplies. Apparently the Pi (especially older ones, not sure if they've fixed it now) had too much of a voltage drop, and needed a slightly higher voltage supply to work properly.
After that, zero problems.
After that, zero problems.
HAOS is absolutely terrible when it faces filesystem corruption. I faced this a few times when my HAOS image crashed. You can't even get it to fsck on boot when it happens. I think that's one big reason people on RPIs have issues. The FS is on an SD card, SD cards are flakey, and there's no good rescue path when the FS has issues.
I guess USB power is also historically not great on RPI. I haven't played with them in a few years but I remember needing powered hubs. That might explain issues with Zigbee and Z-wave dongles. Note also the '700 series' z-wave dongles have a lot of issues. You can update the firmware to fix some. Mine's been flakey and I'm on the latest firmware from ~2 weeks ago that's supposed to fix all of that.
I was running HAOS on VirtualBox, with the disk image on ZFS. I switched to running docker out of the same ZFS filesystem and it's much faster and more reliable, notably I don't get random filesystem corruption. Anecdote. YMMV.
I guess USB power is also historically not great on RPI. I haven't played with them in a few years but I remember needing powered hubs. That might explain issues with Zigbee and Z-wave dongles. Note also the '700 series' z-wave dongles have a lot of issues. You can update the firmware to fix some. Mine's been flakey and I'm on the latest firmware from ~2 weeks ago that's supposed to fix all of that.
I was running HAOS on VirtualBox, with the disk image on ZFS. I switched to running docker out of the same ZFS filesystem and it's much faster and more reliable, notably I don't get random filesystem corruption. Anecdote. YMMV.
> HAOS is absolutely terrible when it faces filesystem corruption. I faced this a few times when my HAOS image crashed. You can't even get it to fsck on boot when it happens.
I don't see this as being unique to HAOS, if a filesystem is corrupted in a certain way then _no OS_ is going to be able to boot.
There are distros that are specifically optimized for the Pi (with, eg specific logging choices [1]) that try to avoid problems (with trade-offs).
I've used something before (can't remember/find it now, but maybe thought it was in Yocto?) where there were 3 partitions: one was read-write used for persisting user data, and two were for the OS/apps. One would be live and mounted as read-only, the other was for the next system update using a blue-green deploy strategy. I think it also used RAM for log and temp files.
[1] https://dietpi.com/docs/software/log_system/
I don't see this as being unique to HAOS, if a filesystem is corrupted in a certain way then _no OS_ is going to be able to boot.
There are distros that are specifically optimized for the Pi (with, eg specific logging choices [1]) that try to avoid problems (with trade-offs).
I've used something before (can't remember/find it now, but maybe thought it was in Yocto?) where there were 3 partitions: one was read-write used for persisting user data, and two were for the OS/apps. One would be live and mounted as read-only, the other was for the next system update using a blue-green deploy strategy. I think it also used RAM for log and temp files.
[1] https://dietpi.com/docs/software/log_system/
> I don't see this as being unique to HAOS, if a filesystem is corrupted in a certain way then _no OS_ is going to be able to boot.
Theoretically true if you are very unlucky, however, that's not true at all for the vast majority of filesystem failures.
I am talking about failures where if I inspect the disk image outside the VM and fsck it, everything is fine.
Also, given that HA leans so heavily on docker, it would be a reasonable feature for it to rebuild some docker images should the disk damage them.
Traditional hard disk failures are common, but also, SD card failure is really common. If you've worked on a sufficiently popular mobile app you've probably seen tons of it. It's reasonable to plan for it at the application layer. To say nothing of at an OS layer. There's a very good reason why Unix traditionally ships with fsck tools and sometimes runs them at boot. Whoever designed HAOS not to do this made a big mistake, and I would hit this a few times a year in my old setup.
Theoretically true if you are very unlucky, however, that's not true at all for the vast majority of filesystem failures.
I am talking about failures where if I inspect the disk image outside the VM and fsck it, everything is fine.
Also, given that HA leans so heavily on docker, it would be a reasonable feature for it to rebuild some docker images should the disk damage them.
Traditional hard disk failures are common, but also, SD card failure is really common. If you've worked on a sufficiently popular mobile app you've probably seen tons of it. It's reasonable to plan for it at the application layer. To say nothing of at an OS layer. There's a very good reason why Unix traditionally ships with fsck tools and sometimes runs them at boot. Whoever designed HAOS not to do this made a big mistake, and I would hit this a few times a year in my old setup.
I’m not familiar with virtualbox, do you have any idea why HAOS on VB+ZFS was corrupting vs Docker+ZFS?
I wasn't sure. I had some kernel panics that I didn't dig deeply into, and I would sometimes use the image outside the VM to fsck it when HAOS would subsequently not recover.
I've also found pis to be unreliable in the long term. Even buying good SD cards doesn't help. It's always something. Broken storage, brown out (I'm using the recommended power supply), sudden lack of communication over the eth port, etc.
I've found that just getting an old toughbook is much more reliable for projects that don't require miniaturization.
I've found that just getting an old toughbook is much more reliable for projects that don't require miniaturization.
Counterpoint: my Pi 4 4gb booting a USB3 SSD drive has been working fine for years. The SD cards are what kill Pis
I mostly agree, but found that HA isn't too bad on Pi if you don't continuously update the versions even if it suggests. I had a lot of trouble keeping a stable system until I just ignored them until I really needed to install on new system, etc.
I've been using a raspberry pi 4 for 2 years with no issues. You need a good, clean power source or you can have all kinds of issues. Having good ventilation won't hurt. You also need a good sdcard that can handle a large volume of writes.
The problem is often that people use small MicroSD (8-16GB) that don’t support the number of writes to SQLite3 that HA does.
Have been using Western Digital purple 64GB MicroSD for years without problems (support the same number of writes as SSD)
Have been using Western Digital purple 64GB MicroSD for years without problems (support the same number of writes as SSD)
100% this, my rpi3 kept running out of ram running all the services I wanted on home assistant so I moved it to proxmox and use the roi+touchscreen as a dedicated web client for the interface now
Be careful with the beelinks though, I have one with a nice ryzen API that's basically useless because the USB gave out and it's a chicken and the egg problem trying to get Bluetooth on it. Haven't gotten around to attempt manually configuring Bluetooth on the SSD yet (from another computer) or otherwise fixing those ports
Be careful with the beelinks though, I have one with a nice ryzen API that's basically useless because the USB gave out and it's a chicken and the egg problem trying to get Bluetooth on it. Haven't gotten around to attempt manually configuring Bluetooth on the SSD yet (from another computer) or otherwise fixing those ports
Or a 2012 MacMini, $~90 on ebay. Quiet, small form factor, runs Linux.
I've been running hass for quite some time, for years directly in a python venv on a Pi2, then Pi3, and now happily on a Pi4 4GB for several years. Runs so well I decided not to upgrade to a 5. Use both zigbee and zwave.
Currently running in docker, which was a godsend when I migrated from Raspbian to NixOS about 18 months or so ago with no issues.
Have used an SSD wherever possible, perhaps that's why it's been so stable.
I use the GPIO, which is one reason I've stuck with the Pi!
Currently running in docker, which was a godsend when I migrated from Raspbian to NixOS about 18 months or so ago with no issues.
Have used an SSD wherever possible, perhaps that's why it's been so stable.
I use the GPIO, which is one reason I've stuck with the Pi!
I had problems when running HA on an RPi as well. It was never very snappy or stable in its connection with the Z-Wave network. I don't know if it was too much power being drawn by the dongle or what, but switching over to a mini ThinkStation that I got for cheap on Ebay solved the problem. Not only perfectly stable with the connection to the Z-Wave network but also just overall more responsive.
I ran it on RPI 3 and 4 with SSD for years and had zero issues. Now moved to the mini pc but RPI still hosting other stuff and works rock solid.
Been running HA and a couple other services on RPi 4 with old SSD and DietPi as the OS, behind tailscale for 2 years. It needs a restart maybe once in a blue moon, and it's back online in 1 min, that's it.
I've been running off a Raspberry Pi for years and it's been very stable. The main things for me were to use a good SD card, to use Ethernet instead of Wifi, and to also reboot the Pi daily via an automation.
Or buy an officially supporter Home Assistant Green for $99:
https://www.home-assistant.io/green/
Honestly, to be fair, You can buy two more powerful 1L dell optiplexes or HP prodesks for this cost. i5-7/8xxx with 8G/16G ram often go for $40-50 on eBay.
Install proxmox and HAOS and you can use the rest for other stuff.
Install proxmox and HAOS and you can use the rest for other stuff.
How’s the power consumption compare? If you don’t need more powerful it might not be the bargain it looks like.
Idle wall draw is approx 4W, average is approx 15W under load. Hovers around 10-24 mostly tbf. These are mostly i5-xxxxT CPUs. They have TDP of 35W.
And honestly, if you're in many states of the US - power's consumption is not necessarily an issue. Electricity is dirt cheap in the States, but I see your point.
And honestly, if you're in many states of the US - power's consumption is not necessarily an issue. Electricity is dirt cheap in the States, but I see your point.
I've been using a Home Assistant Yellow, which is running on a Raspberry Pi CM4. Bit more specialized than the Green I think.
Recommend just running it on a VM in proxmox or similar
Had rpi3b with HA for nearly 4 years now without any problems at all, not sure where your issues come from but I feel like mine is cake.
I'm about to buy a Pi 5 for a Pi-hole. Does the same advice apply to that?
Pis are basically toys. They have a function, but it isn't running servers.
I use an old Mac mini.
I use an old Mac mini.
I've pip-install it in my homeserver (a small celeron with enough ram and storage) BUT I have a note to all HA users and devs: why the hell keep insisting on the WebUI for configuring, it's NOT reproducible nor simple.
Oh, of course, for a casual user it's simple, unfortunately no casual users know about HA or how to physically integrate HA in a smart home, so the idea of making a generic end-user system it's a failure in principle, no matter the implementation. Aside nothing is forever so even if for some it's easier to go for a WebUI, when it will break, because it will (and with HA I've experienced issues various time, an update at a time) you need to waste big time instead of simply adapting a damn simple config.
Hell, even NixOS with it's damn nix language is enormously simpler than the YAML hell + WebUI of HA. And yes, NixOS is far more stable and simple than playing with an entire distro just to run a Pythonic app.
Oh, of course, for a casual user it's simple, unfortunately no casual users know about HA or how to physically integrate HA in a smart home, so the idea of making a generic end-user system it's a failure in principle, no matter the implementation. Aside nothing is forever so even if for some it's easier to go for a WebUI, when it will break, because it will (and with HA I've experienced issues various time, an update at a time) you need to waste big time instead of simply adapting a damn simple config.
Hell, even NixOS with it's damn nix language is enormously simpler than the YAML hell + WebUI of HA. And yes, NixOS is far more stable and simple than playing with an entire distro just to run a Pythonic app.
what?
HA is a hell of YAML and more and more things doable only from the WebUI, this means you can't nor automate nor document your setup, so you can't replicate it.
It's a common issue in modern software: devs are so inhabited to use cloud stuff not knowing what's behind they are mentally unable to comprehend why doing so it's a totally absurd thing. Software MUST REPLICATE with easy, your home infra should be replicated from scratch without much more than booting a custom live. You shouldn't need to re-do the same step again. In *nix we have this concept since decades, those from Windows land simply do not understand because replication for them it's a myth.
Give NixOS or Guix System a try and you'll understand: your setup is just a single or few text files, a command read them and generate a new deploy for you. No need to traveling ever changing UIs by hand, no YAML hell.
At another level it's the same for those from stratis/mdraid/lvm/btrfs vs zfs. Zfs is done for the operation, as a storage should be, flexible, simple, effective, the others are a pile of CRAP those who develop them do not even recognize why, because they have no real idea of automation even if they are core devs of some very low level system stuff. Another example: "systemctl status something" is a CLI designed by some who have no idea of the real world needs, otherwise it would be "systemctl something status" because typically when you look for a service status you might want thereafter reload/restart/stop it, if not the word exchange does change nothing to you. These are the sign of devs born on Windows that have never go behind their desktop or someone else cloud service so they have no idea about how to build an infra.
For HA most of it's devs I suppose have no p.v. at home, or they have no personal automation to maximize self-consumption so they do not know how many lines of YAML and wasted time on their UI such design imply. Instead with "dumb end users" in mind, people who NEVER EVER use HA seriously simply because they lack too much knowledge even if someone gives the a ready made system, they focus on "visual code" like Node Red, augmenting them messiness level while still no option exists to establish sensor data retention and pruning, you need aside InfluxDB so another dependency for next to nothing and an issue at a time HA became just a part of a system with NO UI at all because to use InfluxDB you need for instance Grafana and so you entirely replace HA slick UI. In the end you have done A MONSTER to handle simple automation of many stuff due to wrong design ideas, while it could perfectly be a single simple app, HA itself, for instance exposed in python directly.
At some level many start to understand and from UIs they tend to REPL, from disappearing menus to "dashes", from widgets to NotebookUIs for some scientific software, LLM prompts and so on, but even with that most still have to understand a decades old IT principle.
It's a common issue in modern software: devs are so inhabited to use cloud stuff not knowing what's behind they are mentally unable to comprehend why doing so it's a totally absurd thing. Software MUST REPLICATE with easy, your home infra should be replicated from scratch without much more than booting a custom live. You shouldn't need to re-do the same step again. In *nix we have this concept since decades, those from Windows land simply do not understand because replication for them it's a myth.
Give NixOS or Guix System a try and you'll understand: your setup is just a single or few text files, a command read them and generate a new deploy for you. No need to traveling ever changing UIs by hand, no YAML hell.
At another level it's the same for those from stratis/mdraid/lvm/btrfs vs zfs. Zfs is done for the operation, as a storage should be, flexible, simple, effective, the others are a pile of CRAP those who develop them do not even recognize why, because they have no real idea of automation even if they are core devs of some very low level system stuff. Another example: "systemctl status something" is a CLI designed by some who have no idea of the real world needs, otherwise it would be "systemctl something status" because typically when you look for a service status you might want thereafter reload/restart/stop it, if not the word exchange does change nothing to you. These are the sign of devs born on Windows that have never go behind their desktop or someone else cloud service so they have no idea about how to build an infra.
For HA most of it's devs I suppose have no p.v. at home, or they have no personal automation to maximize self-consumption so they do not know how many lines of YAML and wasted time on their UI such design imply. Instead with "dumb end users" in mind, people who NEVER EVER use HA seriously simply because they lack too much knowledge even if someone gives the a ready made system, they focus on "visual code" like Node Red, augmenting them messiness level while still no option exists to establish sensor data retention and pruning, you need aside InfluxDB so another dependency for next to nothing and an issue at a time HA became just a part of a system with NO UI at all because to use InfluxDB you need for instance Grafana and so you entirely replace HA slick UI. In the end you have done A MONSTER to handle simple automation of many stuff due to wrong design ideas, while it could perfectly be a single simple app, HA itself, for instance exposed in python directly.
At some level many start to understand and from UIs they tend to REPL, from disappearing menus to "dashes", from widgets to NotebookUIs for some scientific software, LLM prompts and so on, but even with that most still have to understand a decades old IT principle.
Sir. You Win teh Internets today. This has been my gripe with HA for the longest time. That YAML / GUI-only / etc. approach is just atrocious.
Unfortunately it works well enough, and there are little or no alternatives to it as far as I can tell. Were there a reasonable alternative, with a configuration as an actual code (YAML isn't), I would dump HA in a heartbeat. I mean I could even live without the GUI - just configuration as a code, and stable support for Zigbee (and BLE etc devices). But then again HA mostly works. And if it works, then...shrug.
My use case is mostly to be able to 1) monitor/understand our electricity consumption, 2) be able to turn off all/selected electrical devices when leaving house etc., 3) automatically lower/raise outside shutters based on weather/where sun is(!) to keep house cooler, 4) and as a bonus, have leak detectors send me a text if there is a leak. My setup is some 30 zigbee smart switches / sockets, couple of IKEA badring leak sensors, solar inverter and something zigbee in main electric panel to get total electric consumption. And five door/window sensors (that aren't really used for anything, but you know how one goes down the rabbit hole with these things...).
How I've made it somewhat manageable is that I run it in a following manner (first in Pi5, now in N100 -- no difference between those observed regarding HA):
- have /opt/homeassistant/config mounted to zram
- on boot unpack /opt/homeassistant/backup/latest.tar.zst -> /opt/homeassistant/config
- run HA from docker (where /opt/homeassistant/config is now on zram)
- cron will make a backup of /opt/homeassistant/config weekly (or I can run backup manually if I've made changes/addedd devices) and then these are backed up 'offsite'.
So now whenever HA goes bonkers, or more likely I've messed something up with it, end result being the same, I simply roll back to some earlier known good configuration. Docker is wonderful in this regard. Really, I don't know how else people live with the HA, other than backing up their entire config, and then re-installing.
Unfortunately it works well enough, and there are little or no alternatives to it as far as I can tell. Were there a reasonable alternative, with a configuration as an actual code (YAML isn't), I would dump HA in a heartbeat. I mean I could even live without the GUI - just configuration as a code, and stable support for Zigbee (and BLE etc devices). But then again HA mostly works. And if it works, then...shrug.
My use case is mostly to be able to 1) monitor/understand our electricity consumption, 2) be able to turn off all/selected electrical devices when leaving house etc., 3) automatically lower/raise outside shutters based on weather/where sun is(!) to keep house cooler, 4) and as a bonus, have leak detectors send me a text if there is a leak. My setup is some 30 zigbee smart switches / sockets, couple of IKEA badring leak sensors, solar inverter and something zigbee in main electric panel to get total electric consumption. And five door/window sensors (that aren't really used for anything, but you know how one goes down the rabbit hole with these things...).
How I've made it somewhat manageable is that I run it in a following manner (first in Pi5, now in N100 -- no difference between those observed regarding HA):
- have /opt/homeassistant/config mounted to zram
- on boot unpack /opt/homeassistant/backup/latest.tar.zst -> /opt/homeassistant/config
- run HA from docker (where /opt/homeassistant/config is now on zram)
- cron will make a backup of /opt/homeassistant/config weekly (or I can run backup manually if I've made changes/addedd devices) and then these are backed up 'offsite'.
So now whenever HA goes bonkers, or more likely I've messed something up with it, end result being the same, I simply roll back to some earlier known good configuration. Docker is wonderful in this regard. Really, I don't know how else people live with the HA, other than backing up their entire config, and then re-installing.
Running it on my home-server via pip (no containers for me, thanks) I do not try the "kind-of-firmware approach, just different zfs volumes, with auto-snapshots and backups for bin (python venv), data and config. Mostly I have had issues upgrading HA but still even with my config at hand, written in org-mode and tangle-ed anyway to be less of a hell and to embed docs/references in the YAML hell, the main issue came from integrations only configurable from the WebUI. In most case it's just a matter of remove the configured part from the running config, add the integration from the WebUI, add back the config, reload etc. But it's still a PAINFUL process. Less hard than configuring via NixOS, but still hard.
Just as an example (no ads) https://kfx.fr/posts/2024-02-21-shellyfloodandha/ how is possible to demand such amount of line to get a damn flood notification on mobile?
As you rightly say HA works well enough and have less issues than OpenHAB, but as long as something less yaml-illish and webui-tied appear I'll switch instantaneously. My setup have probably far less devices than you, bus some have a gazillion of sensors (i.e. my main battery inverter a Victron MultiPlus with ECV charging station have at least 1248 lines of yaml, NOT counting the template code for many sensors usages) while it could be a simple python data structure of 1/5 of the size. My main usage is just monitoring and a bit of automation to maximize self-consumption like piloting hot water heater, running A/C etc, videosurveillance and co are managed separately.
Just as an example (no ads) https://kfx.fr/posts/2024-02-21-shellyfloodandha/ how is possible to demand such amount of line to get a damn flood notification on mobile?
As you rightly say HA works well enough and have less issues than OpenHAB, but as long as something less yaml-illish and webui-tied appear I'll switch instantaneously. My setup have probably far less devices than you, bus some have a gazillion of sensors (i.e. my main battery inverter a Victron MultiPlus with ECV charging station have at least 1248 lines of yaml, NOT counting the template code for many sensors usages) while it could be a simple python data structure of 1/5 of the size. My main usage is just monitoring and a bit of automation to maximize self-consumption like piloting hot water heater, running A/C etc, videosurveillance and co are managed separately.
I've given up on Home Assistant because of this. Particularly because since I've switched to NixOS I really don't want to be arsed reconfiguring stateful crap from the start every time I make some change that requires a reinstall.
Sadly, I've yet to find a viable alternative.
Sadly, I've yet to find a viable alternative.
I'm still on HA since as you I have to find a viable alternative, the saddest thing is how many, dev included, do not understand the above rant, do not even have a damn idea what we are talking about...
Can it automate a cutout of Michael Jordan attached to a model train set?
You jest, but with an ESP32 flashed with ESPHome and a few dollars of electronics to regulate the power, I think controlling model trains would actually be quite doable. Your biggest challenge is probably dealing with network/scripting latency for events that need to happen in quick succession, like when dealing with switches.
Or, if you consider Lego DUPLO trains to be model trains, there's this: https://community.home-assistant.io/t/lego-duplo-train-contr...
Edit: there's also this https://github.com/aaron9589/esphome-for-model-railroading for the more serious model railroad enthusiast, though I'm not 100% sure if that actually controls the trains themselves (or just the switches and lights)
Or, if you consider Lego DUPLO trains to be model trains, there's this: https://community.home-assistant.io/t/lego-duplo-train-contr...
Edit: there's also this https://github.com/aaron9589/esphome-for-model-railroading for the more serious model railroad enthusiast, though I'm not 100% sure if that actually controls the trains themselves (or just the switches and lights)
In many cases, a simple off-the-shelf smart plug would suffice.
That's why I try as hard as I can to find either truly "dumb" devices with mechanical switches vs momentary buttons or devices that remember their last state after A/C power is restored. Hard to figure out the second option though without trying it unless a review happens to mention it specifically.
Awesome. The Home Assistant and related (ESPHome, Voice Assistant, Music Assistanc) communities are amazing and there is just a crazy amount of projects one can just pick up and use.
It could also automate ordering pizza delivery and the tipping process to "Keep the change, ya filthy animal"
There's a dominoes pizza integration in home assistant
There are dcc systems that run on Arduino or raspberry pi, and expose an API interface. Could control one via home assistant
I used this last week! I was out of town and a friend texted me letting me know the lights in my house were on. I got such a sense of joy in knowing that it was working as intended.
I use a normal automation to turn on the lights every day at sundown, and to turn off the lights every night at ($BEDTIME + 1hr), just as part of daily life. I don't need anything tricky to simulate that pattern when I'm traveling; I just don't disable the automation. I wonder how many people using HomeAssitant for their lights are manually turning lights on and off all the time. I would think most people would set up a daily or weekday + weeknight schedule and be done with it.
I use a rule-based automation in OpenHab (similar to HA) to randomly pick a light from a group and toggle it after a random interval, and it repeats the process every 10 minutes from 4pm to 11pm. I find this better than relying on prior history since there is no guarantee that my prior pattern of occupancy would be applicable to a vacation period. Better to just randomly cycle random lights - that will confuse them ;-)
We have some automations, but mostly use homebridge and Apple Home scenes controlled by presence, smart switches, Siri, and the app. I'd imagine that's 10x-100x more common than pure time based automations based on the HA fora.
I did this for a long time with timer switches that could be programmed similarly, and switching to HA wasn’t some huge change, it was just nicer. I had to periodically make sure the clock was correct on them, as they would drift a few minutes, and the interface itself was via small LCD screen and buttons.
HA is just a nicer experience, but I wouldn’t say it (or any home automation) is a “need”. It’s better seen as something for tech people to tinker with once they’ve settled a bit in life and are looking for something to do.
HA is just a nicer experience, but I wouldn’t say it (or any home automation) is a “need”. It’s better seen as something for tech people to tinker with once they’ve settled a bit in life and are looking for something to do.
I'm guessing you have to do a bit more in maintenance for your Home Assistant instance than set the clock every once and a while?
Not much more than just clicking an update button once in a while. But that’s a standard workflow most people are used to. Updating the clock on the standalone timers has to be done using a tiny LCD screen with an esoteric menu system while holding a manual/pamphlet that’s printed in less than 6pt text. It’s not something you do often enough to remember the procedure.
Of course you can make things more complicated if you want to in HA, or you can set it and mostly forget it if you just use timers.
Of course you can make things more complicated if you want to in HA, or you can set it and mostly forget it if you just use timers.
Exactly! What’s the point of that if most of people have evening lights and blinds automated to run daily.
Hm I'm not sure if this helps.
Because thieves will first knock on doors, even for tens of minutes. Ring etc.
Normally people will open and thief will say some BS and go away.
Cameras with backup power and backup internet connection is your first priority.
Cameras with backup power and backup internet connection is your first priority.
Funny because I never answer my door when anyone knocks. If you're knocking on my door it's because I don't know you, which means I probably don't want to talk to you. Anyone who knows me knows to call or text before they come by.
What if it's like, a utility company trying to warn you they'll cut off power/water/whatever in a few minutes because of emergency works?
I have kids, neighbors have kids, door is knocked on all the time.
You don't even have to have kids.
When I was at my last house, I didn't have kids, and people would knock on my door every day. It was because my block was full of neighbors who were friendly and nice to one another, and not shut in their houses like hermits.
The way many people in the suburbs live these days, they'd might as well live in windowless metal shipping containers.
When I was at my last house, I didn't have kids, and people would knock on my door every day. It was because my block was full of neighbors who were friendly and nice to one another, and not shut in their houses like hermits.
The way many people in the suburbs live these days, they'd might as well live in windowless metal shipping containers.
You're so right. If you life in a neighborhood that even vaguely resembles some kind of community then you're really really lucky!
Simulated presence in our home: Motion-triggered lights and a cat
Sure, but cats sleep around 35 hours a day.
Fortunately, presence simulation is only needed at dusk/night - when cats have their zoomies.
This would be a dead giveaway that I wasn't home; my cats tend to get the zoomies in the small hours.
I need some of those cat-sensitive motion triggers.
Old school hardware stores have them. They screw in between the lightbulb and the lamp.
My z-wave sensors of various brands tend to recognize my cat. Most of them have a "pet" setting which is supposed to ignore them, but then I would lose my entire security system.
Slightly related, please forgive the offtopicness: has anyone implemented a DIY UWB location base + beacon/tag?
I ask because my neurodivergent wife loses things, and often Tile either doesn't work or isn't load enough. I read that UWB promises 10cm² or 10cm³ accuracy, which would be ideal for finding lost stuff.
I've seen a couple of commercial offerings, but they didn't have pricing.
I ask because my neurodivergent wife loses things, and often Tile either doesn't work or isn't load enough. I read that UWB promises 10cm² or 10cm³ accuracy, which would be ideal for finding lost stuff.
I've seen a couple of commercial offerings, but they didn't have pricing.
I don't know if it will count as DIY, but take a look at LEGIC and their devkit for this. We (seam) work with them and I recall seeing a couple of startups doing demo's of their UWB solution at their LEGIC Connect conference.
I used some Decawave kits ~a decade ago and they worked pretty well... however if you want to DIY something as usable as Airtags I think the main struggle would be getting the package compact and with low power consumption (unless you want to track large things and are fine with a chonky battery)
The generic stuff in the "Find My" ecosystem works quite well. It's not DIY, but most things have UWB finding that works whole-house for me.
Growing up, my parents always made sure the radio was on, slightly louder than a normal volume, whenever we left the house. Funny seeing how that idea of presence simulation has evolved.
This has been on my list of things to do for a while, saves me a job. Thanks for sharing.
It's amazing _but_ do NOT use a raspberry pi to run it. Save yourself a ton of headaches and buy a mini pc (there was a list of used mini pcs posted here yesterday from ebay). Also I recommend using HAOS (or whatever the "we install and run the whole OS" option is called) so that you can use things like plugins without messing around with docker. I love docker but trust me, life is easier on HAOS.
I liked HA but felt like it wasn't really "stable". I used a Pi 3 for a while, then a Pi 4 decked out (highest ram, NVME storage, super nice case, etc) and still felt like it was unstable. I chalked this up to HA but then rolled the dice on a Beelink mini pc and it has been rock solid ever since. Also don't be misled by the lower price of the Pi, I paid more for my Pi 4 setup than the Beelink (or about the same).
I blamed everything from the Zigbee/Z-wave dongles, to HAOS, to HA itself, etc but in the end it was RPi. The 4 was the last Pi I'll ever buy.
EDIT: I was in a hurry and didn't add my normal disclaimer when I talk about the RPi's:
Yes I know some of you have a Pi 1 that been running you entire life since it first came out and you think I'm full of crap. I've owned every Pi 1-4 and never been truly happy with them. I bought them "raw" and sourced all the parts myself, I bought high-end (at least in price) kits with everything included, I bought all official accessories (like power), they always were just that little bit unstable.
It would work great for days/weeks then randomly not be reachable (wired or wireless). I spent just shy of $200 for my last "builds" which included a NVME drive (240G, lest you think this is where the cost was), RPi case, RPi NVME hat, RPi 4 8gb model, SD card, power, etc and the result was still instability. I don't know what to tell you. Maybe I'm a moron but my experience with them has not been great. That said I want to love them and I loved my RPi 1B even with all it's warts, a $35 "credit card sized" computer was awesome. Maybe I just don't want to tinker as much anymore and value stability.