You can hook up a cheap dongle to expose the stats in an app. For instance, we use:
https://www.homewizard.com/nl/shop/wi-fi-p1-meter/
This meter also exposes an API on the local network. I have written a small driver for the SmartThings Hub, so that you can get the stats/graphs in the SmartThings app as well (we use a SmartThings hub for Zigbee/Z-Wave devices):
Does that support monitoring each power circuit separately?
A natural integration would be with Home Assistant. I’m not sure if the Earu breaker has an OOTB integration with HA yet, beyond doing something like Zigbee2MQTT and configuring entities for readings. It’s a good pattern though - integrate meter with your automation hub, let the automation hub push the images to displays, for meter and everything else.
Hey dude, fix your "open in wallet" button when paying with BTC. The link is janked up.
Otherwise, it works great. See https://imgz.org/iAB4tgaJ/
I also bridge my utility (ComEd's) pricing feed to prometheus (https://github.com/kklipsch/comed_exporter). Between those 2 I get pretty good whole home utilization and pricing info graphed into Prometheus (and thus into Grafana).
Price is generally a dollar figure for 1000W per hour.
Victoria metrics/ grafana is supplanting our industrial historian, which is admittedly not a best in class product - I am sure osi pi is better
The clones I can find are roughly the same price as the "original" hardware.
ATM90E32AS seems to be ~$1 per channel on JLCPCB, so I'd imagine this could be pretty cheap with SMT assembly. My use case is like ~60 circuits.
Per plug monitoring is cool however for getting specific devices on a circuit.
(Short video about the setup: https://www.youtube.com/watch?v=-tcbJCvuJG8)
I just did a new video on building a 68030 computer that I suspect will have a much smaller audience!
I've had perfectly lovely reliability with wifi smart devices in my mixture of zigbee/wifi at home, such that I don't really have a preference. Except for one cheap ESP8266-based wifi relay module that had some liquid damage (not the module's fault), and the LED driver in my very first RGBW light bulb finding death after being used for a few years (a common-enough tale regardless of connectivity choice), they seem to Just Work.
It's all semi-random brands of devices, bought over time.
I'm not doing anything particularly fancy with the network itself: It's just a couple of hardwired dual-band Mikrotik access points, with one upstairs at the back of the house and one downstairs at the front of the house (perhaps non-obviously, on non-overlapping channels). A Pi 4 with OpenWRT quietly does the packet-slinging.
Like in many other places, the 2.4GHz band is approximately ruined where I live these days. It's noisy and slow. But it all works well enough to reliably toggle a relay on or off, at least.
Am I just lucky? Are others just unlucky? Or is there an actual pattern here?
(i work at Grafana Labs)
Traditional scada systems have such brutal plotting abilities they are ripe for disruption
https://grafana.com/docs/grafana/latest/panels-visualization...
there's some initial movement towards "press Canvas element -> invoke HTTP api call":
https://www.youtube.com/watch?v=T6fg1TpfBUg
we added streaming/websocket data sources a few major versions back.
i'm hoping to make something more standardized and pluggable like data sources.
since IoT devices have limited storage, usually the metrics are dumped into another system like Prometheus. but that Prometheus data source used plotting cannot be used to control the device, which will have another endpoint and another API, so we need some kind of concept of data sinks. at least that's my idea right now, allow data links configured in the panels to poke some "data sink" with values that are available in the DataFrame or custom-entered into the UI, like we do with traceID for Exemplars, etc.
I also have another esp32 at my elderly relatives house with a pir sensor connected to it, it's also sending the movement data to a different sheet on the google sheets site, so that i can monitor some sort of movement.
i'm i expecting google to discontinue this service at anytime - yes, but its working for now. you can write and read data from the google sheets via json via the esp32, not very inutitive but doable (and free!!)
I think it makes more sense to use “dumb” OTS circuit breakers in your house and augment with add-on monitor than combining the capabilities into a tightly-coupled single device.
My latest automation: when the white noise machine is on for the baby, the doorbell volume is turned down.
you can "simulate" power of fairly stable appliances.
Then you chart that in a nice Sankey chart or in standard charts and enjoy
So I can just take my EspHome plug and very quickly generate a standard set of mapping values for voltage and wattage.
The level of integration you choose is entirely up to you. I don't do this kind of thing much, so I'm OK with kludging together a test rig as-needed with a handheld meter and tearing it apart when I'm done. This makes good use of my own time and tools, according to my personal proclivities.
But if I were doing it often, then I might buy the equivalent of the HOPI meter that Big Clive uses in many of his videos. It displays current and voltage, multiplies them to get power, and also displays power factor -- concurrently, on separate digital displays, in real time.
Or I might build something: A box with a current shunt with some panel-mount meters and appropriate connectors would not be too challenging to put together in an afternoon with parts from Amazon and Lowes, depending on one's ability and desire to deal with sheet metal at home. (I use galvanized steel handy boxes and cover plates from Lowes for all kinds of small-ish stuff. They're cheap, common, and durable-enough.)
Whatever the approach, a simple space heater with multiple literal-speeds seems like a cheap and useful way to make it happen unless you're trying to automate every part of it.
(But by then, making a dumb multi-speed space heater into a "smart" multi-speed space heater that can be activated programmatically with software like ESPHome and some relays is probably pretty much a no-brainer, isn't it?)
For instance, their overvoltage protection might not align well with what the local regulations say. For example, in my region of EU, the upper voltage tolerances are such that 264V must trigger an instant poweroff, and also anything producing power must shut off if the average voltage over the last 10 minutes was 253V or more. However, TuYa sockets which pretty much are the only in-wall variety I was able to find on the local market, shut off at 260V. This tends to be somewhat problematic in an area saturated with PV installations, like the one I'm living in.
This problem is compounded by the fact that the reported measurements of sockets sitting on the same phase tend to differ quite a bit. Some sockets tend to overstate the voltage compared to neighboring sockets sitting on the same wires. Thus, they shut off when they think it's 260V, while it might just as well be 255V.
Just saying that if you put lots of those in your walls, you might suddenly find yourself in a need to prepare some automations to try and bring the sockets on once the voltage is back to normal. This particular variety of sockets won't come back on after the voltage drops.
Mine only gives me a month-to-date, end of month for billing, and month-over-month for the last two years (plus the outside temperature for comparison).
I don't know if there's an API or something to get almost-current data.
Wifi is just not meant for this use case, it will be unhappy if you start adding a lot of devices, and it will slow down your main use of WiFi for your phone.
Note: Powerline ethernet should not be confused with Power Over Ethernet which is perfectly fine.
Looking for Prometheus and Grafana on the cloud? Check out GreptimeCloud! https://greptime.com/
I think the key differences are in cloud requirements, control, and granularity. Price appears higher than Vue, though it's not when considering that Shelly is far more capable in all of the above categories.
The Shelly 3EM, which I use for split phase monitoring (in the US) at the meter is $109. That's not bad for its capacity, capability, and build quality. Mine is outdoors though enclosed (necessarily) so endures some pretty extreme temp swings and humidity changes. There is no cloud requirement, and it offers contactor control.
The Vue 2 from Emporia is built for a single indoor panel, provides no control over the circuits, and requires the cloud to operate unless you get out the soldering iron and reflash it with ESPHome, which isn't horrible, but the OOTB cloud requirement is your starting point. (I think that's still the case, but if I'm wrong, happy to be corrected)
For Shelly, their additional clamp solutions are all high-amp (50-100+) so not really designed to be put on individual circuits, especially at $50 per. You might use these on whole panels, breaking your whole house calculation down into zones by panel or monitoring high-amp devices.
If you tried to replicate the Vue with only these devices from Shelly, then yes, it would be an order of magnitude more expensive. But I don't think that's a good way to use them or the right way to replicate the Vue capabilities.
For the high-grained monitoring, it's hand-in-hand with control. Shelly's deployment model for fine-grained resolution is to put power metering down closer to the consuming devices, and with it, a relay for integration into home automation. You can add power metering along with control to outlets, switches, or hard-wired devices in house with things like the 1PM Mini G3 for $13 per.
In this sense, you get far greater granularity than something like the Emporia Vue which can get no higher resolution than a whole circuit. Here again it must be stressed that with Shelly, there's no cloud requirement for that price and you're also getting remote control of the power distribution. On the balance, you're getting far more for your money with this approach.
For my needs, I combine Shelly's approach with some cheaper sonoff/tasmota plugs with power metering for things like the washing machine (alarming mostly). But for more critical devices or always on devices (like freezers), or switched devices like ventilation fans or lights, I think the build quality and deployment model of the Shelly devices is a better fit.
But definitely different target audiences. If the Vue is the right fit, it's the right fit.
And that they have done.
Just about to try some ikea zigbee sockets, seem cheap(7e) in comparison. I hope I can also get them working command line based, just trying to setup a sonoff usb stick with some python package (bellows) as we speak.
[1] https://hackaday.com/2023/11/03/just-how-dodgy-are-cheap-usb...
You need to open it to flash it the 1st time.
There's at least one unused accessible GPIO. On one I soldered an DS18x20 temperature sensor. Now it controls the heating in my shed based on the measured temperature stay above zero degrees in the winter.
I want to buy more and they don’t seem to be available anymore.
HA is great, but it's not the answer to everything
HA can export data to Prometheus. Setting up and running HA is much easier than figuring out how to get a set of different smart devices to export metrics to Prometheus/Influx. Let HA deal with that.
I live off grid, so energy monitoring is a big deal for me. HA is fine for “at a glance”, but if I want any kind of detail, I use grafana. I actually have my old openhab instance still running purely as I can’t be faffed setting up all the piping from MQTT into influx again.
It’s also possible to integrate the usage over time using a dynamic time window to get Wh figures from wattage, which is enormously useful for me, and is more accurate than the figures HA gives in their power system.
HA is dead useful for getting alerts when the laundry finishes, though - dumb machine, smart plug, look for a sudden drop in power. Also does all our climate control.
So different tools for different jobs.
The Home Assistant authors' hostility towards simple native distributions is now a show stopper for me. Long term reliability is more important than quick initial setup.
Demanding the authors who gave you the software for free also provide support for an installation method they've offered up with no support is a bit ridiculous, don't you think?
That attitude is what causes open source projects to die though...
There seems to be a sonoff usb stick that might act as a hub and allow command-line monitoring of all devices, should be perfect for feeding into grafana/prometheus.
It is entirely possible to meter each individual circuit, either with CTs and a meter or (gross simplification) special breakers that have metering capability built-in.
I was looking at the canvas element to do an electrical single line diagram.
I see a potential for some integration and/or idea sharing here. But it is also important to understand that the set of people who want to fiddle with their homes is much, much larger than the set of people who (are able to) program. Which is why HA and the likes are so popular.
1: the slots/clamps are small which makes fitting 4mm2 wires a chore already. 6mm3 is impossible. 2: the overcurrent protection is very trigger happy. Due to solar panels in the street that voltage can vary significantly. Apparently the charger doesn’t always keep up exactly resulting in a current of 16.0001A which is more than the limit of 16 and poof, off it goes. Not sure whether this is an actual fault in the charger or some rounding error.
I recall the online requirement was for some ntp server requests that cant be disabled.
https://github.com/magico13/ha-emporia-vue
You can do mains only or every circuit
https://shop.emporiaenergy.com/collections/in-panel-energy-m...
I haven’t had a single device that worked reliably. Some worked fairly consistently, but only after a long (and variable) delay. Many others failed to work often enough that, combined with the delays, the workarounds became the normal way of using things.
At this point I’m running basically everything over Z-Wave (via Home Assistant) and it’s been rock solid for me. Especially with the ability to set up direct associations, things like “this dimmer’s state should be synchronized to that dimmer” are very responsive and reliable, not involving my controller or Home Assistant at all.
Hard to say whether you’re lucky or I’m unlucky—most people having a good experience aren’t going to take to the internet to start a crusade about it—but I do occasionally see someone recommending or saying that Z-Wave or Zigbee has been reliable for them… I think yours is the first I’ve read where someone’s been happy with WiFi.
And yes, you're describing a very quiet environment in terms of outside interference. I'm seriously a little bit envious of that.
One thing that I am doing differently than what you were doing is this: I'm not isolating my smart-widgets to their own wifi access point, as I suspect most people also are not (since "most people" just have a single access point/all-in-one router for everything).
I built my little wifi network to have what I feel is good coverage in and around the whole house, with the intent that all devices (dozens of them) would use that same wifi SSID.
As an unintentional result of this combined network, if/when there's a problem with the do-all wireless network, I'm pretty likely to notice right away because things like my phone and my laptop won't work like they did yesterday.
And wifi problems have happened for me: For instance, before I went 100% Mikrotik, I was using an old once-fancy Asus router with third-party firmware as a combination of access point and switch for part of the house. It became increasingly unreliable as the years ticked on for whatever reason, and always came back to life after a quick reboot, but it eventually would turn stupid again anyway.
And whilst it was being stupid, various things would indeed break: The lights wouldn't turn on/off, or I'd see that my phone was using cellular data instead of wifi, or I'd say "Hey Google" and get "I can't connect to your Wifi" as a response. Madness, insanity. (And then I'd go unplug that router-shaped Asus access point for a few seconds, plug it back in, and things would be fine after a few minutes -- every time.)
But I have not at any time blamed the smart end-point devices (the wifi light bulbs, the switched outlets, the whatevers) for what was clearly -- in my case -- an infrastructure problem. (And having a particular old Asus router-box turn funky isn't indicative of a wifi-specific problem, either -- it's just indicative that this hardware had become increasingly broken over time.)
So my initial assumption is definitely going to be that the nearly identical setup except only serving a handful of low bandwidth devices is going to be just as solid.
That would seem to be a safe assumption given I’ve no noticeable missing data points from the $700 German air quality sensor that I’ve been recording for years and is connected via that access point. It’s moved to various rooms and points throughout the house as demand dictated without issue.
It would seem to be the case given I can pull up a feed from the WiFi IP camera I hooked up and pull it continuously with no latency or dropped frames whenever I want.
If I have an infrastructure issue, it’s one that is curiously selective about cheap IoT hardware while ignoring whatever other random stuff I hook up.
After a decade of installing MikroTik networks in hotels, condo buildings, and office buildings supporting all manner of nonsense you can take my word that there is a strong, reliable, WiFi network connection available at any point inside my house… or you’re welcome to come by with whatever diagnostic gear you’d like and tell me how it’s broken. I’d love to be able to make good use of some of that wifi IoT stuff!
Electrical wiring of any sort are all antennas to varying degrees, transmitting and receiving electromagnetic signals. Most mains electrical wiring is also unshielded, meaning they readily transmit and receive electromagnetic signals.
Powerline ethernet basically puts ethernet data on mains electrical wiring by utilizing the bands that aren't used for carrying power. This data is very, very noisy in electrical noise terms, and because most wiring also acts as an antenna that noise also gets broadcast everywhere.
Simple electronics like your coffee machine or microwave oven won't care, but more sensitive electronics like radios can in turn receive interference from both the power line and the noise broadcast into the air.
If anyone chimes in and says they've been running Home Assistant from nixpkgs (where I am now) for several years with no hiccups, then I will certainly reconsider my opinion. But based on my experience and what I've continued to read since, it feels like trying to do that is an uphill battle. One I'm not looking to take on, especially for automation I'm relying on.
YOU believe he should support this anyway, because of various "we promise end-users won't reach out to you" which is comically incorrect because history has shown repeatedly that a user's first step when something is broken is to google package_name broken - which will absolutely turn up the author's name.
BECAUSE he doesn't want to support his software being repackaged in a way he believes isn't supportable, you're upset. You want him to support your unicorn config because that's what you want to do, and his refusal to comply makes him a bad person.
Thank you for reinforcing EXACTLY why open source devs burn out. He has a workflow that he is willing and able to support and doesn't want to support anything outside of that. Your response is: but you need to do it for me because it's what I want.
It's obviously possible to debug what goes on inside a Docker image. It's just not something I'm particularly interested in dealing with, especially under duress.
The thing is, the "it works" is reproducible because of containers. Which is a step above just hoping that it works.
HA is also easy to "patch". You can just install your custom components in `config/custom_components`, it can also be used to "override" core HA files.
Finally, if you are doing intrusive development, you can easily launch HA locally. macOS, Linux, and WSL are supported. You will lose the ability to install add-ons via the addon manager, but that's about it.
FWIW, I had the same aversion to their custom OS and their crazy container-based setup initially. For a couple of years, I used to run HA as a Python app and managed the dependencies manually. Then I tried the HAOS and it... kinda just worked.
FWIW, this can also be called stable state you can retreat to. And build upon, e.g. adding a layer of debugging tools.
I don't really like to deal with Docker, but at least I have reasonable certainty it'll work. I prefer system package manager or MSI, but if not that, it beats having to build something when it's near-guaranteed that what I'll get is not the binary the authors had in mind, if it even runs at all.
(Then again, I routinely rebuild Emacs to stay on the bleeding edge. But it took a while to work out all the usual dependency mess, and I even broke my system once doing it.)
I'm just trying to find some data points that allow for an explanation of both "Eh, seems fine for me," and "Arrgh! This stuff doesn't work! Into the bin!"
I mean: I believe you when you say it doesn't work for you, for I have no reason not to believe you. And I assume that you also believe me when I say that it does work for me.
What other variables/data points could there be, do you suppose? It's hard, as you probably know, for me to imagine ways in which things can break when they've generally been working fine for me.
One possibly-related theoretical datapoint: My access points are not near eachother at all, on purpose. It is perhaps possible that the chatter from one of your APs was "desensing" (I hate that word, but it's a common-enough word) the front-end of the other AP and that this limits the ability of that AP to receive weak-ass signals from an ESP module (or whatever) in some manner of smart device. (When I do want to isolate wifi networks, like when my neighbor asks if he can borrow a cup of Internet because he's broke this month, I've been successful at creating virtual wireless interfaces that are steered to a particular VLAN -- even as far back as the WRT54G days.)
Another possibly-related data point: I do run my 2.4GHz channels at 20MHz bandwidth instead of 40MHz, because that always seemed to get better performance at a longer distance (not that I think I need that for most little in-home smart widgets, but it is nice to be able to take a wifi-connected speaker into the yard or out by the alley where I work on my car, and to use it without using bluetooth[0] or making my phone into a battery-sucking hotspot and reconfiguring the speaker to use that hotspot instead of the house's SSID).
In doing this, the best available throughput in my neighborhood is not very quick at 2.4GHz -- it's always down into low single-digit Mbps with 20MHz-wide 2.4GHz channels, which quite frankly sucks. But it always seems to work with a fairly consistent level of suck, and that level of suck is adequate (throughput-wise, at least) for what I actually need/want from 2.4GHz.
And, sure: I'd be happy to swing by with a few smart devices that seem to Just Work and one of my rather boring Mikrotik wAP ACs so we could sort it out. Or just share configs with passphrases and SSIDs sanitized? I don't think I'm doing anything special, but perhaps I am? (Perhaps I'm even doing something that is both wrong and stupid, but which lets it actually-work.)
I mean: At the end of the day, I just want other people to enjoy the same pleasure of being able to plug in random stuff and have it generally just behave. I don't think I'm an expert, though: I've got some background in land-mobile RF, have established some rather long links between Ethernet-connected devices using ISM bands (some of which have stood up for well over a decade), and I've been playing with Wifi since Orinoco PCMCIA cards were the new hotness. I think I know a few things, but that doesn't mean that I've got some super-secret sauce or something.
At home I'm just a cheap bastard who wants to automate some things, and who seems to be successful at getting inexpensive things like TP-Link smart plugs, ATHOM light bulbs, random Google/Amazon smart speakers, and trash-tier relay modules to work seemingly-reliably with Home Assistant over wifi. I'd pay more for Z-Wave or something if I felt that I had to do so, but my (perhaps unique) experience with wifi isn't leading me towards Z-Wave. (I also had good "luck" with X10 around a quarter of a century ago: It always worked well-enough to automate reliably as long as I kept everything X10-related far away, wiring-wise, from the beastly Best FerrUPS UPS I was using back then.)
---
[0]: Most people would use Bluetooth for this, and they're generally not wrong. But I absolutely hate the way in which Bluetooth breaks when the person with a Bluetooth-connected speaker wanders off with their phone in their pocket and leaves their speaker behind: The audio breaks up in ways that are particularly annoying, but which they'll never, ever hear -- much to the disdain of anyone who does hear it happen. I don't like being that person. If I'm going to play music that the neighbors or anyone else can coincidentally hear, I don't want it to get broken and choppy just because I went inside the house to fetch a different wrench or a beer or something, even if I myself will never hear the problem that Bluetooth use can promote. In this way, slow wifi is better than broken Bluetooth.
I think the most surprising thing is that you can’t see how unreasonable your complaints are.
What I do see is a project calling itself FOSS, while its maintainers really don't like it being used as Free Software. If one wants to control downstream uses of one's software, the answer is quite simple - release it under a proprietary license. Don't grant freedom while going on and on about how you support freedom, but then be upset when someone actually uses that freedom to do something.
> deal with end users bugging me about it being broken.
The nixpkgs maintainers asked how much this was actually happening, and even preemptively proposed solutions. OP didn't engage and just repeated his demands. And in general how is this any different from the common DRM-authoritarian refrain that companies are justified locking down devices they make, lest end users modify them and then clueless people might attribute the outcome to the original manufacturer?
For the uninitiated, CE marking is meaningless (it allows for self-certification).
I'd like to see Big Clive do a teardown of one of those.
Solid state relays have widespread fraud. Like 60% of the ones on amazon will catch fire or fail before they hit the rated current. Trade suppliers generally don't sell them at >30 amps.
Regular relays up to 10 amps are cheap and reliable. Beyond that, they get expensive surprisingly fast, and the reliability is hit or miss. They fail in numerous ways, but the most concerning one is the plastic case melting and catching fire. The chance of failure depends on the nature of the load (capacitive or inductive loads will dramatically shorten a relays lifespan).
In my professional career, I have witnessed ~20 of the above devices failing, with melted bits or burn marks, but of that sample none has burned down a building, yet. But I'd say that was more down to luck than good design.
In general, I would trust a china-device for monitoring power, but not for switching anything more than ~10 amps (1 outlet).
I don't care. I connected my previous breaker after it.
You should care about the quality of these devices, especially ones that provide safety.
Where do you think the "quality" devices are made?
Based on the screw terminal, without looking inside, I would rate it not higher than 10 Amps. Don't pass your whole apartment through it.
You need to host a bunch of daemons (MQTT, ZWave and ZigBee bridges, and whatever else you might need). And a bunch of these daemons can have their own gnarly dependencies (e.g. they can be written in JS and built with NPM, ugh).
So you kinda _need_ to use Docker to make it at least sane.
And if you're using Docker for the plugins, then why not use it for the HA core itself?
And once you do that, you don't really need much from the host system. So why not use a minimalistic OS instead of something like Debian?
These days I'd say that NixOS captures that requirement, allowing orchestration of many daemons and other system config to be abstracted into a packaged solution (eg NixOS Mailserver), that the user can override as much or as little as they'd like.
I believe NixOS does package (or at least attempts to package) HA, but given my past experience and what I believe is still the throw-it-over-the-wall desire of the HA maintainers, I'm wary of adopting it as an overarching solution. I'm certainly not ruling it out for performing some functions, like UI. I just would rather set up my automation efforts as MQTT-first, keep logging and automation rules as their own separate things, and not be fully committed to HA.
You can do that just fine even now. I'm doing experiments with voice control, and I run the complete AI stack locally on my computer. So I just set up everything as regular background processes.
You just can't expect HA to be able to do autoupdates for these daemons.
The other problem is that most of required dependencies are not packaged in Debian. So you'll have to install multiple NodeJS servers and tons of NPMs somewhere on your system.
> These days I'd say that NixOS captures that requirement, allowing orchestration of many daemons and other system config to be abstracted into a packaged solution (eg NixOS Mailserver), that the user can override as much or as little as they'd like.
You can do that with HA as well. Just push in a new image, and tag it appropriately.
The last time I played with Nix, it needed to download tens of gigs of data for a few programs. I don't think this is acceptable for HA.
You can definitely do HA in a piecemeal fashio, but there's just no way it can be done as a reproducible system that you can give to your grandmother. Given these constraints, HAOS is actually pretty remarkable.
> I just would rather set up my automation efforts as MQTT-first, keep logging and automation rules as their own separate things, and not be fully committed to HA.
Raw MQTT still needs a UI that is user-friendly. And even with MQTT you'll need to run ZWave and ZigBee bridges.
The switching under load causes the contacts to get worn, then the large load causes the now-worn contacts to get hot, and the plastic supports melt and catch fire.
There are some ready-made scripts for the Nordics that check the current electricity prices and use those with some basic rulesets to see if the electric heating in a house should be on or off for example.
I just use mine to turn off the ice machine at 22:00 so it doesn't run through the night :D
It's very common to use a relay to control a contactor.
Please learn to never use this type of phrasing when offering suggestions. Your entire exchange was needlessly patronizing and off-putting.
Maybe just something about the latter being interpreted as a question, and the former being interpreted as an order.
I'm not expecting or even wanting HA to do autoupdates. A good framing of the crux of the problem here is that I want to use HA but not HAOS.
> even with MQTT you'll need to run ZWave and ZigBee bridges.
Yes, the point is wanting to keep them as part of my overarching OS-level deployment config so that I can manage them along side email, nginx, matrix, netfilter, hostapd, kodi, etc.
I only brought up NixOS specifically because you asked for an example of a different approach of encapsulating and abstracting service configuration. I'm happy using NixOS, regardless of what you consider a dealbreaker. I used to choose Debian instead. If you prefer HAOS then please continue using HAOS. If I had to create and hand off a machine to my "grandmother", I might even choose HAOS for that myself. We shouldn't need to argue about distributions when talking about software packages.
You can do that. It's not even hard, the HA documentation is pretty stellar in that regard: https://www.home-assistant.io/installation/#advanced-install...
The HA team rightly doesn't want to officially support it, to avoid being inundated by people who don't want to keep the pieces.
> Yes, the point is wanting to keep them as part of my overarching OS-level deployment config so that I can manage them along side email, nginx, matrix, netfilter, hostapd, kodi, etc.
Then this is just not going to happen, unless the world changes a lot. There's just no way something like HA can be both useful for most people, and be released according to the Debian Stable calendar. HA has to move fast to adapt to third-party API changes, new integrations, and to just be able to bring features to users.
> I only brought up NixOS specifically because you asked for an example of a different approach of encapsulating and abstracting service configuration.
NixOS is not that much different from the HA approach. You also can't just get into the NixOS system and edit random files in its storage tree, you'll end up with a broken system. So you need to create a new flake, and then do the changes within this flake's env. If it's a deep dependency, you'll need to modify the dependent software to use your new patched version.
Of course, nix is far more flexible than HAOS, but then they also are made for different kinds of users.
> There's just no way something like HA can be both useful for most people, and be released according to the Debian Stable calendar
People running Debian Stable expect and want slower updates. It's a feature, because things don't change out from under you. It means perhaps not being able to use some new device, but it also means that your current setup just doesn't break/change out of the blue to accommodate some new feature. Essentially the reasons you've said are already being taken into account by people running stable - like yes, running a HA moderated by Debian Stable while trying to use fleeting online APIs is going to be a bad time. Just like trying to use yt-dlp out of the Debian repo is.
> NixOS is not that much different from the HA approach
Sure, but the difference is that I opted into using NixOS as my OS distribution to meet my needs for my entire environment. Whereas HA pushes using their HASS [0] mini distribution as part of using HA. We've discussed the necessary reasons for that, and I agree that the all-encompassing solution makes sense for many people. But the fact remains that is essentially managing a new instance of a bespoke distribution. And that's what really made for my negative experience.
With the advent of Core, it does seem like my previous specific situation has been addressed. But the memory of my experience remains, and then I see things like https://github.com/NixOS/nixpkgs/pull/126326 which make it look like that same rejection of the larger ecosystem dynamic is still alive and well. It just gives me pause, regardless of the continued existence of HA-on-NixOS.
As I said, I'm certainly not against Home Assistant. I'll eventually try using it again when I want some kind of easy UIs for my automation setup. The problems I'm currently solving really just require logging, graphs, and automation rules. And so I've just decided to focus on MQTT-first as the nucleation point, rather than putting all my eggs in the Home Assistant basket again.
[0] Whatever the mini Linux distribution that runs inside the Docker container is called. When writing the previous comment I had thought that was HAOS but now I'm seeing that HAOS isn't included in Supervised or Container. I believe it was called HASS back then, so maybe it's still HASS?