'ModbusIOException' object has no attribute 'registers' about solariot HOT 8 CLOSED

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.

from solariot.

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'

from solariot.

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.

from solariot.

Try bumping up the scan_interval in the config.py file (the default is 10 seconds). There could be congestion or load when Sungrow's own reporting takes place.

from solariot.

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.

from solariot.

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.

from solariot.

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.)

from solariot.

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.

from solariot.