Just had solar installed, using a Solis-mini-4G grid tie inverter. Rather than using something like openenergymonitor, I wanted to use the supplied (well, optional) monitoring stick for the inverter. Normally this would go to their own portal, but it also has an option to point to another IP.
I’ve managed to reverse engineer the protocol and written a script to process it and pipe it into MQTT, so that OpenHAB can monitor it.
github repo:
A bit of a write up about it, with more details.
Hi Darren,
I’m so glad I came across this contribution by yourself. I wanted to couple my solis ginlong inverter with openhab, but couldn’t find any binding for it. For other inverters (e.g. SMA) there are already 2.0 bindings.
However, with your script I should be able to perfectly read all variables from my inverter. I’m not a linux nor python expert however and so far have not used MQTT, so I need a bit of guidance.
Following is what I did already:
Tested it, which gave an OK tickmark
Python was already installed on my PI. I understood the following modules are already part of the standard installation: socket, binascii, time, sys, string.
Added the python module paho-mqtt:
sudo pip install paho-mqtt
Which installed fine
sudo apt-get install mosquitto mosquitto-clients python-mosquitto
And then added a mosquitto.conf file in the /etc/mosquitto/conf.d directory with following content:
user ginlong
max_queued_messages 200
message_size_limit 0
allow_zero_length_clientid true
allow_duplicate_messages false
listener 1883
autosave_interval 900
autosave_on_changes false
persistence true
persistence_file mosquitto.db
allow_anonymous true
password_file /etc/mosquitto/passwd
Then did a restart
sudo systemctl restart mosquito
And finally ran mosquitto:
Mosquitto
If I now run mosquitto again, It sais:
1518956001: mosquitto version 1.3.4 (build date 2017-05-29 22:25:09+0000) starting
1518956001: Using default config.
1518956001: Opening ipv4 listen socket on port 1883.
1518956001: Error: Address already in use
So it seems Mosquitto is listening on port 1883.
Python ginglong-listen.py
I get following:
waiting for a connection
Finally
waiting for a connection
Then nothing happens… When I press CTRL^C I get following:
^CTraceback (most recent call last):
File "ginlong-listen.py", line 57, in <module>
conn,addr = sock.accept()
File "/usr/lib/python2.7/socket.py", line 202, in accept
sock, addr = self._sock.accept()
KeyboardInterrupt
I’m a bit stuck now… Could you give me some guidance on what to do next? I guess the next thing I need to do is to run the python script as a service (daemon). Don’t really know how to do that. However, before doing that, I first need to make sure that the script is actually finding a connection, which doesn’t seem to be the case now…
Thanks for your help! I think I’m pretty close already to the solution… 
So, sounds like its all set up correctly, and something is connecting to the daemon, but not sending something that it is expecting. (Hence, you’re getting a ‘Finally’, and then another waiting for connection).
Unfortunately, I’ve been out all day and now its dark I can’t log into my solar system (stupid system that only works when its light!). I’ll take a look tomorrow, assuming the sun is shining.
How long did you leave it running btw? From sniffing the protocols, it does sometimes send a different packet of data that the daemon won’t recognise and just rejects until it gets something that it likes. Might have to wait for a few packets to come in until it gets one that it likes. (It only likes 270 byte long ones).
One of these days I’ll see if I can reverse engineer the other packet types. 
The response from CTRL^C is to be expected. It doesn’t quit gracefully.
I didn’t leave it running for that long, only a few minutes. I’ve tried again this morning and left it running for an hour, but still no change. I get the ‘Finally’ and then again Waiting for a connection.
Something is indeed connecting to the daemon. If I run the script at night (when indeed the stupid system doesn’t work!), I only get waiting for a connection but no ‘Finally.’
OK, I made some progress here…
I figured: what if the length of the hex data is different in my case? so i modified the following in your .py script:
if(len(hexdata) == 270):
into:
if(len(hexdata) < 270):
(I initially tried with >270, but that didn’t give anything)
With the above, I now get the following:
waiting for a connection
Hex data: 685e41b0bb186771bb18677181010501055cfb80008b010000f8bf095a0100d46f0000303030333730303137333039343039301401d40b6c0c0a000800180000000000f70800000000891326020000f0000000ac44000000000000000000000000be0f04a200470037135b16
Serial 0003700173094090
Length 216
MQTT Topic: ginlong/0003700173094090/
vpv1: 292.4
ipv1: 308.2
vac1: 13.7
iac1: 2.4
pac: 0.0
fac: 49.02
temp: 2.0
kwhtoday: 2.4
kwhtotal: 17.2
Finally
Traceback (most recent call last):
File "test.py", line 166, in <module>
publish.multiple(msgs, hostname=mqtt_server)
File "/usr/local/lib/python2.7/dist-packages/paho/mqtt/publish.py", line 152, in multiple
client.connect(hostname, port, keepalive)
File "/usr/local/lib/python2.7/dist-packages/paho/mqtt/client.py", line 768, i n connect
return self.reconnect()
File "/usr/local/lib/python2.7/dist-packages/paho/mqtt/client.py", line 895, i n reconnect
sock = socket.create_connection((self._host, self._port), source_address=(se lf._bind_address, 0))
File "/usr/lib/python2.7/socket.py", line 571, in create_connection
raise err
socket.error: [Errno 111] Connection refused
So seems it’s pumping out some data now after all 
I should note the following about my setup:
This could maybe explain the difference in hex length…
I will need to do some further testing to see if the data which comes out is actually correct…because it may have shifted due to the difference in hex length
So it seems that my monitoring is broken for some reason, and has been for a couple of weeks. 
not even logging to the ginlong website, or registering in DHCP. Guess I’ll have to fix that first.
Tho from what you’ve tried, it sounds like the protocol is slightly different. So may well be a case of reverse engineering that. There should be a file created called rawlog, with the actual raw data in to test/diagnose. Looking at your results, ipv1 and pvp1 both seem very high, and are probably wrong. Unfortunately, reverse engineering it myself isn’t possible I think, as would need access to the real data from the same time stamps.
Of course, if you do manage to figure out the colums, etc. it may be possible to add it to my code so it understands both protocols. Would make it a lot more useful to more people potentially. 
I was looking at interesting Tutorials & Examples as I’m currently in the process of implementing a KNX system with OpenHAB on top of it.
I also have a Ginlong Solis inverter that was installed last summer. Currently my WiFi signal is not that strong enough to always be picked up by the monitoring stick. Now, I have already been looking at solutions to get the solar data out of the inverter.
What I did find was that the solution for Omnik Dataloggers (https://github.com/Woutrrr/Omnik-Data-Logger) also worked for my Ginlong inverter. From the original config file, I only configured the ip and serial number of the inverter. Then it was possible to get data on demand out of the inverter.
So, I’ve dug further into this issue:
My inverter is handing out hex data of 216 length. I can identify the serial code. For the remaining of the code I wrote a python script which basically looked at every 4 character combination. So what it did was:
a = float(int(hexdata[102:106],16))/10
b = float(int(hexdata[104:108],16))/10
c = float(int(hexdata[106:110],16))/10
...
And so on, and then i printed the output of all the variables to a file which I could then compare with the actual data.
I though this way I could easily recognize the different data elements … NOT!
I’ve compared several files of this python output with the actual data when logging into www.ginlongmonitoring.com … but not a single number matched with the actual data. Very strange! It’s as if the data has been encrypted in a way…
Darren, if you’re interested I can pm you an actual data overview with the corresponding hex string and you can give it a go if you want…
Anhyhow - frustrated as I was - I did find another way to get my data into OpenHab and then finally into Grafana. I stumbled upon another page (https://www.domoticz.com/forum/viewtopic.php?f=65&t=7941) where someone wrote a script to extract the data from the monitoring site itself (www.ginlongmonitoring.com). It’s also a python file where you enter your username and password of the site, and then it can pull the data from the site itself
I’ve then made a “merger python script” from the domoticz python script +the script from Darren, basically removing the final code where the data is uploaded to the domoticz host website, and replacing it with the MQTT code from Darren so the data is sent to the MQTT broker.
And result: it works like a charm
So far I don’t have the same amount of variables (Domoticz has defined 5: TodayIncome, ActualPower, etoday, etotal and etotalstr), but it should be possible to also extract the other variables like temperature, frequency, etc… I guess.
Only disadvantage of this approach: the data is extacted from the monitoring website and not from the inverter itself, making you dependent on an external server…
@peterkuterna thanks for also sharing your approach with the Omnik Datalogger. This is then a 3rd viable alternative
@Darren_Poulson Hope you got your solar panels back online!
Glad you’re getting some data back at least.
I did manage to figure out what was wrong, the network cable’s retention tab had broken off and whilst it hadn’t totally fallen out, it had slipped out enough to not register. Working again now.
@peterkuterna Nice looking project you’ve found there, will take a look when theres daylight. Didn’t think it was possible to query the actual device.
@sceppi Unfortunately I don’t think all the variables are 4 bytes, at least there were a couple that I found that weren’t. Just enough to make things confusing. Its also a problem that the protocol supported by my script is different to the one for the ginlong website, and are sent at different intervals. So you’ll never have quite the same values, but instead have to get a load of data and look for trends, etc. Its a painstaking process, and it was my first ever attempt at doing anything like that.
I’m away for a week or so, so won’t have time to look into it properly yet. May get a bit of time tomorrow to have a quick look.
An update on my setup as I now have a powerline wifi adapter installed near the inverter.
I’m using this project to capture the data from the monitoring stick: https://github.com/XtheOne/Inverter-Data-Logger/
I’m using the outputs towards PVoutput & MQTT. The last one to have this as items in my OpenHAB installation.
Hi
I wonder if anyone is watching for questions, i have one on python version, I’m using 3.6 ,will th w scripts for pyton 2,7 still work with this ???
I’ve no idea what the differences between the python versions are really. Try running it and see? Pretty sure it should either run, or just need minor tweaks.
Hi Darren
I wasn’t sure if you monitored the thread.
I’m using mosquito on sensors in home assistant which run in a python virtual env.
Thats giving some minor problems with downloading with PIP the modules required.
even with sudo its refusing to download at the moment, but as soon as I get that sorted ,I’ll
try ruuning your script and see what happens,
The device is a odroid Xu4 which is an octal core ARM SBC, running ubuntu18.04
thanks for the reply
Hello,
I implemented a monitor for NodeJS in combination with influxdb.
I only show the output in a grafana graph so no need to store it in different items like shown above.
Those interested can find the code at: https://github.com/herrJones/ginlong-node
Regards,
Jan
Hi,
Hoping someone is monitoring and can help.
I have a Solis Wifi dongle. I can see in sceppi’s screen shot that it is from firmware 1.0.1. I am on 1.0.20 and in the general world of progress I seem to have far less. I dont have a test option and I dont have a connection protocol.
I have put in a listening IP & port and verified from another machine on the network that there isnt a local firewall blocking the port and its all fine with the exception of the logger says “not connected” even after it has connected to the ginlong monitor. I have left this for 24 hours (including a very sunny day) and still no connection.
I have tried the above MQTT solution for OpenHAB (really really would love this) and didnt work so went to basics and used nc in Linux and a simply python script and not joy. In all cases I can see there were no attempts from the dongle to open a connection never mind send data.
Anyone got this working with the newer firmware?
And the status page says:
Remote server information
Remote server A Connected
Remote server B Not connected
I have exactly the same problem with an ME3000SP. Any luck resolving it?
Hi,
I have a Sofar HYD5000 inverter with attached battery pack. I too have been trying to reverse engineer the comms.
The SolarMan logger sends a variety of packet sizes, the one of most interest is 203 bytes. So far I’ve identified
sometimes the IP address appears in the packet, leaving me to guess that there are variable fields with flag values to indicate what’s coming next.
I’ve failed miserably so far to identify the two PV strings, voltage and current. Or the grid draw.
I dug around the solarmanpv website in the hope of finding some documentation, but failed to get anything at all.
If anyone’s interested in getting their hands on the source code to the C program I wrote which uses pcap to sniff the traffic, let me know. I run it as a man in the middle sniffer.
Paul
Hello guys. @Carl_Meek / @KrisG I had the very same problem, I even tried setting up a simple TCP server to see if I’m getting any connection but no.
What I ended up is this tool I made by myself:
which is very lame in it’s basic but works 
So I set up this simple NodeJS app and set up my items in OpenHAB using HTTP binding:
Number PV_POWER "Value: [%.1f W]" { http="<[http://my_service_ip:8080/:5000:JSONPATH($.power)]" }
where 5000 is 5 seconds refresh interval, rest of the values you bind the same way (see readme in my node project repo)
Any comments / suggestions welcome 
Did you have any thoughts about, if this inverter might be communication through the modbus protocol? I cant see its aavilable communications protocols from its specs, but it looks like there is a RS485, Ethernet/WiFi and CAN bus (CAN bus for the battery probably). So perhaps it could be as simple as tcp modbus or RS485 modbus.
I have a Solis 4G and I use rs485 and modbus rtu for comunication. This way you only need a 2$ usb to rs485 plugged in to your Openhab HW and run modbus binding.