if config.model == "sungrow-sh5k" and \
        'grid_import_or_export' in inverter and \
        inverter['grid_import_or_export'] == 65535:
My question is how to fix the remaining errors I get (copied below).Note that sometimes it works (in that I get a non-empty "inverter" object and a write to InfluxDB). Sometimes it aborts with:
[ERROR] 'ModbusIOException' object has no attribute 'registers'

[ERROR] 'ModbusIOException' object has no attribute 'registers'

[ERROR] 'ModbusIOException' object has no attribute 'registers'

Exception in thread Thread-10:

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 "./solariot.py", line 172, in publish_influx

target=flux_client.write_points([metrics])

File "/home/bbeeson/.local/lib/python2.7/site-packages/influxdb/client.py", line 490, in write_points

tags=tags, protocol=protocol)

File "/home/bbeeson/.local/lib/python2.7/site-packages/influxdb/client.py", line 551, in _write_points

protocol=protocol

File "/home/bbeeson/.local/lib/python2.7/site-packages/influxdb/client.py", line 327, in write

headers=headers

File "/home/bbeeson/.local/lib/python2.7/site-packages/influxdb/client.py", line 286, in request

raise InfluxDBClientError(response.content, response.status_code)

InfluxDBClientError: 400: {"error":"unable to parse 'Sungrow,location=Gabba ': invalid field format"}
          
Hi @brettbeeson. I'll remove the hardcoding in the next release, which will contain an update to the modbus map based on feedback received and changes to how it connects to Influxdb so it's more resilient to connection issues. I'll add a develop branch soon with these changes.
In your case, it seems there is a difference between the Influxdb data model and what you are sending it. For example, the data type might have changed between updates. Print the metrics to debug the output and compare this to the Influxdb database. If you changed the location from Gabba to Herston that perhaps should've also been reflected in your output but still appears to be Gabba.
          
Little extra info..
See these errors probably more so than not with the script as well, I just assumed a misread of a register while obtaining register information.
Not sure if it helps but here's the output, not using the database in this scenario.
$> python solariot.py

Load config sungrow-sh5k

Load ModbusTcpClient

Connect

[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] 'grid_import_or_export'

[ERROR] 'WriteMultipleRegistersResponse' object has no attribute 'registers'

[ERROR] 'ModbusIOException' object has no attribute 'registers'

{'use_power': 937, 'total_discharge_energy': 2575.1 }    <- Successful

[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'
          
Hi @meltaxa. I've done some more debugging and found the root exception.
In the line:

rr = client.read_input_registers(...)

The variable rr returns an exception object if it fails, so I added:
 except Exception as err:
    print "[2ERROR] %s" % err
    print "[2ERROR] %s" % rr
Which produces the following output:
client=ModbusTcpClient(10.1.1.8:502)
{'5015': 0, '5016': 0, '5018': 0, '5037': 0, 'pv1_current': 0.0, '5032': 0, 'co2_emission_reduction': 1027, '5031': 0, 'second': 21, '13037': 54, 'pv2_voltage': 0.0, 'year': 2019, 'running_state': 0, 'pv_power': 0, 'daily_export_energy': 0.0, 'use_power': 1000, 'total_pv_power': 0, 'total_pv_energy': 146.8, 'daily_use_energy': 33.6, 'battery_voltage': 57.2, 'internal_temp': 39.4, 'day': 10, 'battery_power': 0, 'daily_pv_energy': 34.1, '13007': 0, 'daily_discharge_energy': 0.0, 'daily_charge_energy': 0.5, 'inverter_current': 0.0, '13009': 0, '5023': 0, '13028': 0, '5003': 336, 'battery_level': 96.8, '5001': 50, 'grid_voltage': 235.2, '5007': 0, '5006': 114, '5005': 0, '5004': 1402, '5021': 0, '5020': 0, '5009': 0, 'total_use_energy': 139.9, 'battery_temp': 32.0, 'battery_health': 100.0, '13035': 0, 'total_discharge_energy': 0.0, 'load_power': 0, 'month': 2, 'grid_frequency': 49.9, 'minute': 55, 'total_charge_energy': 6.7, 'pv1_voltage': 0.0, 'hour': 21, 'export_power': 0, 'grid_import_or_export': 0, '13016': 0, '13014': 0, '13038': 0, '13004': 0, 'battery current': 0.0, 'total_export_energy': 0.2, '13036': 0, '13033': 0, '13030': 85, 'pv2_current': 0.0, '13032': 0, '13019': 0}
[INFO] Sent to InfluxDB
type=read,start=5000,count=100
client=ModbusTcpClient(10.1.1.8:502)
[2ERROR] 'ModbusIOException' object has no attribute 'registers'
[2ERROR] Modbus Error: [Input/Output] Modbus Error: [Invalid Message] Incomplete message received, expected at least 8 bytes (0 received)
So all is well on the first loop, then the second register read fails, as shown on the last output line.
I'm totally new to ModBus, so am not really sure where to start! Any further ideas? In the worst case, I'll just run it as a cronjob, but would be interest to know the reason for the 2nd loop fail.
          
Good idea. I tried that, but that didn't fix the problem. I can repeatedly run the script at short intervals, so it likely some initialization / loop-based effect.
As a workaround, I just run it as a new process, repeatedly, and exit after one loop.
          
The new version which I'll put on a develop branch soon, does just that: runs and exits. The output is saved to a file. Then you can use a collector like Telegraf to schedule the running of Solariot and send the data to any destination.
Edit: Forgot to mention, another advantage of using a collector like Telegraf, is that the data can be buffered if there are connectivity issues.
          
Thanks for the tip. The script is working well posting to influxdb. See the dashboard!
I'm closing the issue.
(Btw, did you ever decipher "running_state" for the Sungrow? I can't make head or tail of it, even assuming its a bitmask.)
          
Nice work. Love the detail. I'll go ahead and close this issue.
The running state is a U16 data type and it's indeed a bit mask:
bit 0: 1 is PV power generation. 0 it's idle.

bit 1: 1 battery is charging. 0 battery idle.

bit 2: 1 battery discharge. 0 battery idle.

bit 3: 1 goes to load. 0 not going to load.

bit 4: 1 feeding the grid. 0 not going to the grid.

bit 5: 1 taking from the grid; 0 not taking from the grid.
I'll have to work out how to code this in the next version.