Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monitoring energy usage with smart plugs, Prometheus and Grafana

ounapuu.ee

Post reply on HN
Print view View original

111–120 of 190 posts

Re: Monitoring energy usage with smart plugs, Prometheus and Grafana

#111

Post by cyberax »

mindslight wrote: post #107
cyberax wrote: post #98

Earlier quoted context omitted.

But how would you do it differently? 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 o…

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 lik…

> 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.

Re: Monitoring energy usage with smart plugs, Prometheus and Grafana

#112

Post by tw04 »

mindslight wrote: post #109
tw04 wrote: post #106

Earlier quoted context omitted.

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'…

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.

Re: Monitoring energy usage with smart plugs, Prometheus and Grafana

#113

Post by aulin »

argulane wrote: post #32
dsab wrote: post #14

Guys what are your favourite smart plug? I need one with easy integration with grafana, not sucking, and shipment to EU country?

ATHOM plugs are very nice, you can order one with ESPHome or Tasomata firmware preinstalled and they can ship from Germany https://www.athom.tech/

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

Re: Monitoring energy usage with smart plugs, Prometheus and Grafana

#114

Post by mindslight »

tw04 wrote: post #112
mindslight wrote: post #109

Earlier quoted context omitted.

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?

Re: Monitoring energy usage with smart plugs, Prometheus and Grafana

#115

Post by Izkata »

baq wrote: post #35
mindslight wrote: post #4

Earlier quoted context omitted.

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.

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.

Re: Monitoring energy usage with smart plugs, Prometheus and Grafana

#116

Post by sponaugle »

RatchetWerks wrote: post #103
sponaugle wrote: post #62

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. (Short video about the setup: https://www.youtube.com/watch?v=-tcbJCvuJG8 )

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.

Re: Monitoring energy usage with smart plugs, Prometheus and Grafana

#117

Post by mindslight »

cyberax wrote: post #111
mindslight wrote: post #107

Earlier quoted context omitted.

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 lik…

> 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 autoupd…

> 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.

Re: Monitoring energy usage with smart plugs, Prometheus and Grafana

#118

Post by applied_heat »

leeoniya wrote: post #89
applied_heat wrote: post #84

Earlier quoted context omitted.

If grafana supported numeric entry fields and buttons it could easily replace wonderware intouch etc. Traditional scada systems have such brutal plotting abilities they are ripe for disruption

for sure. we're continuously adding capabilities to the Canvas panel to support SCADA-type and flowchart use cases. 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 standar…

I think OPC-UA uses http, and there are OPC-UA servers to talk to Just about every type of device, so maybe it is already possible.

I was looking at the canvas element to do an electrical single line diagram.

Re: Monitoring energy usage with smart plugs, Prometheus and Grafana

#119

Post by nucleardog »

ssl-3 wrote: post #110
nucleardog wrote: post #96

Earlier quoted context omitted.

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…

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…

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!

Re: Monitoring energy usage with smart plugs, Prometheus and Grafana

#120

Post by cyberax »

mindslight wrote: post #117
cyberax wrote: post #111

Earlier quoted context omitted.

> 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 autoupd…

> 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, ngin…

> 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.

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.

Post reply on HN