search

meltaxa / solariot

Leverage your IoT enabled Solar PV Inverter to stream your solar energy usage data to a real time dashboard.
https://solariot.live
MIT License
201 stars 69 forks source link

Use SungrowModbusTcpClient to read encrypted comms #12

Closed immoos closed 3 years ago

immoos commented 4 years ago

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 commented 4 years ago

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

Is yours working ?

mopedy commented 4 years ago

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. https://github.com/meltaxa/solariot/issues/10

flare04 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

meltaxa commented 3 years ago

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 commented 3 years ago

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

tjhowse commented 3 years ago

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

chrisvivo commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

flare04 commented 3 years ago

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 commented 3 years ago

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

@chrisvivo & @flare04 thanks for testing.

kyrannian commented 3 years ago

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

kyrannian commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 https://github.com/meltaxa/solariot/issues/12#issuecomment-692457563, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACX55SOXV46QRDVQZ37CZHTSF3VDBANCNFSM4NJD7EWQ .

chrisvivo commented 3 years ago

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!

kyrannian commented 3 years ago

@rpvelloso, I think I inadvertently stumbled on your solution. I made two changes, clearing the fifo and caching the inverter key and that seems to have solved my issues even when running on my custom version of @meltaxa 's script. Thanks for all the help

rpvelloso commented 3 years ago

Great!

Em ter, 15 de set de 2020 04:03, kyrannian notifications@github.com escreveu:

@rpvelloso https://github.com/rpvelloso, I think I inadvertently stumbled on your solution. I made two changes, clearing the fifo and caching the inverter key and that seems to have solved my issues even when running on my custom version of @meltaxa https://github.com/meltaxa 's script. Thanks for all the help

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/meltaxa/solariot/issues/12#issuecomment-692511519, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACX55SKRTTMTRJGZ5EXUYUDSF4GVDANCNFSM4NJD7EWQ .

rpvelloso commented 3 years ago

guys,

I have made some changes. The underlying TCP socket was desyncing with the internal FIFO. So whenever connect() is called I'm closing and reestablishing connection and clearing internal FIFO buffer. That seemed to solve the issues. I've also managed to integrate directly into home assistant using modbus integration. It is working without hiccups now.

rpvelloso commented 3 years ago

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

meltaxa commented 3 years ago

Thank you for the community effort in fixing this issue!

Code branch has been merged to master.

rpvelloso commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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

Ruderbaker commented 3 years ago

@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 sslcontext=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 commented 3 years ago

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

meltaxa commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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