Mine is working fine.
I assume you need a server for the logger to find and connect to. I capture the incoming string with NodeRed (see post above). My logger is version 1.0.57 so I don’t know if that makes a difference.
Server B does not work under some firmware versions. Instead you can redirect the output entirely by going to /config_hide.html
See algodynamic - Reverse Engineering the Solis/Ginlong Inverter Protocol for some information.
Also
Also from Poland, you should check orno we-517 , it,s two way energy meter with serial modbus. It has energy monitoring per phase also.
P.S in my OH3 Regex transformation is working strange, i still don,t have data from datalogger stick… ;-(
//edit
in regex pattern should be one “slash” not two “slash” - wow… now its working
1 Like
I’ve not checked what it does but does the upgrade option work to take you to a version where the Server B does work?
I don’t know. As I have a working monitor I’m reluctant to change the firmware in case the protocol changes.
Understandable. You would hope that upgrading using the OEMs upgrade tool shouldn’t break anything but we’ve all had to spend time unpicking stuff we hoped would work!
I just installed solar panels in the end of March this year.
It is strange my version is 1.0.23 while yours is 1.0.57.
I am living in Melbourne, Australia, where are you?
It is interesting to see hiding configuration page of the solis data logger.
I have thinked about redirecting output to my local machine, but it should be better to let both server A and B working to avoid lost data in case of route issue, internet connection issue or my local server machine maintenance.
So, anyone knows where to get other version of the data logger firmware?
I am in the UK. I don’t know if the sticks can update over the air but my inverter and logger were installed in 2015 so that version could have been around a while.
Hi i can’t get into the hidden config menu and server b does not appear to do anything. status.html does not load so I can’t seem to get a scrape to work.
But if I set server b to a machine in my network the server is pingable
The system is off line so I can’t check the firmware version but what versions are people using, can you access the hidden config and have you had any luck with server b. I will post my firmware version when it’s online.
My installer very kindly gave me a lan stick to play about with.
Some observations based on firmware 1.02(?)
The hidden config page doesn’t exist and the firmware auto upgrade options timeout (suspect they may be pointing to old servers?) on this firmware.
I’ve had mixed success with configuring server B - I initially pointed it at my pi running HA, pinged ok but then I was delayed configuring the pi to receive data. I think this is important because the inverters web interface would keep dropping / refusing connections after I configured the B server. (Only way to get access was to unplug stick to reboot). Luckily data was still sent to ginlong web portal.
Anyway, finally got back on pi and tried the tcp listener in node red, once this was up and running, the lockouts on the web interface disappeared 
On TCP, inverter sends message of approx 14 bits (bytes?) waits a while and then sends one of either 230(ish) or 244. (If received into buffer, total received length each minute is 244 or 258) I’m using the solar man customer option, tcp, ignore response / errors send every minute.
I Left it logging the streams from Friday afternoon until this afternoon and have just started reviewing data to look for patterns and work out how to get the values I want (originally the individual string data) into HA
With the help of a few sources I think I have worked out how to decode the data I need (all my offsets seem to be different than the examples I’ve seen - even accounting for the short message.
Happy to add more info if it can help anyone.
Hi Andy this explains my systems behaviour and why i get lock outs.
Btw to reset the stick undo the clips holding the case together there is a micro switch with it powered on hold it until it goes off
Firmware for mine is v1.0.6
Andy would appreciate any input you can provide
Just checked, same here according to F/W version 1.0.6 (tag at bottom of screen is misleading - says 1.0.1!)
Started decoding my bytes:
165, 1, 0, 16,71, aa, bb, cc, dd, ee, ff, 0, gg, 21
appears to be the “ready to transmit” signal ( I think if the message ends with 21, that is the end of message) “aa” skips one every 5 which is (I suspect) because that is the transmission to Ginlong every 6 minutes
“bb” becomes bb+1 in next part of transmission
cc dd ee & ff are the serial number of the monitoring stick I suspect gg is a checksum (but I haven’t bothered looking into it too deeply)
After the initial transmission the payload is sent starting
165, 232, 0,16,2 aa, bb+1, cc, dd, ee, ff, 1, 7, 5, <3 or 4 data values>, Inverter serial number, temp, dcv1, dcv2, watts?, watts?, ??, AC Voltage, AC Frequency, ??, Total generation, (Lots more date), year, month, day of month, hour, minute, second, (bit more data) 70(+) 0 bytes
I suspect the 70+ bytes at the end are for transmitting digital alarm states
Still finalising the data
Hi Andy sounds interesting there is I think variation on hex length which others have struggled to decode
Yes - I must admit looking at the hex stream being pushed from monitoring stick is difficult - I didn’t really get anywhere.
However I think what has really made life easier is recording the streams (hex converted to decimal) into a csv file for 2-3 days and then looking at in a spreadsheet
All the data most are interested in follows the 16 byte serial number
With it in a table, I could quickly filter and sort to see which bytes were changing (and how) and start identifying the parameters.
Will post my final findings / explanation later this week. I’ve achieved what I wanted with a bit of trial and error and using others work as a starting point.
I’m basically using a tcp node in node-red and feeding the buffer into “buffer parser” node (addon) to a pick the bits of data I have identified to output to HA entities.
One issue was the last message (before the inverter powers down after dusk) has values of 0.1a / xx Volts and ~20watts (and would exist all night until the sun rose and generation picked up again) so I have included a time out on the buffer so that if nothing is received for 3 minutes, the HA generation entities are set to”0”
Hi Andy any help to get everyone up and running would be appreciated. Two years I have been trying different things and it looks like finally something might work
Are your hex data received from the server B setting?
What’s your web ver number?
@abinitio1980 Please share step by step tutorial how to get data from inverter. Appreciate your reply
This is my Node-RED flow
The TCP listener is set to output a single buffer after the connection closes
If it is a “full” message it is processed and also resets the “zero at dusk” timer (the messages are arriving each minute, but if nothing come for 3 minutes, I want 0 sending to some of the values instead of the last value from the inverter before it switched off). Some values, I have added limits before they are passed to the HA entities.
Shorter messages write a timestamp in a file and then 1 second later the buffer is converted to bytes and added to the same file ending with a newline
