Guidance requested: Proper implementation of energy monitoring (including historical kWh)

I want to write a new integration for an old energy meter (CM-160 OWL +USB) I happen to have lying around, but that got me thinking more fundamentally: This ideally should have some core or at least utility support so that not every energy meter component needs to implement all the stuff themselves.

Current situation: All the currently implemented energy measurement components are either: A) utility company cloud service, B) smart meter (maybe local), C) plug-between type devices (integrated with z-wave switch for example).
The device I want to implement support for is another category D) clamp-on sensor attached to the power mains.

A generic energy measurement and display flow looks like this:

  1. Input amperage (current, as Amperes)
  2. Convert to power (as Watt), possibly taking into account a power factor correction because of the difference between active and apparent power (https://en.wikipedia.org/wiki/AC_power#Active.2C_reactive.2C_and_apparent_power)
  3. Integrate over time, get total energy consumption (Wh), possibly in different tariff/time bins
  4. (Optional: Differentiate Wh to get instantaneous power usage for display)
  5. Multiply with energy cost per unit (example: €/kWh) to display current cost per time unit (example: day so far, day projected)
  6. Calculate and display various comparison figures (both € and kWh: total today, yesterday, day before yesterday, this week, last week, this month, last month, year-to-date, last year).

(See: Daily/Monthly kWh total is a request for a subset of this.)

I’m willing to write all or most of it, but it would be helpful to know where it should fit in the home assistant framework in such a way that other components can make use of it. Making this generic allows all sensor types to profit: Cloud connect and smart meter components (example: sensor.loop_energy, sensor.dsmr, image_processing.seven_segments) will directly give you kWh total so you can skip steps 1 through 3 (and may need step 4 for systems that don’t give you instantaneous power some other way). A plug-between sensor may give you either Amperes or Watts or both (and sometimes the Watt calculation is dependent on externally setting the right power factor), so you may be able to skip step 2. A clamp sensor will only give you Amperes.

Problem A: How to package this? Is it a base class that other components can derive from? Is it a separate service like “map”?
Problem B: Where to store the data for steps 3 and 6? Does the history component have it? In a lossless way?

6 Likes

Hi @henryk,

Can’t really advise on your above queries, but wanted to let you know I use a CurrentCost EnviR similar to your OWL
I also have an old OWL energy monitor but due to interference with other wireless standards on RFXTrx433 I no longer use it.
I just wanted to let you know that I would welcome your component and was more than happy helping with tests should you need.

Good luck.

That sounds good. I currently started adding support for some AVM smarthome devices and one of them can measure the current power and and also the already integrated consumed energy. Therefore a common entity would be nice.

Just to help with the numbers, I’m also using an OWL, the CM-180, via RFXTRX.

I think this sounds like a great idea. In my old house where I had solar and real time energy reading, I was starting to think about how to manage all of the data but didn’t get very far. InfluxDB looked promising, but I wasn’t sure about the long term usefulness of it. It was before I starting using HA and I had started to implement a two stage system where I would feed real time measurements into something like Influx and and have it do computations on that data to get the derived quantities. Then at the end of each day (or whenever), I was going to grab the data in Pandas and use that to normalize it - move the points to fixed time boundaries via interpolation, compress the data set to some level, and generate other quantities like daily/weekly/monthly/yearly min/max/avg numbers.

I realize it might be a big job, but I think a general purpose approach to this would benefit HA for many things. There is a ton of data that would benefit from a history mechanism that allowed for creating derived quantities, compression, and long term storage and plotting. Basically a much improved version of a RRDtool. In addition to the obvious energy examples you’re looking at, here are some more:

  • I have temp sensors that report every 18 sec (weather station). I’d like to keep 3 days worth of that data while generating real time min/max/avg numbers for the day, week, and month. At the end of the 4th day, compress the data from the older data down to 5 min intervals for long term storage and plotting.
  • The thermostat history shows a nice plot of actual and desired temperature. I’d like to add an item showing when the thermostat was running and integrate that value to generate accumulated run time. Also create min/max/avg values for some time periods.

Trying to make something that general would be tricky and it might take a few iterations to get the user interface easy to use, but if it could be done it would be a big capability addition to HA that I think would be really useful.

1 Like

I would love this component. I agree it would be a great idea.

I don’t know how to help with your questions though, I’m relatively new to Home Assistant and not well versed with its internals.

Sharing my experience:
I use clamp-on sensors on mains for power readings (Rpict from Lechacal connected to a Raspberry Pi).
I ended up researching and using Influxdb integrals to get Energy consumption, and the Influxdb sensor to display the results in HA.
I suppose the upside is that I learned quite a lot about Influxdb. However, the setup was a bit complicated, and the Raspberry Pi didn’t like it either, it failed too often under load from HA, Influxdb and the clamp-on sensor readings.
So I have just moved HA and Influxdb to a mini-PC, and use the Raspberry Pi only for the mains power readings.

You sell it?

How you transmit data? Or you pi3 is next to the main cable?

I can if you want. Where would it need to be shipped?

After corrupting a couple of SD cards while running HA and Influxdb and the current readings, now the Pi is just a mains power reader.
And you guessed right, the Pi lives near the general switchboard in the hallway and transmits the power readings over Wifi to the Influxdb database in a Docker container in the home server.
Then HA (again Docker container on home server) reads them with the Influxdb sensor.
The Rpict board has 3 inputs, so I read mains, electric boiler and kitchen cooker. The readings look quite noisy though. I’m not exactly an expert so I don’t know whether it’s inherent to the current sensors or it’s the power line (voltage seems to fluctuate quite a lot) or what else.

I too have an OWL intuition + CM160 + Wall sensors & switches.
Would love to see/ help work on a way to interface to the OWL intuition API.

Also note re OWL intuition API - I received an email from the vendor re moving to a paid service, so a free version might need to snoop via a RFXtrx433E interface.

Either way here are some refs which might help

OWL intuition API - network snoop
https://openenergymonitor.org/forum-archive/node/11109.html

OpenHAB - RF snooping


OWL intuition - Docs - Kit User manuals & install docs
docs.owlintuition.com/

OWL intuition - Data Push Settings

Hope this is helpful, please contact if you want to collaborate.

I finally set up influxdb and grafana so am dumping all the OWL readings into influxdb via HA, and then graphing it out in grafana. Using the functions I am calculating the daily consumptions, and then have grafana implemented back into HA via an ipanel. Works well enough.

Hallo davefi,
I would like to do similar. Are you using rip? What is you configuration? What is the 433 receiver you are using with you pi?

Hello Dave,

Can you share your configuration for CM-180 via RFXTRX ?

Thanks !

Interested in this as well! :slight_smile: