Any interest in energy for INA219?

[Frogmore42]

I want to use Tasmota to reply the timer on a hay feeder. To make it more interesting, I am adding an INA219 to measure the current that the motor uses and also want to know how long the motor runs (to understand the general health of the system and to make sure it really did work). Since the motor only runs for less than 10s, measuring the duration is challenging. Looking at the energy used gives part of the picture and using a rule to publish the sensor value multiple times while the motor is running, will probably provide the rest.

Anyway, I have a proof of concept of using the INA219 to measure energy. Now there are some decisions to make.

1. Is measuring energy always done, or does it need to be selected?
2. How often to check, currently using every 50ms, which seems reasonable, but maybe should be adjustable.
3. What units to use, currently using watt-seconds, which is probably the right unit given the capabilities of the sensor and the integration time, but might be good to support other units for display.
4. Should it match the other sensors that support energy and include, total, today, and yesterday?
   I think this is probably generally useful. Using 50ms for the integration time will give an indication of average power, but will have some inaccuracy for loads that change rapidly.

Any thoughts?
I would like this to be part of the official release, even if it is off by default. I will submit a PR for it, so not asking for help with the code, but might have some questions.

[barbudor]

Hi @Frogmore42

Is this breaking anything for people already using INA219 ?
What is the format of your JSON message ?

Today INA219 is reported through the SENSOR message as { "INA219": { "ID": XX, "Voltage":, ....} }
If your PR change that to an { "ENERGY" : {...} } reporting I think it should be selectable by a compilation switch and not enabled by default.
Not even sure that ENERGY report is supporting multiple sensors while INA219 report currently support multiple sensors.

My 2c.

[Frogmore42]

It is currently just a POC, so nothing is set in stone. Since it just a matter of programming, it can be anything. I was thinking I would follow the model of the other power measuring sensors.

I have seen some issues about the INA219, so I suppose there are people who are using it. My intention for the JSON is to add fields for energy. That makes it a non-breaking change if people use best practices for reading the JSON. But, it could break poor implementations.

Adding a compile time option is possible. I always compile my own, so that is fine with me. Add support to allow dynamic changes is also possible, but probably uses more RAM and code space and adds to the complexity.

There have been many breaking changes with the JSON (and settings) over the years. I suppose having access to just bolts, amps, watts is helpful, but I found that was not really enough for what I need. The cost of the extra measurements, seems small (I am seeing the same percentage utilization reported, but have not looked closer. There is a comment in the code that it takes a few ms for each sensor, so doing it every 50ms is a significant increase over every second.).

Doing energy for multiple sensors is easy. The code is in a loop for each sensor. It will just be done automatically for each sensor.

[barbudor]

Supporting ENERGY for multiple sensors may be tricky if across different drivers.
What happens if on the same ESP you have 2 INA219 + 1 PZEM + 1 HW81012 ? :)

[barbudor]

But don't get me wrong , ENERGY is kinda apealing to have an uniformed energy reporting on tasmota

[Frogmore42]

Each sensor has its own section, so not an issue:

16:16:37 MQT: tele/tasmota_8E9B01/SENSOR = {"Time":"2021-01-01T16:16:37","INA219":{"Id":40,"Voltage":4.70,"Current":-0.000,"Power":-0,"Energy":7.669}}

If I had more sensors, they would not interfere with each other, since each would be a separate object. I am just modifying what is in the INA219 object. Note that this is my POC, so I just implemented Total and it doesn't currently save that to non-volatile. But, it should help make it clear how this could work. Every option makes it more complicated to build, understand, maintain, and use. But, making it too simple makes it not suitable for some use cases. That is the problem with the current INA219 sensor implementation. It works fine for constant loads that are of long duration. I have a use case for a load of short duration that I want to verify is actually running. This means I need a higher sampling rate and a way to tell the duration of load. I looked for other ways to do this. Rules looked like they would work, but they have significant variability in when they get executed and at a 4 second duration for the load a fairly high likelihood of missing the event. I could do something custom just for me, but thought that implementing power might be generally useful.

[barbudor]

@Frogmore42 Looks like we don't understand each other
Specifically has you are not sharing anything about your code. AFAIK, there is no PR to review nor you shared you dev fork.

If you modify the INA219 sensor message to add new field this is fine and will not break anything. Just adding up.

I was commenting about ENERGY which are a special class of sensors. They do not report in a message by their name.
Have you ever used Sonof POW, or plugs with power monitoring or PZEM energy monitors ?
They provide energy monitoring through a generic ENERGY sensor message which is the same whatever is the sensor model:
MQT: tele/skt-barbuxps/SENSOR = {"Time":"2021-01-02T11:26:45+01:00","ENERGY":{"TotalStartTime":"2020-01-09T22:00:14","Total":0.757,"Yesterday":0.293,"Today":0.050,"Period":0.00,"Power":0.00,"ApparentPower":0.00,"ReactivePower":0.00,"Factor":0.00,"Voltage":248,"Current":0.000}}

My original understanding was that you wanted to change the INA219 driver to match those ENERGY sensors.
This is what I addressed as a breaking change because system that were relaying on the INA219 JSON would not work anymore.

WIth regards to your pump monitoring use case, I will answer on the other discussion.

[gg2003]

Good Morning!
I think, I used this page:
https://tasmota.github.io/install/
and installed "Tasmota Sensors"

[sfromis]

No, values in INA219Integral cannot be produced by the standard binaries from the Tasmota project, but you might have gotten a binary by other means, and then used that page to upload it. Or you might be using some Berry code (or scripting, I suppose) doing calculations and then adding the result as a "new sensor" INA219Integral. Just not from a feature of "standard Tasmota".

[gg2003]

O, what a shame... You are right, I wrote a Berry script a few months ago, which I forgot...

I added every second 1 to mAh and 2 to Wh and sent as "INA219Integral"...Sorry for asking here...

[sfromis]

And now you can get to fixing the issue you spotted with your code 😀

[gg2003]

Yes, I will tell, when it works.

[gg2003]

Hi, I fixed the mAh and Ws counter. Now it works fine. Here is a screenshot with two charge/discharge cycles:

It is good to see, that more Wh/mAh were needed to charge than given back while discharge.

By the way: The INA219 seems very unhappy, whith reverse connection. I connected on LiIon cell the wrong way and the INA219 and ESP32 were bricked. Now I added a reverse protection...

[gg2003]

By the way 2: The "normal"
Program Version 13.3.0(tasmota32)
Build Date & Time 2023-12-12T14:31:54
Core/SDK Version 2_0_14/4.4.6.231122
can handle the INA219.
I do not need tasmota-sensors for that.

[sfromis]

You cannot even use tasmota-sensors on ESP32, and there is no tasmota32-sensors, as those sensor drivers are indeed included in the base build, as indicated on https://tasmota.github.io/docs/BUILDS/