Did you consider using UDP? I find it more reliable

[simon3270]

Hi Graham, looks as though we've been through the same journey!
(just published mine at https://github.com/simon3270/ginlong-python)

I got the same fields as you, but noticed that the data logger supports UDP as well as TCP. I have had problems where, if the receiving code crashes, the system holds on to the TCP port for a long time, making it impossible to rebind to the same port. I have had no similar problems so far with UDP.

One difference with UDP is that there are 2 message types. One is identical to the TCP one, while the other (sent at the same time as the first one) is shorter, and seems just to contain the firmware version of the inverter. I'm guessing that this is used for the centralised Ginlong monitor.

With 2 record types to play with, a couple more fields became apparent:
Offset 0 is always 0x68 (Start of data?)
Offset 1 is a 1-byte message length, 14 bytes less than the overall message length
(so 0x59 for the long message, 0x29 for the short)
Offset 3 is 0xb0 for the long message, 0xb1 for the short
Offset 12 is 0x81 for long messages, 0x80 for short
Offset 13 is the "country standard", 01 for UK

For the long message:
Offset 14 is the power curve version (mine is 0x05)
Offset 15-30 is the inverter number in ASCII (e.g. 000608111111-001)
Offset 101 Checksum - add all bytes from offset 1 to offset 100, modulo 256
Offset 102 is always 0x16 (End of Data?)

For the short message:
Offset 14-51 is the firmware version - mine is H4.01.51Y4.0.02W1.0.57(GL17-07-261-D)V
Offset 52 is the NUL terminator for that string
Offset 53 is the checksum (based on offsets 1 to 52)
Offset 54 is the 0x16 End of Data

I'm still trying to work out:
Offset 65-66 is always 0x000a
Offset 83-86 is always 0xbe360401

Any ideas?

All the best, Simon

[graham0]

Hi Simon,
I must admit I never tried UDP. I have also seen the port lockup problem here. It only seem to happen after long durations so I have a bash script that stops the Python script when the inverter goes to sleep and restarts it in the morning when it wakes up. That has worked reliably for about 5 years now. I have set the inverter up to send it's output to two devices on my network, one of which is a Raspberry Pi, this doesn't seem to suffer from the port lockup issue at all.

The unidentified bits may be alarm conditions. They are difficult to test for unless the inverter fails. I didn't try to cause alarm conditions, as I didn't want to break the inverter. Maybe one to try would be to turn off it's mains supply to see if that pops up anywhere.

When I first looked into logging the output from the inverter there seemed to be no information anywhere. A few people have published their work now. My inverter is a second generation model, I believe the fourth gen models are slightly different.

Regards
Graham

[scadaguru]

Thanks for the work!
I just got installed solar panels and running Solis/Ginlong inverter with lan stick which is hardwired. I can see web page from that IP and has data and I did configure to send data to "Server B" but this script receives nothing I have waited about hour. I see the settings options are little different from you have mentioned:
It has IP and port address but there "Domain" which I left empty and protocol selection is dropdown list which has "Transparent Protocol" which I have selected. When I say "test" it shows blue check of success. And then save, restart but no data. Anything else I can try.
Thanks for the good work!

[graham0]

Hi Scadaguru,
Its possible you have a 4th gen inverter (or even later) which has different output to my 2nd gen model.
Just a few things you can try though assuming you are using the python version:
I have mine set to 'Data Collection' I've not checked if it works in transparent mode.
The tick I suspect just pings the server so it would appear even if the script is not running.
Insert a line in the code just under hexdata = binascii.hexlify(rawdata),
print(hexdata)
You should get data about every 6 minutes, when it arrives you should see the Hex output from the inverter. If you don't see the Hex data appear you may have some sort of network config issue. If it does and the webfile or logfile don't appear check whether the script has write access to the folder you are using to test the script.
If all that checks out and you still have no data like I said earlier you may have a newer inverter than mine. There are some other projects on github that could handle these later models.

Hope this helps
Graham0

[scadaguru]

Hi @graham0
Thanks for the detailed reply.
Yes I have 4th generation 10k inverter. After playing some with setting I started getting data and have print statement as you suggested. It fails header and length check and that makes sense as you said 4th generational may have different firmware providing different data sets.
I will search github 4th inverter support.
Really appreciate your work and time.
Thanks

[simon3270]

Hi Graham. I eventually tired of the AP on the WiFi stick interfering with my main network (it always used the same channel as the network it connected to), so I bought a LAN data Logger Stick. The data layout is, of course, different: different pre-amble and only 2 DC voltages and currents rather than 3. Worst of all, though, while the values on the WiFi stick are big-endian, the ones on the LAN stick are little-endian! I don't think that the development teams for the two ever talked to each other...

[kyanar]

Something I discovered with the Wifi sticks (I don't have a LAN stick to test with) is that the stick also has port 8899 open. I used a TCP/IP MODBUS tool to open that port and throw registers at it and... what do you know... it's the MODBUS polling port! No need to wait for it to hit your python script and have to worry about keeping a long running port open, you can just ask it whenever you want for data. And it has a LOT more registers than are readable from the info it vomits at you on a schedule.

(It goes without saying too that you could move the stick onto an IoT network and not have it send data to Ginlong too!)

[graham0]

Hi Mat, I've just checked my WiFi stick and port 8899 is indeed open. I have no experience of using modbus. A quick scan round the internet and there are loads of modbus tutorials. I can see the advantage of using this approach but I'm not sure at this stage if it is worth the extra effort to understand the protocol and write a program around it when I already have a solution to the problem I set out to solve in the first place. Thanks for getting in touch and pointing out this new possibility, I may have a look at this later. At the moment I don't have any tools to read mmodbus installed on my PC so it's a steep learning curve to get going. Graham0

…

On 06/08/2021 05:28, Mat Barrie wrote: Something I discovered with the Wifi sticks (I don't have a LAN stick to test with) is that the stick also has port 8899 open. I used a TCP/IP MODBUS tool to open that port and throw registers at it and... what do you know... it's the MODBUS polling port! No need to wait for it to hit your python script and have to worry about keeping a long running port open, you can just ask it whenever you want for data. And it has a LOT more registers than are readable from the info it vomits at you on a schedule. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADNB43XNXRDU4SSPVHXVWGDT3NQIRANCNFSM4N7SDECQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>.

[simon3270]

I've just checked the LAN stick, and only port 80 is open. Ah, well, never mind... :-)