Comments (44)
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.
from solariot.
... and it was me, running 2.7. I have got it going in in 3 :)
from solariot.
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
from solariot.
did some minor code clean up, home assistant modbus integration running smoothly so far. I think it is "stable" now.
from solariot.
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.
from solariot.
@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?
from solariot.
Hi how is this different to the codes in the code ?
Is yours working ?
from solariot.
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
from solariot.
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 ?
from solariot.
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.
from solariot.
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.
from solariot.
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.
from solariot.
@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
from solariot.
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.
from solariot.
My class already does it. But I can't test it.
from solariot.
I'll test it tomorrow, it's night time here and my inverter is off.
from solariot.
@flare04 Ping! Are you able to help with this testing?
from solariot.
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
from solariot.
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
from solariot.
@kyrannian try increasing the scan_interval (in the config.py file).
@chrisvivo & @flare04 thanks for testing.
from solariot.
@meltaxa, thanks the the reply. tried upping to 60 seconds and still no luck. I'll try a longer again.
from solariot.
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)
from solariot.
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.
from solariot.
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.
from solariot.
from solariot.
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!
from solariot.
@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
from solariot.
from solariot.
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.
from solariot.
Thank you for the community effort in fixing this issue!
Code branch has been merged to master.
from solariot.
@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.
from solariot.
@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
from solariot.
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):
from solariot.
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.
from solariot.
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')],)",)
from solariot.
ok, but I think the problem now is connecting to influxdb. Maybe @meltaxa can help there. I'm not familiar with this.
from solariot.
@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)'),))
from solariot.
looks like it's the same error (some SSL problem when connecting to db).
from solariot.
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.
from solariot.
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"}
from solariot.
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.
from solariot.
@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
from solariot.
@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
from solariot.
@meltaxa tested this morning when the inverter restarted. It is working.
from solariot.
Related Issues (20)
- RPi4 HA Docker - MQTT No sensor/intergration - modbus proxy?
- sungrow-sg5kd Modbus connection failed HOT 2
- Sungrow SG10RT inverter modbus HOT 10
- WiFi vs Ethernet HOT 9
- python 3.9.2 issues? HOT 1
- Not working with InfluxDB 2.0 HOT 2
- Sungrow SG10RT - "unable to decode request" HOT 17
- InfluxDB and Grafana HOT 1
- SG15RT support HOT 2
- Command errored out with exit status 1 HOT 4
- Adding in the custom user to the Dockerfile broke existing permissions HOT 1
- Failed to scrape inverter: sg8kd HOT 1
- InfluxDBClientError: 400: {"error":"unable to parse 'Sungrow,location=XXXXX ': invalid field format HOT 1
- Error loading config.py HOT 2
- How to create a new device from template
- Quick update
- Sungrow SH5K HOT 1
- Solariot + SMA Inverters xx000TL-20
- WARNING:Modbus connection failed WARNING:Failed to scrape inverter, sleeping until next scan HOT 1
- WARNING:root:Failed to scrape inverter, sleeping until next scan HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from solariot.