Jump to content

Monitoring total energy used and energy actually paid for


Bobster
 Share

Recommended Posts

I'd like to track the power I use against the power I actually pay for. In theory I can get this off the SEMS portal, but that throws me a curve ball at least once in each month. EG

image.png.2cb8d15967670736d972edd3c3ec24ba.png
Huh? Suddenly I consume 453.91 kw/h in one day! I'd consider that an indelible stain on my reputation. 

The same exaggerated figures are present in the downloadable reports that the portal makes available. But the daily power graph seems OK
image.thumb.png.e59e41e9cce6679a46fb636f59a98f54.png

So I don't think this is a case of GIGO with the GI coming from the Goodwe box in my house. So I'm thinking that maybe the truth is available via the RS485 socket on the Goodwe.

I have some programming chops. I don't mind getting my hands dirty with programming languages that I don't use in my job (I'm actually looking for some motivation to get busy with Python). I have a Raspberry PI looking for gainful employment. Or is there another way of reading the two totals (used and paid for)?

I have googled. Most of the DIY projects I find documented did scraping on an older version of the portal. They don't work now. Oddly there don't seem to be any well documented studies on how to query the RS485 port on the Goodwe.

Any ideas on where to start? I could also use wifi, but the Goodwe wifi isn't a broadcast device and accepts only one connection from a smart phone at a time, and I don't want to take up that connection all day every day.

I'll happily share whatever I come up with (whenever I come up with it) that actually works.

Edited by Bobster
Link to comment
Share on other sites

21 minutes ago, Bobster said:

Huh? Suddenly I consume 453.91 kw/h in one day! I'd consider that an indelible stain on my reputation. 

We had a similar issue recently with a Fronius firmware bug. Every now and then we'd get an erroneous zero energy value. The software correctly interpreted that as a "meter wrapped around" event, and ignored it, but then the next value would be correct again, a large positive number. Whenever that happened, we got large consumption numbers that were not real.

It is also possible that the software does not deal with the wraparound correctly, and that would account for the monthly regularity.

Also, these values are not calculated from the power values, so don't be surprised that the power charts are not affected. Of course they aren't. The hardware itself has internal counters for this.

Sometimes you can figure it out by just looking at the value. For example, if it uses a 16-bit register for this, the maximum number it can account for would be 65535. A scaling factor might use some of that for decimals, so the implementation may well wrap every 655kWh or something like that (which would be roughly once a month if you're like me and you hover around 20kWh a day).

Similarly, we once had a bug where ABB PV-inverters produced 64kW in the late afternoon. Again, this is because it reports negative values (it uses power from the grid to stay alive, but it isn't getting PV), and a bug in the code did not correctly interpret 16-bit signed integers... so it wrapped around to 65535... 🙂

Link to comment
Share on other sites

3 hours ago, plonkster said:

We had a similar issue recently with a Fronius firmware bug. Every now and then we'd get an erroneous zero energy value. The software correctly interpreted that as a "meter wrapped around" event, and ignored it, but then the next value would be correct again, a large positive number. Whenever that happened, we got large consumption numbers that were not real.

It is also possible that the software does not deal with the wraparound correctly, and that would account for the monthly regularity.

Also, these values are not calculated from the power values, so don't be surprised that the power charts are not affected. Of course they aren't. The hardware itself has internal counters for this.

Sometimes you can figure it out by just looking at the value. For example, if it uses a 16-bit register for this, the maximum number it can account for would be 65535. A scaling factor might use some of that for decimals, so the implementation may well wrap every 655kWh or something like that (which would be roughly once a month if you're like me and you hover around 20kWh a day).

Similarly, we once had a bug where ABB PV-inverters produced 64kW in the late afternoon. Again, this is because it reports negative values (it uses power from the grid to stay alive, but it isn't getting PV), and a bug in the code did not correctly interpret 16-bit signed integers... so it wrapped around to 65535... 🙂

Sure, but my property  generally uses less than 500 kw/h a month. I say this because when I used to buy pre-paid credits I always bought 500, because, then, in Jhb, the first 500 in the calendar month were the cheapest. Doing this I built up a credit fairly quickly, so I was using less than 500 kw/h.

What I'm getting around to saying is that this seems to me like a pretty fundamental bug. Whatever register is overflowing, I'm not pushing it very hard and certainly not unusually hard. 

Edited by Bobster
split infinitive/grammatical thing
Link to comment
Share on other sites

Hi @Bobster I have exactly the same distorted graph as displayed in your post.  I'm also keen to monitor PV production and consumption and extracted data although the report I extracted shows results every minute not the 5 min quoted by @Pietpower I will try his approach to see if I can tie back to the graphs that SEMS produce.  My key objective is to understand if the panels are working as they should, at the moment I'm only getting 67% of installed capacity.  This is about 4.2 kw (instantaneous reading)  from 10h00 to 16h00 on a sunny days vs 6.205 kwp.  There are periods when SEMS graph data shows production of 6kw for a short period but I've not been able to find it in the data.  This having been said I don't fully understand the data,  an example of the data transposed for easier reading below.  If you can find a way to extract data or have insights on how to get to kwH I would also like to know! 

Time 01/09/2020 07:08:26 01/09/2020 07:09:25 01/09/2020 07:10:25 01/09/2020 07:11:46 01/09/2020 07:12:30  
Day 09 09 09 09 09  
Work Mode Normal Normal Normal Normal Normal  
Vpv1(V) 253.3 241 251.8 249.8 247.6 PV 1 8 panels north facing
Vpv2(V) 301 296.5 298.5 292.1 274.1 PV 2 9 panels north west facing
Ipv1(A) 0.2 0.2 0.2 0.3 0.3  
Ipv2(A) 0.2 0.3 0.3 0.3 0.4  
Vac1(V) 233.5 233 232.7 234 234.2  
Iac1(A) 0.7 0.8 0.8 0.9 1  
Fac1(Hz) 49.86 49.83 49.83 50.08 50.17  
Temperature(℃) 28.6 28.6 28.6 28.6 28.6  
HTotal(Hrs) 17 17 17 17 17  
PV Generation(kWh) 4.2 4.2 4.2 4.2 4.2  
Pmeter(W) -1135 -1122 -1108 -1096 -1091  
Pbackup(W) 225 224 228 226 224  
Vbackup(V) 233.5 233 232.7 234 234.2  
Ibackup(A) 1 1 1 1 1  
Vbat(V) 49.3 49.3 49.3 49.3 49.3  
Ibat(A) 0 0 0 0 0  
SOC(%) 48 48 48 48 48 state of charge
SOH(%) 100 100 100 100 100 state of health
BMS Temperature(℃) 27 27 27 27 27 Battery management system temp
BMS_Charge_I_Max(A) 37 37 37 37 37  
BMS_Discharge_I_Max(A) 37 6 37 37 37  
Daily Output(kWh) 0.4 0.4 0.4 0.4 0.4  
Total Output(kWh) 6 6 6 6 6  
Link to comment
Share on other sites

On 2020/02/18 at 3:23 PM, Pietpower said:

If your daily power graph is ok then the info in the daily downloadable reports should be OK? Is it not?
Bit of an effort to download individual days though.

I should try this. My example shows two instances in 30 days, but that's unusual, it's usually about once a month.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...