For people in The Netherlands: all Smart Meters that the net maintainers installed (are required to) support the P1 standard, which provides a standardized interface for customers to read out current current draw, cumulative power use, etc. Usually gas is hooked as well.
You can hook up a cheap dongle to expose the stats in an app. For instance, we use:
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):
Indeed it is great to use what is already provider by the utilities company, for the same reason I wrote a prometheus exporter that exposes the homewizard values https://github.com/chrisdoc/homewizard-p1-prometheus
Not likely, you’d need a CT around the phase conductor(s) of every circuit. The meter likely only has CTs around the 2 (3) phase conductors on the incoming service drop.
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 think the aliexpress link for the display is busted (as they do).
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.
This guy is funny, I like him. I just bought a $12 annual sub to his project IMGZ. I'm not affiliated at all, if you're thinking this is an elaborate ad.
You're running all your flat's power through that $14 Chinese rubbish and never assumed that shortcuts were taken or quality would be an issue? How do you know it will continue to function as a circuit breaker and isn't just a piece of wire inside?
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.
There are 2 ways to design these. They could use a regular relay, or they could use a solid state relay.
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've been down this road quite a bit on Amazon, eBay, and AliExpress/Alibaba. Are there any good options for relays that work for 100-200amps? I've found 30 amp relays of the type that are built into PCBs and I have tried a few 100 amp contractors that can be triggered with a separate line but I'm not sure I trust them. Most tend to top out at 65a rating and I get the feeling the 100a ones are just the same but with a more belligerent seller willing to advertise a false rating. What serious options are available for switching larger loads remotely.
Relays and contactors are the same thing. The main difference is that they tend to be called contactors more often when they are carrying mains voltage and current. (Or higher.)
It's very common to use a relay to control a contactor.
Is it the switching that kills the relay or is it enough to start/stop the load? E.g. if I have a 10A smart plug monitoring power on a small waist-tall freezer in the garage will it eventually damage the switching function?
Its generally the switching, although I wouldn't professionally sign off an undersized relay on the basis of 'it never switches, so its fine'.
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.
A mains connected circuit designed to minimum costs could have all sorts of corner cuts: bad capacitors, no overvoltage protection, no back EMF from load protection, bad isolation to the driving circuit, etc, so that it could work flawlessly for decades, but also stop working after a while because of a spark that welded the contacts together, or mains voltage to enter the driving circuit because of moisture and insufficient creepage between high and low voltage tracks, etc. I use a lot of cheap Chinese products in non critical contexts, but I'd avoid them with mains voltage or in any safety critical use.
Some options at the $10 price point on AliExpress, though I cannot recommend one, maybe another reader can. CTs are the generally accepted way to do this and don't have to modify mains wiring. Could also build your own; CTs are inexpensive.
The fire hazard from the cheap breaker is still present. Your existing one protects the downstream circuit but the Chinese breaker itself is a safety hazard.
You should care about the quality of these devices, especially ones that provide safety.
Just a nit: The Chinese breaker isn't providing safety. You should still be caring about its quality because it's handling a lot of current (and potential power).
Some of them (most of the latest models) are scriptable on-device.
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
Do you have any you would recommend? I'll love you for a link, and like you for a brand name. Not being a dick here, I'm genuinely looking for one that I don't have to lose sleep over installing.
I nerded out on this a few years ago and ended up buying a not well known device called a rainforest automation eagle (https://www.rainforestautomation.com/rfa-z114-eagle-200-2/). Its a pretty straight forward little linux device that reads your smart meter (after being enrolled via your utility). It exposes an xml api that I bridge to Prometheus (https://github.com/kklipsch/reagle).
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).
Thanks! Unfortunately all my data readings are in kW. I've been trying to figure out how to get hourly roll-up working and then multiply each hourly reading by price in Prometheus.
One step further. I just installed the Emporia Vue 2 in my distribution box. 16 CTs plus the three mains phases. It's ESP32 based and there is a great ESPHome project that you can flash it with for local only reporting. Add some HA and VictoriaMetrics, and now I can see how the whole house behaves with Grafana. Next up, Zero-Export using this data to steer my little OpenDTU solar plant. We live in such cool times!
Victoria metrics and grafana is great. I only wish I could enter descriptions for the metrics to populate the description in the grafana metrics explorer which is traditionally done by Prometheus metric metadata “help” field.
Victoria metrics/ grafana is supplanting our industrial historian, which is admittedly not a best in class product - I am sure osi pi is better
Eh, that's even more expensive. I think I'll end up having to develop my own hardware, even with Vue blowing $1500 for energy monitoring is a bit too much given how cheap the hardware can be.
The device the OP puts Tasmoto on from athom.tech can also be ordered for the same price pre-flashed with ESPHome to work with Home Assistant. I have used them with 2500W single-socket loads and been happy with them for a year or so.
For whole house load I'd recommend integrating with whatever smart meter tech your country uses.
For the in-between size loads eg. 32A breakers in a consumer unit I have not found a reliable and cost effective solution yet.
I bought a CURB Energy monitor about 6 years ago. Does anyone know if it's possible to flash open source firmware on it? It only has a cloud integration, but I would really like to hook it to to home assistant.
I did some scouting about for what microinverters would be usable without a full professional install, for a small under half kilowatt playing around. I was hoping I could snap up some used enphases & try stuff out with a 200w panel & my existing batteries. But I really didn't turn up much; most discussion online made it seem like you needed special installer access to get anywhere with Enphase. Exciting to hear maybe this microinverter idea might not be totally dead in the water.
I used IoTaWatt devices, which can be installed in panels. It is a great solution for by circuit monitoring, and has direct influxdb integration so you can use Grafana.
Per plug monitoring is cool however for getting specific devices on a circuit.
Wow it’s a small world. I just discovered your channel recently and love the content. Probably watched the home lab video like 10 times. I have a historic building with 3 vacation rentals that I’m in the process of adding some intelligence and monitoring to, including a raspberry pi kiosk based on one of your videos. Thanks for making them!
I gotta chime in also. I just learned about your channel literally today when a buddy DM'd me a link on your YouTube homelab tour. We have pretty similar interests. I also have an IOTAWATT and I love it. My only grip is I wish they had the ability to log more channels with the same unit. ie Approximately 30 channels.
Sweet! Yea, I have several panels that have 2 of them for that reason. I have debated making a larger one since the code is open source. It would be great to have one that has more ports, and perhaps the ports combined into less cables.
I agree. I think a good way to solve this problem would be to move the ADC + circuitry to the induction clamp itself; then daisy chain the units together via some bus protocol. It's would allow customers to go from 0-X in terms of logged channels. As well as reduce the size of the sending unit considerably.
I scrape power usage metrics from Tapo P110s and push them to Grafana Cloud using https://github.com/richardjennings/tapmon - although as other commenters have noted - using Wifi for smart plugs has its rough edges.
I second that. I replaced a bunch of wall switches with Leviton WiFi smart ones and would never go WiFi again. They're totally unreliable. My Meross smart plugs fair a little better but still lose connectivity now and then (got a bit better with updates).
I hear a lot about reliability issues with various wifi smart devices.
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’ve tried a handful of WiFi light bulbs, smart plugs, and other things. They were connected to a dedicated 2.4GHz access point (MikroTik as well). WiFi signal was fine—had good coverage (access point was central to the small wood frame house, and checking signal strength at device locations showed a great signal) and I live in the middle of a forest and there’s nothing else within range to interfere. Basically best case scenario outside of a lab or something.
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.
Why sure. It's a rule that people who have the least amount of success with a thing will write the most about that thing. This is why those with their wits about them read things like Amazon reviews with a decent-sized grain of salt.
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.)
I have two identical Mikrotik devices bolted to a wall beside each other in a closet. One is the WAP serving all of our phones, the laptop I use for work, the laptop my wife uses for work, the TV, the PC hooked to the TV, and everything else. It’s been 100% rock solid.
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!
I haven't, at any time, doubted your ability to correctly configure an access point.
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'm surprised there aren't LAN-over-powerline devices that do outlet switching. I run a large portion of my local ethernet through my home's powerlines and it works really, really well. My desktop can saturate my internet connection running on one of these things. I think there are five or six devices on the wired LAN that run like that.
i'm trying to nudge Grafana into the direction of IoT/SCADA control, so we can be both, a great way to viz (data sources) and to control (data sinks). not personally a huge fan of having to recommend Home Assistant for that use case :)
similar to how you can make plugins for data sources, you can make plugins for data sinks, like write over modbus, or POST to http API or, publish to some kind of MQTT broker, etc.
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.
Have you seen/know about NodeRED? I myself have moved away from HA/OpenHAB-likes to NodeRED as that allows me control that's more... restricting. At its heart NodeRED is a visual programming tool (and I think it wouldn't be a terrible fit for Grafana), but what NodeRED has and Grafana doesn't is a community which built a very significant number of packages that integrate with various protocols and devices used in home automation.
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.
Facetious but half serious reaction: surely grafana usage nullifies any possible benefit from the monitoring? If there is one piece of software regularly using way more resources than seem reasonable it's that one.
i've just bought a cheap esp32 with a light sensor connected to it. then connected light sensor (ie bluetac) to my electicity meter that pulses every 1/1000 1KW/Hr, it uploads the data to google sheets which graphs the output - works great
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!!)
nice, I like the simple approach. My old meter only had a rotating disc and it took all my effort to get a sensor connected to my arduino that could detect the black mark on the edge of the disc. There was just enough mem for a http service to allow me to pull that value into my iobridge for remote monitoring.
Home assist looks good, but my requirements was that my elderly relative was being monitored by all my family (ie they're not on my home wifi/lan) hence the data on the movement needed to be on the internet for all to see
Surprised there’s not more mention of Shelly monitors in these comments. They’re great for whole house (service entrance) and circuit power monitoring. Pretty open integration, OOTB integration with HA.
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.
I use a dozen of their relays and I am happy with it; for power metering they don't have a great solution, the 3 phase clamp is very expensive and there is no option for more, like Emporia Vue with 8 or 16 sensors. So yes, Shelly is worth mentioning, but not for fine grained power metering.
The deployment model is very different, and within that model, the capabilities are far different. Comparing Shelly's system to Vue really starts with understanding your requirements and long-term automation plans.
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.
I also like their products very much. I installed a few of them in my sockets. Some people argue that it's not safe to put in your sockets walls and the 16A limit is realistically lower before they can overheat and cause fire. That scared me a little bit but I think most of the reports are from bad wiring like using thin wires or not tightening the clamps enough
I have a Shelly pro 1PM in my Breaker box for the car charger. It gets to 80 degrees Celsius easily at 16A. I have two other gripes with it:
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've been happy with my tplink sockets, especially running them off-cloud, and getting some command line control over them (although I think that debug api got blocked on later firmware updates). But quite easy to feed data into any db once you have such control.
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.
I had four tasmota preflashed athom plugs die on me in less than a year. As long as they worked they were perfect but they don't last... Hope they addressed the issue meanwhile
They were always on, used them as power monitors. One on my washing machine, one on the 3d printer, one on the tumble dryer. One on and off depending on the season, christmas tree and similar.. They all died the same way, at some point never turned on again without any apparent reason.
I use Gosund SP112. Available at Amazon, ~12€ / plug. Flashable with Tasmota or ESPHome (I use the later). It can switch the mains as well as one USB-A power outlet.
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 love these ATORCH ones on Amazon, they have a screen with a bunch of useful details, super stable wifi connection, over-voltage/current/power protection, etc.
I've switched from Shelly plugs to ThirdReality Zigbee outlets, I like having them on Zigbee rather than WiFi as I've installed like 8 now, and my consumer WiFi router doesn't like handling more than 15-20 devices.
I’ve got some Sengled E1C-NB7 plugs that I really like. The form factor is nice, they work perfectly with Zigbee2MQTT and Home Assistant, and they’ve got a power button on the device itself.
I want to buy more and they don’t seem to be available anymore.
I would love a semi-automated way to generate a power-profile for ESP-Home. Find a smart room heater with 3 levels perhaps, and use home assistant to gather values at "Off", "1/3", "2/3", "3/3", with a downstream power plug as reference (and a known consumption of the downstream plug as well).
So I can just take my EspHome plug and very quickly generate a standard set of mapping values for voltage and wattage.
The easy way is with a resistive space heater and a multimeter. I keep a big, dumb, thrifted "oil-filled radiator" space heater around just to use as a big, safe 3-speed dummy load with reasonably OK repeatability (nichrome heaters do not have perfect temperature coefficients, but they're stable-enough that using them to measure temperature quickly begins to be a non-starter).
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?)
I'm really impressed to see the home server power consumption in the article. I always sort of expect these things to end with, "it turns out I could save even more power by not having a home server".
Why not both? You’ll need to run a server either way.
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.
Seconded - HA's graphs are great for a simple "is this going up or down" glance but when you want to put a whole bunch of things together for comparison or perform aggregations or calculations, that's when you want Grafana et al.
Right up until the Home Assistant UI turns into a lagfest, the installation dies, and you can't debug why because Docker. At least that's what happened to me. And no, it wasn't RPi SD power issues. This happened on an otherwise-stable amd64 server.
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.
... and then not have any of your usual development tools, environment, system layout, or repair techniques because you're inside someone else's "works on my system" that they threw over the wall.
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.
> ... and then not have any of your usual development tools, environment, system layout, or repair techniques because you're inside someone else's "works on my system" that they threw over the wall.
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.
> because you're inside someone else's "works on my system" that they threw over the wall.
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.)
It's certainly within my gamut to jump into an embedded system to debug it, bringing/building tools as I go. I'm just not looking to opt into doing that on something that doesn't need to be that complex in the first place. Same reason I run one decently powerful amd64 server that does many things rather than a stack of Raspberry Pis, one per software package.
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?
At the time my setup didn't require other daemons like that. But if I had been in that position, I would have just set up the other daemon under Debian and pointed HA at it.
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.
> At the time my setup didn't require other daemons like that. But if I had been in that position, I would have just set up the other daemon under Debian and pointed HA at it.
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.
> You just can't expect HA to be able to do autoupdates for these daemons.
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.
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.
Back when I was using HA, Core and Container did not exist (at least as first-class recommendations), so I'll admit not having been really aware of what they were. Core would have meet my deployment policies at the time, and if it had existed I would have gone that route instead of Supervised and been much happier. So I will give credit there for HA getting better distribution options since my poor experience.
> 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?
It's a Python app, of course being distributed as a docker image is the sanest way of doing it. I don't see why you couldn't just pip install it if you really wanted, but having been a Python developer for close to two decades, I wouldn't want to.
That was the standard way a long time ago, and the first startup would take a really long time because it would install even more stuff. And sometimes fail. It wasn't very reliable if you used any addons, and some required a ton of extra steps that it couldn't automate like the modern deployments do now.
I happily ran a dockerized HA on a Debian for years now, no need to do any complicated debugging (and even if I did, it would not be difficult to inspect it properly)
Nobody is preventing you from running Home Assistant core and deploying everything else yourself manually.
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...
What do you mean "demanding support" ? I remember Home Assistant authors being actively hostile to people packaging their software outside of the official Docker or RPi images. Which is why it wasn't in the Debian repository, pushing me down that Docker path in the first place. Here's the same dynamic on an associated project in 2021: https://github.com/NixOS/nixpkgs/pull/126326
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.
So... your example is a developer of HA stating that he sees major flaws with how they're distributing his package, and that he has absolutely no interest in supporting users that pull his code in a way that is unmaintainable by him.
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.
Did we read the same thread? Nobody asked the HA developer to support anything, rather that developer started the conversation by making demands and then kept at it.
“Making demands” which were: please don’t package my code in your distro that has dozens of out of date packages my code depends on that will break. Because I don’t want to deal with end users bugging me about it being broken.
I think the most surprising thing is that you can’t see how unreasonable your complaints are.
If you attempted explaining how you think my stated position is unreasonable, perhaps I could see it. So far you've only attacked strawmen, such as claiming that I am demanding support from HA or claiming upstream was being asked to support nixpkgs.
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?
I'm also looking at a custom solution for my current migration from WiFi sockets to Zigbee. It seemed impossible to do an offline installation of home assistant, and discouraging signs for running it without an internet connection.
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.
HA will happily run offline; if you mean HAOS then I don't know what it does but it's an unorthodox Linux distro, but once it installs it should also run offline without issues. I'm also using their skyconnect zigbee coordinator and it works very well.
Yeah one of the tests was a RPi image and it wouldnt complete without a LAN internet connection (only got 4G). And it seemed far too weighty for a bit of home automation.
I recall the online requirement was for some ntp server requests that cant be disabled.
Yeah that's more of a rpi hardware requirement as it doesn't have a battery and you realistically want to have accurate time on your smart home controller, even - especially - after it cold boots after power loss.
Just last week I was geeking out at Jeff Gluon's home lab implementation, and he released a nice video walking through his power monitor, which also uses Grafana.
You need to be careful with what plugs you choose, though, because they each have, let's say, their own peculiarities.
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.
Shelly relays can be configured to do all these things and the voltage safety threshold itself is also configurable (at least in the Plus devices) but they aren't zigbee. Otherwise great little devices.
Not sure what do you mean? There are the 1/1PM/Mini/2PM which quite comfortably fit behind light fixtures and outlets (unless you have shallow flush mounts).
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).
If someone else wants to try this, I strongly recommend against using WiFi for the plugs, instead use Z-Wave or Zigbee.
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.
Not the first time I hear this but I have about 20 ESP devices on my WiFi, almost all of them pushing data regularly and polling for instructions (I don't use HA, but a simpler home made solution) and I have no problem at all.
Powerline ethernet dumps an utterly horrifying amount of electrical noise into both the wiring and the surrounding area. Please don't use powerline unless you have no other solution.
Note: Powerline ethernet should not be confused with Power Over Ethernet which is perfectly fine.
Don't have any to link off hand, but the basic gist is this:
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.
The issue, I think, is that you're extrapolating from the usecase where high bandwidth ethernet is carried over the power lines. Protocols' like X10 bandwidth use and needs are so low (dozens of bits per second) that the interference is indistinguishable from the regular power fluctuations.
I speak from experience. I tried powerline ethernet because wifi signals traverse the house walls very poorly, to say the least. The sheer noise the powerline adapters generated into the line, regardless traffic, was unacceptable.
I have a box of old X10 devices here, one of the most reliable home automation systems I ever set up. I only switched to WiFi when my iobridge X10 controller failed and I couldnt work out the RS232 protocol for a different controller.
https://www.stavros.io/posts/making-the-timeframe/