7.2 Voltronic Max - load_watthour not working

[jraydoran]

Good Day,

Firstly, thank you so much to all who contributed to this repo.

As per the description, It is the Kodak 7.2 OG Branded Model

Data being logged from the MQTT "voltronic_Load_watthout" topic, the totalizer is not working as expected.

Inverter Settings:

device=/dev/hidraw run_interval=120 amperage_factor=1.0 watt_factor=1.01 qpiri=108 qpiws=45 qmod=5 qpigs=110

No other mods done

Any suggestions?

Edit (resolved): I was misunderstanding the actual data and how the run_inteval is related in the Energy calc.

Extract from MQTT Browser

[wdross]

I'm not sure what you mean by "not working": load_watthour is an expression of taking the instantaneous load watts reported by the unit at the time of the sample, and turns that into what should be represented as "WattHours". For instance, your last value of 34.5667 Wh would be the result if your Kodak reported is was inverting 1037 watts: 1037 / (3600 / 120).

You would have to sum them to get a "total" over whatever time for which you want to know the total Wh.

Do see issue #30 as the description in the inverter.conf is incorrect: run_interval should contain the seconds between program executions. The default entrypoint.sh attempts to run the program every 30 seconds, so the 120 you show should actually read 30. This would correct your readout for inverting 1037 watts for the ~30 second sample to be 1037 / (3600 / 30) = 8.6417 Wh

If you visualize a constant 1037 watts being generated for a full hour, you should get 120 readings of 8.6417Wh. Sum them up and you get 1037 watts generated for 1 hour (1037Wh).

If you attempt to do this math with the run_interval set to 120, you'll get 120 readings (entrypoint.sh's execution rate) of 34.5667, which would sum to 4148Wh, which is exactly 4 times too big. This is because 120 is 4 times bigger than 30, which is the problem!

[jraydoran]

Hi, wdross,

Thank you so much for taking the time to respond. Your explication makes perfect sense.

What I was expecting to see was a value increasing over time until a reset either daily, weekly or at e.g. 99999999. So if I wanted to get energy over a specific time, I would take the sample each point and subtract from the other.

So now that I understand why it can go up and down.

Just dissecting your reply so I make sure I understand each step and can maybe help someone else in future.

In this case: Energy (Wh) = Power (Real Power - W) x Time (Hours)

Energy = 34.5667Wh Time = (run_interval/60/60) hours

So Power = Energy / Time

Power = 34.5667 / (120/3600) Power = 1037 W

Up to hear I understand perfectly. So the 34.5667 Wh Energy Reported is over the last 120 seconds. So if I integrate all these values, I will get the readings I expected initially.

It is the part 2 that I don't fully understand. Issue No. 30 you linked to.

Do you suggest that I change run_interval=120 to run_interval=30

Really appreciate the time and effort you put into this reply.

Thank you!!

[wdross]

Right, sorry for the lack of clarity. I was basically trying to show where the numbers came from using the default parameter 120 to show the math yielding the 34.5667Wh would have been based on your Kodak inverting 1037 Watts.

The number 120 is wrong (and thus the 34.5667 is also wrong) .
If you haven't changed the shell script at all, it is trying to collect the data every 30 seconds. _So runinterval needs to be 30. When you are inverting 1037W for 30 seconds the actual answer is supposed to be 8.6417Wh. Collect (add up) 120 samples (how many readings you will get in an hour if you sample every 30 seconds) you'll end up with 1037Wh. That is the correct answer.

I'm also trying to be very careful with my words here: I say "trying" to collect every 30 seconds, but if you monitor the actual time between messages it is 34, sometimes 35 seconds (at least on my Pi4). That's because the shell script uses the "watch" command with a 30 second delay to run another pass of the program. The program takes about 4 seconds to do the work of getting the parameters, parse them out and transmit the 32 separate variables to my MQTT server. Then it waits for 30 seconds. And does it again. If your network is slow or (in my future case) the MQTT server isn't on the same network as the Pi4 it will take much more than 4 or 5 seconds to do the work.

I've improved that by having the shell script adapt the delay time such that it really does sample every 30s in a "personalizations" branch in my fork of this repo. The shell script now actually uses this configuration run_interval we are discussing!

[jraydoran]

Thank you so much for your detailed explication and makes perfect sense to me know.

Appreciate your time and effort in assisting me with the query. I will look into your fork. You are correct, with Energy, the time component is essential.