Use SungrowModbusTcpClient to read encrypted comms

[immoos]

These are my findings from my inverter. Sorry, it is not an issue but more information.

Sungrow SH5K-20
	"5001",
	"5003",
	"5004",
	"5005",
	"5006",
	"5007",
	"internal_temp_10",
	"5009",
	"pv1_voltage_10",
	"pv1_current_10",
	"pv2_voltage_10",
	"pv2_current_10",
	"5015",
	"5016",
13011	"total_pv_power",
	"5018",
	"grid_voltage_10",
	"5020",
	"5021",
13030	"inverter_current_10",
	"5023",
	"5031",
	"5032",
	"grid_frequency_10",
	"5037",
	"running_state",
13001	"daily_pv_energy_10",
	"total_pv_energy_10",
	"13004",
	"daily_export_energy_10",
13005	"total_export_energy_10",
	"13007",
13007	"load_power",
	"13009",
13008	"export_power",
	"grid_import_or_export",
13039	"daily_charge_energy_10",
	"total_charge_energy_10",
	"13014",
	"co2_emission_reduction",
	"13016",
	"daily_use_energy_10",
	"total_use_energy_10",
	"13019",
13019	"battery_voltage_10",
13020	"battery current_10",
13021	"battery_power",
13022	"battery_level_10",
13023	"battery_health_10",
13024	"battery_temp_10",
	"daily_discharge_energy_10",
	"total_discharge_energy_10",
	"13028",
	"use_power",
	"13030",
	"inverter_current_10",
	"13032",
	"13033",
13033	"pv_power"

[flare04]

Hi how is this different to the codes in the code ?

Is yours working ?

[mopedy]

Hi, mine is working, that is the same as in the code.

Mine is working again now. Had some issue which i guess was related to a possible security update from sungrow closing port 502. #10

[flare04]

OK port 502 is open for me, and I can get a response just not recognisable by this app or pvstats
So did you downgrade the firmware on the Wifi module or just connect via Ethernet port ?

[mopedy]

I had it connected via Ethernet, which worked fine until suspected firmware upgrade. After i had issues i set up connection via Wifi module, which i don't like using due to security issue, it started working again on both interfaces. I am not using pvstats, i only use the influxdb aswell as mqtt services to get the information into Homeassistant, where i monitor the data and currently play around with automation. Like when battery is full and Solar is generating send me a notification so i can turn on the Washing machine, etc.

[tjhowse]

If anyone finds their way here from google and is looking for some more modbus address mappings for the SH5k-20, there are some here: https://github.com/tjhowse/pvstats/blob/master/pvstats/pvinverter/sungrow_sh5k_20.py
It's not complete, but it might help.

For the purpose of helping troubleshoot this issue: I'm running a modbus connection via ethernet to the port inside the inverter. It's running SH5K-V13_FW_V013 according to the info page on the LCD on the front. I manually installed M_WIFI_RAK475_V25_V01_C onto my solarinfo dongle for a test in 2020-03, but I can't say for certain whether this affected the modbus connection as it may have still been working via the ethernet connection.

[meltaxa]

The Sungrow modbus encryption has been busted: https://github.com/rpvelloso/Sungrow-Modbus! I do not have the effected (or perhaps infected) firmware on my inverter. Any PR contributions to use this SungrowModbusTcpClient library will need to consider folks (like me) on older firmware versions (perhaps a config item) to switch between the different modbus tcp clients.

[rpvelloso]

@meltaxa SungrowModbusTcpClient should default to standard TCP client if encryption is not available on the device. Can you test this and confirm if it works (I only have the 'infected' firmware)? Thanks!
https://github.com/rpvelloso/Sungrow-Modbus/blob/master/SungrowModbusTcpClient.py#L20

[meltaxa]

Hey @rpvelloso, thanks for your hard work! You are correct, we need to test if encryption exists, perhaps if a pub key is returned use your lib otherwise default to the unencrypted modbus client. Will endeavor to provide a patch soon.

[rpvelloso]

My class already does it. But I can't test it.

[meltaxa]

Branch created: https://github.com/meltaxa/solariot/tree/%2312-Use-SungrowModbusTcpClient with the changes.

Tested on my inverter which doesn't have the encryption enabled:

Load config sungrow-sh5k
Load relevant ModbusTcpClient
Connect
{'5015': 0, '5016': 0, '5018': 0, '5037': 0, 'pv1_current': 7.6, '5032': 0, 'co2_emission_reduction': 51507, 
'5031': 498, 'second': 36, '13037': 23776, 'pv2_voltage': 197.8, 'year': 2020, 'running_state': 43, 
'pv_power': 498, 'daily_export_energy': 0.1, 'use_power': 961, 'total_pv_power': 3091, 
'total_pv_energy': 3613.3, 'daily_use_energy': 0.8, 'battery_voltage': 55.5, 'internal_temp': 52.2, 'day': 15, 
'battery_power': 2593, 'daily_pv_energy': 1.9, '13007': 1, 'daily_discharge_energy': 1.6, 
'timestamp': '15/9/2020 9:56:36', 'daily_charge_energy': 1.0, 'inverter_current': 2.4, '13009': 0, 
'5023': 0, '13028': 0, '5003': 26, 'battery_level': 12.5, '5001': 50, 'grid_voltage': 240.3, '5007': 0, 
'5006': 24119, '5005': 2, '5004': 35165, '5021': 0, '5020': 0, '5009': 0, 'total_use_energy': 4204.6, 
'battery_temp': 25.0,'battery_health': 100.0, '13035': 0, 'total_discharge_energy': 3758.5, 'load_power': 674, 
'month': 9, 'grid_frequency': 49.9, 'minute': 56, 'total_charge_energy': 3929.1, 'pv1_voltage': 308.0, 
'hour': 9, 'export_power': -175, 'grid_import_or_export': 65535, '13016': 1, '13014': 0, '13038': 0, 
'13004': 2, 'battery current': 46.6, 'total_export_energy': 2033.2, '13036': 6, '13033': 0, '13030': 85, 
'pv2_current': 4.7, '13032': 0, '13019': 0}
[INFO] Sent to InfluxDB

Need someone to test these changes on an encrypted inverter comms before a merge.

[rpvelloso]

I'll test it tomorrow, it's night time here and my inverter is off.

[tjhowse]

@flare04 Ping! Are you able to help with this testing?

[chrisvivo]

Hey guys, I'll assume I'm the problem..

Load config sungrow-sh5k
Load relevant ModbusTcpClient
Connect
Traceback (most recent call last):
  File "solariot.py", line 69, in <module>
    client.connect()
  File "/home/pi/solariot/SungrowModbusTcpClient.py", line 31, in connect
    self._getkey()
  File "/home/pi/solariot/SungrowModbusTcpClient.py", line 22, in _getkey
    self.decipher = AES.new(self.key, AES.MODE_ECB)
  File "/usr/lib/python2.7/dist-packages/Crypto/Cipher/AES.py", line 94, in new
    return AESCipher(key, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/Crypto/Cipher/AES.py", line 59, in __init__
    blockalgo.BlockAlgo.__init__(self, _AES, key, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/Crypto/Cipher/blockalgo.py", line 141, in __init__
    self._cipher = factory.new(key, *args, **kwargs)
ValueError: AES key must be either 16, 24, or 32 bytes long

[kyrannian]

Interestingly, it worked on the first encrypted packet, and then it seems to fail.

Load config sungrow-sh5k                                                                                                                                         
Load relevant ModbusTcpClient                                                                                                                                    
Connect                                                                                                                                                          
{'5001': 50, '5003': 97, '5004': 27505, '5005': 1, '5006': 6137, '5007': 0, 'internal_temp': 54.0, '5009': 0, 'pv1_voltage': 365.30000000000001, 'pv1_current': 6
.5999999999999996, 'pv2_voltage': 371.5, 'pv2_current': 6.2999999999999998, '5015': 0, '5016': 0, 'total_pv_power': 4615, '5018': 0, 'grid_voltage': 251.5, '5020
': 0, '5021': 0, 'inverter_current': 20.100000000000001, '5023': 0, '5031': 4614, '5032': 0, 'grid_frequency': 49.899999999999999, '5037': 0, 'running_state': 79
3, 'daily_pv_energy': 14.699999999999999, 'total_pv_energy': 3032.5999999999999, '13004': 1, 'daily_export_energy': 6.2000000000000002, 'total_export_energy': 42
18.1999999999998, '13007': 0, 'load_power': 788, '13009': 0, 'export_power': 3826, 'grid_import_or_export': 0, 'daily_charge_energy': 5.2000000000000002, 'total_
charge_energy': 2153.4000000000001, '13014': 0, 'co2_emission_reduction': 1567, '13016': 1, 'daily_use_energy': 3.2999999999999998, 'total_use_energy': 3214.5999
999999999, '13019': 0, 'battery_voltage': 57.299999999999997, 'battery current': 0.0, 'battery_power': 0, 'battery_level': 96.799999999999997, 'battery_health': 
95.0, 'battery_temp': 25.0, 'daily_discharge_energy': 0.0, 'total_discharge_energy': 2054.4000000000001, '13028': 0, 'use_power': 360, '13030': 85, '13032': 0, '
13033': 0, 'pv_power': 4614, '13035': 0, '13036': 31, '13037': 24521, '13038': 0, 'year': 2020, 'month': 9, 'day': 15, 'hour': 11, 'minute': 25, 'second': 57}   
[INFO] Sent to InfluxDB                                                                                                                                          
[ERROR] 'ModbusIOException' object has no attribute 'registers'                                                                                                  
[ERROR] 'ModbusIOException' object has no attribute 'registers'                                                                                                  
[ERROR] 'ModbusIOException' object has no attribute 'registers'                                                                                                  
[ERROR] 'grid_import_or_export'                                                                                                                                  
[ERROR] 'ModbusIOException' object has no attribute 'registers'                                                                                                  
[ERROR] 'ModbusIOException' object has no attribute 'registers'                                                                                                  
[ERROR] Key cannot be the null string                                                                                                                            
[ERROR] 'grid_import_or_export'                                                                                                                                  
Traceback (most recent call last):                                                                                                                               
  File "solariot.py", line 209, in <module>                                                                                                                      
    inverter['grid_import_or_export'] == 65535:                                                                                                                  
KeyError: 'grid_import_or_export'                                                                                                                                
                                                                                                                                                                 
During handling of the above exception, another exception occurred:                                                                                              
                                                                                                                                                                 
Traceback (most recent call last):                                                                                                                               
  File "solariot.py", line 245, in <module>                                                                                                                      
    client.connect()                                                                                                                                             
  File "/volume1/homes/admin/solariot/SungrowModbusTcpClient.py", line 31, in connect                                                                            
    self._getkey()                                                                                                                                               
  File "/volume1/homes/admin/solariot/SungrowModbusTcpClient.py", line 22, in _getkey                                                                            
    self.decipher = AES.new(self.key, AES.MODE_ECB)                                                                                                              
  File "/opt/lib/python3.7/site-packages/Crypto/Cipher/AES.py", line 95, in new                                                                                  
    return AESCipher(key, *args, **kwargs)                                                                                                                       
  File "/opt/lib/python3.7/site-packages/Crypto/Cipher/AES.py", line 59, in __init__                                                                             
    blockalgo.BlockAlgo.__init__(self, _AES, key, *args, **kwargs)                                                                                               
  File "/opt/lib/python3.7/site-packages/Crypto/Cipher/blockalgo.py", line 141, in __init__                                                                      
    self._cipher = factory.new(key, *args, **kwargs)                                                                                                             
ValueError: Key cannot be the null string 

[chrisvivo]

... and it was me, running 2.7. I have got it going in in 3 :)

[flare04]

I have this working
I just checked out the branch and configured influxdb and and the config file, it can happily store values in influxdb

[meltaxa]

@kyrannian try increasing the scan_interval (in the config.py file).

@chrisvivo & @flare04 thanks for testing.

[kyrannian]

@meltaxa, thanks the the reply. tried upping to 60 seconds and still no luck. I'll try a longer again.

[kyrannian]

Upon updating timeout to 2 minutes, still the second fetch fails. However, I can run, retrieve the results, exit the program and immediately rerun it and it will process the information again.

This is using a fresh checkout of the branch and using the defaults in the config (other than changing addresses)

[cuong-pham]

Upon updating timeout to 2 minutes, still the second fetch fails. However, I can run, retrieve the results, exit the program and immediately rerun it and it will process the information again.

This is using a fresh checkout of the branch and using the defaults in the config (other than changing addresses)

That's what i did in the code. In the main while loop, client.connect() run the fetch then client.close() at the bottom of the loop. It reduces the number of ModbusException.

[meltaxa]

Hey @kyrannian, that's not an ideal workaround - although that's how I run a customized version of Solariot - I've made telegraf kick it off on a schedule to produce a json file which is then picked up by telegraf's outputs influxdb extension. The advantage of this approach allows for caching of the telemetry in the event of a connection issue (to influxdb). You could also use MQTT to achieve the same.

In the meantime, as per @cuong-pham suggestion, I've moved the connect and close statements to within the loop.

[rpvelloso]

Can you pull my last commit and see if it fixes these issues??? Haven't tested (it is night, inverter is off). Em ter, 15 de set de 2020 01:33, Dennis Mellican <notifications@github.com> escreveu:

…

Hey @kyrannian <https://github.com/kyrannian>, that's not an ideal workaround - although that's how I run a customized version of Solariot - I've made telegraf kick it off on a schedule to produce a json file which is then picked up by telegraf's outputs influxdb extension. The advantage of this approach allows for caching of the telemetry in the event of a connection issue (to influxdb). You could also use MQTT to achieve the same. In the meantime, as per @cuong-pham <https://github.com/cuong-pham> suggestion, I've moved the connect and close statements to within the loop. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACX55SOXV46QRDVQZ37CZHTSF3VDBANCNFSM4NJD7EWQ> .

[chrisvivo]

Running solid for me the last couple of hours with the updates! I have a battery also, so it doesn't shut off at night. I use solariot to control the load of my Tesla charger (TWCManager) so that it only charges from excess solar, great to have this running again!

Thanks so much guys!

[rpvelloso]

did some minor code clean up, home assistant modbus integration running smoothly so far. I think it is "stable" now.

[meltaxa]

Thank you for the community effort in fixing this issue!

Code branch has been merged to master.

[rpvelloso]

@meltaxa did you test it with non-sungrow inverter? I think the line below might not work in this case:
https://github.com/meltaxa/solariot/blob/master/solariot.py#L63
SungrowModbusTcpClient defaults to standard TCP only when it is a "sungrow" without encryption.
With other inverter brands I believe it is better to stick with ModbusTcpClient.

[meltaxa]

Hi @rpvelloso, I may have misunderstood an earlier comment in regards to your class defaulting to ModbusTcpClient if encryption is not asserted. Easy enough to fix - if the model var in the config isn't "sungrow", then use the default client. I'll raise this as a separate ticket. Thanks for the heads up.

[Ruderbaker]

@rpvelloso @kyrannian @chrisvivo

How did you, get it to work?

running with python3 I get this error:

python3 solariot.py
Load config sungrow-sh5k
Load SungrowModbusTcpClient
Connect
Traceback (most recent call last):
File "solariot.py", line 77, in
client.connect()
File "/home/pi/Downloads/solariot-master/SungrowModbusTcpClient.py", line 32, in connect
self._getkey()
File "/home/pi/Downloads/solariot-master/SungrowModbusTcpClient.py", line 22, in _getkey
self._aes_ecb = AES.new(self._key, AES.MODE_ECB)
File "/home/pi/.local/lib/python3.5/site-packages/Crypto/Cipher/AES.py", line 95, in new
return AESCipher(key, *args, **kwargs)
File "/home/pi/.local/lib/python3.5/site-packages/Crypto/Cipher/AES.py", line 59, in init
blockalgo.BlockAlgo.init(self, _AES, key, *args, **kwargs)
File "/home/pi/.local/lib/python3.5/site-packages/Crypto/Cipher/blockalgo.py", line 141, in init
self._cipher = factory.new(key, *args, **kwargs)
ValueError: Key cannot be the null string

This is running on a RPi, directly connected to the SH5K-20 via LAN. Sungrow wireless adapter has been removed from inverter.
Firmware: SH5K-V13_FW_V013

[rpvelloso]

https://github.com/meltaxa/solariot/blob/master/SungrowModbusTcpClient.py#L22
ValueError: Key cannot be the null string

Maybe the inverter is not returning anything when it is asked for the 'public key'. Try changing the line https://github.com/meltaxa/solariot/blob/master/SungrowModbusTcpClient.py#L20 to if (len(self._pub_key) > 0) and (self._pub_key != NO_CRYPTO1) and (self._pub_key != NO_CRYPTO2):

[rpvelloso]

It should fallback to ModbusTcpClient if key is empty. I heard someone say, at the forum, that the inverter does not use encryption via ETH connection, only via Wi-Fi. Maybe that's it.

[Ruderbaker]

@rpvelloso

Starting to work

I get the same errors when I run it in python or python3

Load config sungrow-sh5k
Load SungrowModbusTcpClient
Connect
{'5015': 0, '5016': 0, '5018': 0, '5037': 0, 'pv1_current': 0.0, '5032': 65535, 'co2_emission_reduction': 10, '5031': 62539, 'second': 29, '13037': 38609, 'pv2_voltage': 0.0, 'year': 2020, 'running_state': 658, 'pv_power': 62539, 'daily_export_energy': 0.0, 'use_power': 1000, 'total_pv_power': 0, 'total_pv_energy': 1.5, 'daily_use_energy': 0.0, 'battery_voltage': 52.6, 'internal_temp': 49.2, 'day': 19, 'battery_power': 2997, 'daily_pv_energy': 0.0, '13007': 0, 'daily_discharge_energy': 0.1, 'daily_charge_energy': 0.0, 'inverter_current': 11.9, '13009': 65535, '5023': 0, '13028': 0, '5003': 1, 'battery_level': 49.4, '5001': 50, 'grid_voltage': 250.6, '5007': 0, '5006': 611, '5005': 0, '5004': 3124, '5021': 0, '5020': 0, '5009': 0, 'total_use_energy': 1.5, 'battery_temp': 18.0, 'battery_health': 99.0, '13035': 65535, 'total_discharge_energy': 363.1, 'load_power': 58907, 'month': 9, 'grid_frequency': 49.9, 'minute': 4, 'total_charge_energy': 0.0, 'pv1_voltage': 0.0, 'hour': 12, 'export_power': 3632, 'grid_import_or_export': 0, '13016': 0, '13014': 0, '13038': 1, '13004': 0, 'battery current': 53.7, 'total_export_energy': 0.0, '13036': 78, '13033': 0, '13030': 85, 'pv2_current': 0.0, '13032': 0, '13019': 0}
[INFO] Published to MQTT
Exception in thread Thread-3:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 754, in run
self.__target(*self.__args, **self.__kwargs)
File "/home/pi/Downloads/solariot-master/solariot.py", line 188, in publish_influx
target=flux_client.write_points([metrics])
File "/home/pi/.local/lib/python2.7/site-packages/influxdb/client.py", line 599, in write_points
consistency=consistency)
File "/home/pi/.local/lib/python2.7/site-packages/influxdb/client.py", line 676, in _write_points
protocol=protocol
File "/home/pi/.local/lib/python2.7/site-packages/influxdb/client.py", line 410, in write
headers=headers
File "/home/pi/.local/lib/python2.7/site-packages/influxdb/client.py", line 333, in request
timeout=self._timeout
File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 488, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 609, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 497, in send
raise SSLError(e, request=request)
SSLError: ("bad handshake: Error([('SSL routines', 'ssl3_get_record', 'wrong version number')],)",)

[rpvelloso]

ok, but I think the problem now is connecting to influxdb. Maybe @meltaxa can help there. I'm not familiar with this.

[Ruderbaker]

@rpvelloso
actually, the python3 error is different:

python3 solariot.py
Load config sungrow-sh5k
Load SungrowModbusTcpClient
Connect
{'day': 19, '13028': 0, '13009': 65535, '13035': 65535, '5001': 50, '13016': 0, 'grid_frequency': 50.0, '13038': 1, '13032': 0, 'total_discharge_energy': 363.1, 'grid_voltage': 253.5, '5006': 611, '5016': 0, 'export_power': 3310, 'daily_pv_energy': 0.0, 'pv2_current': 0.0, '5009': 0, 'pv_power': 62550, 'year': 2020, '5037': 0, 'battery_voltage': 52.8, '5018': 0, 'second': 34, '13033': 0, 'use_power': 1000, 'co2_emission_reduction': 10, 'internal_temp': 50.6, 'battery_health': 99.0, 'hour': 12, 'daily_charge_energy': 0.0, 'pv1_current': 0.0, '5031': 62550, 'total_use_energy': 1.5, '13030': 85, '5020': 0, 'minute': 11, '5003': 1, 'daily_discharge_energy': 0.1, 'month': 9, '5023': 0, 'battery_level': 51.5, 'grid_import_or_export': 0, 'total_export_energy': 0.0, '5007': 0, '5005': 0, 'battery_power': 2850, 'load_power': 59240, 'daily_use_energy': 0.0, '13004': 0, '5032': 65535, 'pv2_voltage': 0.0, 'running_state': 658, '5015': 0, '13036': 78, 'daily_export_energy': 0.0, '13037': 38609, 'battery_temp': 18.0, '13014': 0, 'inverter_current': 11.7, 'total_charge_energy': 0.0, '13019': 0, '5021': 0, 'total_pv_power': 0, '5004': 3124, 'total_pv_energy': 1.5, 'battery current': 53.8, '13007': 0, 'pv1_voltage': 0.0}
[INFO] Published to MQTT
Exception in thread Thread-3:
Traceback (most recent call last):
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/connectionpool.py", line 677, in urlopen
chunked=chunked,
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/connectionpool.py", line 381, in _make_request
self._validate_conn(conn)
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/connectionpool.py", line 978, in validate_conn
conn.connect()
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/connection.py", line 371, in connect
ssl_context=context,
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/util/ssl.py", line 397, in ssl_wrap_socket
return context.wrap_socket(sock)
File "/usr/lib/python3.5/ssl.py", line 385, in wrap_socket
_context=self)
File "/usr/lib/python3.5/ssl.py", line 760, in init
self.do_handshake()
File "/usr/lib/python3.5/ssl.py", line 996, in do_handshake
self._sslobj.do_handshake()
File "/usr/lib/python3.5/ssl.py", line 641, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:720)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/pi/.local/lib/python3.5/site-packages/requests/adapters.py", line 449, in send
timeout=timeout
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/connectionpool.py", line 727, in urlopen
method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2]
File "/home/pi/.local/lib/python3.5/site-packages/urllib3/util/retry.py", line 439, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='192.168.1.5', port=8086): Max retries exceeded with url: /write?db=Sungrow (Caused by SSLError(SSLError(1, '[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:720)'),))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
self.run()
File "/usr/lib/python3.5/threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
File "solariot.py", line 188, in publish_influx
target=flux_client.write_points([metrics])
File "/home/pi/.local/lib/python3.5/site-packages/influxdb/client.py", line 599, in write_points
consistency=consistency)
File "/home/pi/.local/lib/python3.5/site-packages/influxdb/client.py", line 676, in _write_points
protocol=protocol
File "/home/pi/.local/lib/python3.5/site-packages/influxdb/client.py", line 410, in write
headers=headers
File "/home/pi/.local/lib/python3.5/site-packages/influxdb/client.py", line 333, in request
timeout=self._timeout
File "/home/pi/.local/lib/python3.5/site-packages/requests/sessions.py", line 530, in request
resp = self.send(prep, **send_kwargs)
File "/home/pi/.local/lib/python3.5/site-packages/requests/sessions.py", line 643, in send
r = adapter.send(request, **kwargs)
File "/home/pi/.local/lib/python3.5/site-packages/requests/adapters.py", line 514, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='192.168.1.5', port=8086): Max retries exceeded with url: /write?db=Sungrow (Caused by SSLError(SSLError(1, '[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:720)'),))

[rpvelloso]

looks like it's the same error (some SSL problem when connecting to db).

[meltaxa]

Check if you are indeed running Influxdb with TLS encryption enabled (for v2 see: https://docs.influxdata.com/influxdb/v2.0/security/enable-tls/). If not, change influxdb_ssl to False in the Solariot config file.

[Ruderbaker]

@meltaxa @rpvelloso

Seems to be getting closer.

python3 solariot.py
Load config sungrow-sh5k
Load SungrowModbusTcpClient
Connect
{'internal_temp': 51.7, '13004': 0, 'inverter_current': 12.0, 'battery_voltage': 53.6, 'year': 2020, 'total_use_energy': 1.5, 'battery current': 53.2, 'pv1_current': 0.0, 'pv2_voltage': 0.0, 'battery_power': 3004, '13016': 0, '13037': 38609, '5020': 0, 'daily_export_energy': 0.0, '13007': 0, 'running_state': 658, '13038': 1, '5016': 0, 'battery_health': 99.0, 'total_discharge_energy': 363.1, 'daily_use_energy': 0.0, '13033': 0, '5032': 65535, 'total_pv_energy': 1.5, '5006': 612, '5005': 0, '5003': 1, 'total_export_energy': 0.0, 'hour': 12, 'total_pv_power': 0, '13035': 65535, 'load_power': 60311, 'daily_pv_energy': 0.0, 'second': 3, 'pv_power': 62532, '5037': 0, '5009': 0, 'co2_emission_reduction': 10, 'grid_voltage': 250.1, '13014': 0, 'pv1_voltage': 0.0, '13030': 85, '13019': 0, 'battery_level': 60.0, 'daily_discharge_energy': 0.1, 'day': 19, '5015': 0, '5023': 0, 'minute': 41, '13032': 0, 'daily_charge_energy': 0.0, '13036': 78, 'pv2_current': 0.0, '5021': 0, 'grid_import_or_export': 0, '5018': 0, '5007': 0, '13009': 65535, '5031': 62532, 'total_charge_energy': 0.0, '5001': 50, '13028': 0, 'export_power': 2221, 'month': 9, 'use_power': 1000, 'battery_temp': 19.0, '5004': 3124, 'grid_frequency': 49.9}
[INFO] Published to MQTT
Exception in thread Thread-3:
Traceback (most recent call last):
File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
self.run()
File "/usr/lib/python3.5/threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
File "solariot.py", line 188, in publish_influx
target=flux_client.write_points([metrics])
File "/home/pi/.local/lib/python3.5/site-packages/influxdb/client.py", line 599, in write_points
consistency=consistency)
File "/home/pi/.local/lib/python3.5/site-packages/influxdb/client.py", line 676, in _write_points
protocol=protocol
File "/home/pi/.local/lib/python3.5/site-packages/influxdb/client.py", line 410, in write
headers=headers
File "/home/pi/.local/lib/python3.5/site-packages/influxdb/client.py", line 369, in request
raise InfluxDBClientError(err_msg, response.status_code)
influxdb.exceptions.InfluxDBClientError: 400: {"error":"partial write: field type conflict: input field "13004" on measurement "Sungrow" is type integer, already exists as type float dropped=1"}

[meltaxa]

A database schema issue because the former update chose a different data type, possibly because it got a null or zero value from that troublesome modbus connection you had.

Easiest fix is to drop that database or create a fresh (new) one and connect to that instead. Update influxdb_database field in the config file accordingly.

[Ruderbaker]

@meltaxa @rpvelloso
That was it.

Thank you both for your help.

One final thing, can you shed some light on the 65535 values? For instance: 'load_power': 59789 Is there a way of displaying this correctly in grafana?

[cuong-pham]

@Ruderbaker this is due to the load_register doesn't get all the value of registers from modbus. I put this check in the code

if len(rr.registers) != int(COUNT):
      print(rr.registers)
      print("Mismatched number ({}) of registers read".format(len(rr.registers)))
      return

before the loop in load_register function

[rpvelloso]

@meltaxa I'm testing this modification to see if it solves the problem of not reconnecting to the inverter next sunrise, if you want to test it too:
https://github.com/rpvelloso/Sungrow-Modbus/blob/master/SungrowModbusTcpClient.py

[rpvelloso]

@meltaxa tested this morning when the inverter restarted. It is working.