Help Required Uploading Growatt Inverter To PVOutput

Inverters Growatt
#103

Hi,
Thank you for the explanations regarding the interpretation of the data.
I include below the readings for holding registers from 45 ~ 50 for the three units.
This is year, month, day, hour and minute.
I also include the payload (captured by tcpdump after changing https to http) sent to pvoutput from the two units. Please keep in mind that I have forced c1=0.

Summary 
root@OpenWrt:~# python
Python 2.7.15 (default, Aug 16 2018, 07:51:15)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pymodbus.client.sync import ModbusSerialClient as ModbusClient
>>> inv = ModbusClient(method='rtu', port='/dev/ttyUSB0', baudrate=9600, stopbits=1,
                       parity='N', bytesize=8, timeout=1)...
>>> inv.connect()
True
>>> rr = inv.read_holding_registers(45, 5, unit=0x1)
>>> print rr
ReadRegisterResponse (5)
>>> print rr.registers
[2018, 10, 16, 11, 1]
>>> rr = inv.read_holding_registers(45, 5, unit=0x2)
>>> print rr
ReadRegisterResponse (5)
>>> print rr.registers
[2018, 10, 16, 10, 50]
>>> rr = inv.read_holding_registers(45, 5, unit=0x3)
>>> print rr
ReadRegisterResponse (5)
>>> print rr.registers
[2018, 10, 16, 10, 59]
>>> inv.close()
>>> quit()
root@OpenWrt:~#

PAYLOAD
unit=0x1
d=20181016&v12=0.965288290338&v10=158709800&v1=70800&v2=24613.5&v5=20.0&v6=615.4&v8=236.8&v9=67.9&c1=0&t=12%3A35[!http]

unit=0x2
d=20181016&v12=0.982326635263&v10=110493300&v2=24711.9&v5=20.0&v6=584.5&v8=236.5&v9=57.9&c1=0&t=12%3A35[!http]
#104

Thank you! Do you mind tell me what Growatt model do you have? Your inverters clearly have timekeeping while mine has not. Probably yours may have data log memory too (don´t remember registers now but they are the last ones in the input registers table); those store data like yearly production for the last 3 years, monthly production for the last year, daily production for the last month…

Based on the fact you have timekeeping on your devices I will include the code to synchronize clock later on. This is good to keep all your 3 on the same minute and keep data logging (if any exists) in sync.

Later I come back with something about c1 and v1 issue you report.

#105

My model does not store data like yearly production for the last 3 years etc as I can not read registers 450+.

I have an issue (not related to the code discussed here) but I just report it here in case anyone has a clue.

One unit, from time to time, reports usually for one day (but sometimes more) voltage around 717.0V and the production is about 2/3 of the other units. I discussed the issue (a year or two ago) with the local distributor but they said that this is wrong reading from the telemetry and there is no issue with the inverter.
Today this happened again but thanks to @jrbenito I was able to access the unit and read the registers. There is no indication of fault or warning and all readings seem consistent.
Has anyone else experienced this?

image
image761×292 16.7 KB

#106

What would be normal voltage for your arrays?

#107

The other two units normally work around 600v (580-630). If you look at the voltage line above you see a strait line (with minor differences at decimal point).
Below I include today’s production diagram for an other unit.

image
image775×307 26.5 KB

#108

I would say that the straight line is really strange, photo-voltaic cells are never that stable. But I have no idea what it is or how is it happening.

#109

For those who might be interested, I uploaded documentation I have regarding Growatt protocols (3 versions). They are inside docs sub directory on dev branch

#110

“Are you seeing 5 minutes gap yet?”. No, no unexplained gaps since I started running 0.7.1 :slight_smile:

Bob.

#111

Hi @jrbenito.

Lots of errors in my log today and missing values between 12:05 and 12:35 (11:05 and 11:35 UTC). I guess that this was because PVOutput was down for maintenance. The errors were:

Traceback (most recent call last):
File “/home/pi/canadianSolar-pvoutput-master/canadian_reads.py”, line 328, in
main_loop()
File “/home/pi/canadianSolar-pvoutput-master/canadian_reads.py”, line 302, in main_loop
power_vdc=inv.pv_power)
File “/home/pi/canadianSolar-pvoutput-master/canadian_reads.py”, line 261, in send_status
self.add_status(payload, system_id)
File “/home/pi/canadianSolar-pvoutput-master/canadian_reads.py”, line 175, in add_status
self.__call(“https://pvoutput.org/service/r2/addstatus.jsp”, payload, sys_id)
File “/home/pi/canadianSolar-pvoutput-master/canadian_reads.py”, line 194, in __call
reset = round(float(r.headers[‘X-Rate-Limit-Reset’]) - time())
File “/home/pi/.local/lib/python2.7/site-packages/requests/structures.py”, line 52, in getitem
return self._store[key.lower()][1]
KeyError: ‘x-rate-limit-reset’
python script erro, sleeping few seconds and call it again

You seem to be busy helping a few people on this forum :slight_smile: but I wonder if you’ve had any further thoughts on storing the 5 minute values from the inverter and uploading them separately with the ability to retry if the upload fails?

I know I said some time ago that I’d look at this:

but to be honest I’m not sure that I have the necessary skills. I appreciate your support as always.

Bob.

#112

Hi @bobboulby,

Regargind error I agree they might be related to pvoutput.org downtime.

Actually I was working on this, first I tried to make a buffer inside the existing code, however, the whole thing started to be too much coupled and one change here implied in other changes there… this kind of programming is doomed to fail in the long run. My other approach (not implemented yet) is to complete decouple the solution, one small python to read the inverter and publish it somewhere, another small python to read data from somewhere and upload. This way, one change to publishing code would not impact others and a lot of tests can be done without change the working code (a must since I can only test on my mom´s inverter and when it fails I lose a day o data until I can access again and undo things). The downside is the complexity increase in terms of dependencies. Anyway, I did not give up since I loved the idea and it would open the possibility to have dashboards for instance and also solve a problem I face in my own setup (consumption calculation - another thread for this). I also looked into SBF solution and it is more decoupled, what make me think I am in the right path.

One thing you can try and would somehow solve the lost data “intraday” is to use “wh_total” instead of “wh_today” for the v1 parameter and set the c1 (cumulative). Since “wh_total” keeps the lifetime value, next time pvoutput receives the count it would update the average power and energy generate correctly. Other data would still be missing. To try this solution, on latest master branch, change line 298 (swithc wh_today for wh_total) and line 302 add cumulative flag inside parenthesis, like power_vdc=inv.pv_power, cumulative=1). However, other data would still be missing unfortunately.

@lampra,

The cumulative issue you reported might be related to this. If using wh_total for the v1, cumulative must be set (c1=1). If using wh_today then cumulative must be unset (c1=0).

BRs

#113

However, I forgot to add, there is an error in the logic that decide if v1 shall be sent or not, in the multi-inverter case it will always be sent - we did not want this since it causes average to be zero in the early morning or late afternoon… I will correct this later, it is not a big deal but important to be aware.

#114

I’m happy to change this if you’d like me to test, otherwise I think I’ll leave it as it’s not a big problem.

Bob.

#115

I finally looked at this and you are absolutely right. Line 278 should have cumulative=None and NOT cumulative=False. Or better I think, line 278 test for False and keep 251 as is, makes more sense as cumulative shall be set to True or False, this keeps the API sane I think.

#116

Actually I am using that way, don´t bother yourself.

JrBenito

#117

I just update all branches with a correction to c1 being wrongly set as pointed by @lampra.

On multi-inv branch there is still one missing feature regarding not sending v1 parameter if energy did not change since last update. This was left out on purpose but as also pointed by @lampra systems it shall be implemented.

#118

Does this change impact the single inverter version? Should I update to the latest master from 0.7.1?

Bob.

#119

Yes, the bug impacts every version. Latest master is now tagged v0.7.2 and the only difference to v0.7.1 is this bugfix.

1 Like
#120

Hi,

  1. Today, probably due to change of time (-1 hour) the systems stopped uploading.
    So I think this problem needs to be addressed.
  2. It seems that I had not updated the code since last month and I was only doing changes. Some days ago I updated from the github repo. So today, I tried to restart due to the above mention problem but I can not make the multi inverter version work for more than one inverter.
    This is probably related to commit 4a0d387 but I can’t seem to make it work so I reverted to single system upload for the moment.
    I also suggest that the example in pvoutput.conf.rename should be more explicit i.e.
    #enter a comma separated list of systems, one for each inverter systemID=12345,67890

Here is my config and the error:

    [pvoutput]
    #enter a comma separated list of systems, one for each inverter.
    systemID=12345,67890
    APIKEY='111111111111111111111111111111111'

    [inverters]
    #enter a comma separated list of addresses, defaults to 0x1
    addresses=0x1,0x2
    port='/dev/ttyUSB0'

    root@OpenWrt:~/canadianSolar-pvoutput-multi-inv# sh pvoutput.sh 
    Warnning: Missing system_id, doing nothing
    Warnning: Missing system_id, doing nothing
    ^C
    Exiting by user request.

Edit: I also tested with quotes in the pvoutput.conf, i.e.
systemID='12345,67890'

#121

“Today, probably due to change of time (-1 hour) the systems stopped uploading.”

Just to say no problems with version 0.7.2 with the time change of -1 hour here.

Bob.

#122

Here too, no problem with daylight time. My system wrongly went +1 hour last week and I had no problem besides the wrong hour being reported in the PVoutput. Corrected the timezone and ok again with no restart in the report program. @lampra we need to look deeper into your situation.

About wrongly hour set:
Actually, bit of curious regarding daylight saving time here in Brazil. It used to be a nightmare for system administrators because each year, the day of start and day of stop was chose by the president like two or three months before the start day. It used to change a lot. Well, some years ago they fixed dates like third weekend of October and third with weekend of February (if my mind does not fail me). There were a exception for the start date: national elections; since Brazil has 4 timezones, they claim that the daylight saving (which is not applied to all 4 timezones) would make difficult to handle the elections…
Introduction being told, this year we had the presidential election yesterday and originally the daylight saving would start at 21st October, due election, it was postponed to 4th november. No big deal right? However, someone had the idea to ask president to delay it even more because a national education exam that would be carried on november, 4th. Well, they agreed but due laws it was not possible to delay… so after advertise for everyone that daylight would start on November 11th they pull back to November, 4th.
While the decision was going and coming, the October 21st happened and a lot of systems (including my inverters) went +1 hour on October 21st. Lot of cell phones, lot of bank ATM machines, etc…