Closed immoos closed 3 years ago
Hi how is this different to the codes in the code ?
Is yours working ?
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
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 ?
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.
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.
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.
@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
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.
My class already does it. But I can't test it.
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.
I'll test it tomorrow, it's night time here and my inverter is off.
@flare04 Ping! Are you able to help with this testing?
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
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
... and it was me, running 2.7. I have got it going in in 3 :)
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
@kyrannian try increasing the scan_interval (in the config.py file).
@chrisvivo & @flare04 thanks for testing.
@meltaxa, thanks the the reply. tried upping to 60 seconds and still no luck. I'll try a longer again.
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)
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.
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.
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 .
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, 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
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 .
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.
did some minor code clean up, home assistant modbus integration running smoothly so far. I think it is "stable" now.
Thank you for the community effort in fixing this issue!
Code branch has been merged to master.
@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.
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.
@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
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
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):
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.
@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')],)",)
ok, but I think the problem now is connecting to influxdb. Maybe @meltaxa can help there. I'm not familiar with this.
@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)'),))
looks like it's the same error (some SSL problem when connecting to db).
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.
@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"}
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.
@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?
@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
@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
@meltaxa tested this morning when the inverter restarted. It is working.
These are my findings from my inverter. Sorry, it is not an issue but more information.