search

bohdan-s / SunGather

GNU General Public License v3.0
148 stars 61 forks source link

Support for SG5K-D #3

Closed rvdblink closed 2 years ago

rvdblink commented 2 years ago

Hey mate,

I'm trying to run SunGather against a SG5K-D with a WiFi V31 dongle. Modbus seems to not work:

2021-12-17 13:47:22 INFO Starting SunGather 0.1.0 2021-12-17 13:47:22 INFO Loaded config: config.yaml 2021-12-17 13:47:23 INFO Loaded registers: registers.yaml 2021-12-17 13:47:23 INFO Loaded Export: exports\console 2021-12-17 13:47:23 INFO Configured Console Logging 2021-12-17 13:47:23 INFO Configured export: console 2021-12-17 13:47:23 INFO Loaded Export: exports\mqtt 2021-12-17 13:47:23 INFO Configured MQTT Client 2021-12-17 13:47:23 INFO Configured export: mqtt 2021-12-17 13:47:23 INFO Connection: ModbusTcpClient(192.168.0.6:502) 2021-12-17 13:47:23 DEBUG Connection to Modbus server established. Socket ('10.0.1.249', 47621) 2021-12-17 13:47:23 DEBUG load_registers: read, 4999:1 2021-12-17 13:47:23 DEBUG Connection to Modbus server established. Socket ('10.0.1.249', 51883) 2021-12-17 13:47:23 DEBUG Current transaction state - IDLE 2021-12-17 13:47:23 DEBUG Running transaction 1 2021-12-17 13:47:23 DEBUG SEND: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x4 0x13 0x87 0x0 0x1 2021-12-17 13:47:23 DEBUG New Transaction state 'SENDING' 2021-12-17 13:47:23 DEBUG Changing transaction state from 'SENDING' to 'WAITING FOR REPLY' 2021-12-17 13:47:23 DEBUG Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY' 2021-12-17 13:47:23 DEBUG RECV: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x84 0x4 2021-12-17 13:47:23 DEBUG Processing: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x84 0x4 2021-12-17 13:47:23 DEBUG Frame check failed, ignoring!! 2021-12-17 13:47:23 DEBUG Getting transaction 1 2021-12-17 13:47:23 DEBUG Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE' 2021-12-17 13:47:23 WARNING Modbus connection failed

But it might be its failing out because I can't see the SG5K-D being supported?

bohdan-s commented 2 years ago

Looks like model detection is failing. Can you try adding the model to config.py and let me know if it works?

rvdblink commented 2 years ago

Same story. I tried it with SG5KD, sg5kd, SG5K-D, sg5k-d; all give this:

ronald@dockernuc:~/src/SunGather/SunGather$ python3 sungather.py 2021-12-17 22:34:30 INFO Starting SunGather 0.1.0 2021-12-17 22:34:30 INFO Loaded config: config.yaml 2021-12-17 22:34:30 INFO Loaded registers: registers.yaml 2021-12-17 22:34:30 INFO Loaded Export: exports\console 2021-12-17 22:34:30 INFO Configured Console Logging 2021-12-17 22:34:30 INFO Configured export: console 2021-12-17 22:34:30 INFO Loaded Export: exports\mqtt 2021-12-17 22:34:30 INFO Configured MQTT Client 2021-12-17 22:34:30 INFO Configured export: mqtt 2021-12-17 22:34:30 INFO Connection: ModbusTcpClient(192.168.0.6:502) 2021-12-17 22:34:30 DEBUG load_registers: read, 4999:1 2021-12-17 22:34:30 DEBUG Current transaction state - IDLE 2021-12-17 22:34:30 DEBUG Running transaction 1 2021-12-17 22:34:30 DEBUG SEND: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x4 0x13 0x87 0x0 0x1 2021-12-17 22:34:30 DEBUG New Transaction state 'SENDING' 2021-12-17 22:34:30 DEBUG Changing transaction state from 'SENDING' to 'WAITING FOR REPLY' 2021-12-17 22:34:30 DEBUG Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY' 2021-12-17 22:34:30 DEBUG RECV: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x84 0x4 2021-12-17 22:34:30 DEBUG Processing: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x84 0x4 2021-12-17 22:34:30 DEBUG Frame check failed, ignoring!! 2021-12-17 22:34:30 DEBUG Getting transaction 1 2021-12-17 22:34:30 DEBUG Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE' 2021-12-17 22:34:30 WARNING Modbus connection failed sungather.py:257: DeprecationWarning: The 'warn' function is deprecated, use 'warning' instead logging.warn(f'Model specified in config {config["inverter"].get("model")} does not match model reported by inverter {model}') 2021-12-17 22:34:30 WARNING Model specified in config sg5kd does not match model reported by inverter None 2021-12-17 22:34:30 DEBUG Scanning: hold, 4999:10 2021-12-17 22:34:30 DEBUG load_registers: hold, 4999:10 2021-12-17 22:34:30 DEBUG Current transaction state - TRANSACTION_COMPLETE 2021-12-17 22:34:30 DEBUG Running transaction 2 2021-12-17 22:34:30 DEBUG SEND: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x3 0x13 0x87 0x0 0xa 2021-12-17 22:34:30 DEBUG New Transaction state 'SENDING' 2021-12-17 22:34:30 DEBUG Changing transaction state from 'SENDING' to 'WAITING FOR REPLY' 2021-12-17 22:34:30 DEBUG Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY' 2021-12-17 22:34:30 DEBUG RECV: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x83 0x4 2021-12-17 22:34:30 DEBUG Processing: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x83 0x4 2021-12-17 22:34:30 DEBUG Frame check failed, ignoring!! 2021-12-17 22:34:30 DEBUG Getting transaction 2 2021-12-17 22:34:30 DEBUG Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE' 2021-12-17 22:34:30 WARNING Modbus connection failed

I'd love to use http (which your tool also supports) but it seems the SG5K-D doesn't have a web stream running on 8052...

bohdan-s commented 2 years ago

@rvdblink Interesting the inverter doesn't come up as supported in the official documentation. I have change the detection to be a bit more fail safe now. Could you please try again (after git pull)? With: connection: sungrow model: "SG5KD" logging: 10 This should work with the generic registers, and full debug. Could you post the full log after 1 run (default in 30 seconds)

Could you also email info@sungrowpower.com.au and ask them for a copy of the modbus register for your model? The support look up the model registered to your isolar account and wont provide it for other models. If you can get it I can update the registers list to add the specific model

dbaines commented 2 years ago

I have an SG5K-D and a v31 wifi dongle as well. I'm getting output on the http export server and the numbers seem pretty accurate. I'm running in docker with the config model commented out so I guess it's autodetecting fine. I enabled smart_meter and I enabled use_local_time because the inverter wasn't reporting DST correctly, it was an hour behind.

However the MQTT export is failing. I'm guessing from the logs it has something to do with replacing the model in the MQTT topic.

Here is the relevant log:

Exception in thread Thread-1009 (publish):
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/threading.py", line 1009, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.10/threading.py", line 946, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/src/sungather/exports/mqtt.py", line 38, in publish
    self.sensor_topic = self.sensor_topic.replace('{model}', inverter.get('device_type_code', 'unknown').replace('.',''))
AttributeError: 'int' object has no attribute 'replace'

It's running via portainer on a qnap device.

Edit: I have tried using a custom topic, eg: topic: "tele/inverter_test/SENSOR" but it shows the same error in the log.

bohdan-s commented 2 years ago

Yes, it doesn’t support “.” or “-“ in MQTT topic. I need to clear the “-“ from the model, which I have done. Just need to push and build docker again. Should hopefully be able to do that soon.

bohdan-s commented 2 years ago

@dbaines could you provide the device_type_code? I'll add it to the auto-detection code for future as well.

dbaines commented 2 years ago

@bohdan-s sure thing, this is what the http logging shows:

device_type_code    294
bohdan-s commented 2 years ago

@dbaines I have published v0.1.2 to git and Docker. It should fix the model detection errors, and add support for your model.

dbaines commented 2 years ago

@bohdan-s Thanks, appears to be working beautifully now! My inverter is being detected as SGK5-D and the MQTT is no longer erroring.

I've noticed in the logs that everytime it publishes to MQTT there appears to be an exception thrown on the modbus connection:

2022-01-05 19:23:55 DEBUG    load_registers: read, 7012:25
2022-01-05 19:23:55 DEBUG    Connection to Modbus server established. Socket ('<IP>', 48345)
2022-01-05 19:23:55 DEBUG    Connection to Modbus server established. Socket ('<IP>', 32973)
2022-01-05 19:23:55 DEBUG    Current transaction state - TRANSACTION_COMPLETE
2022-01-05 19:23:55 DEBUG    Running transaction 77
2022-01-05 19:23:55 DEBUG    Connection to Modbus server established. Socket ('<IP>', 60535)
2022-01-05 19:23:55 DEBUG    Connection to Modbus server established. Socket ('<IP>', 52975)
2022-01-05 19:23:55 DEBUG    SEND: 0x0 0x4d 0x0 0x0 0x0 0x6 0x1 0x4 0x1b 0x64 0x0 0x19
2022-01-05 19:23:55 DEBUG    New Transaction state 'SENDING'
2022-01-05 19:23:55 DEBUG    Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
2022-01-05 19:23:55 DEBUG    Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2022-01-05 19:23:55 DEBUG    RECV: 0x0 0x4d 0x0 0x0 0x0 0x3 0x1 0x84 0x0
2022-01-05 19:23:55 DEBUG    Processing: 0x0 0x4d 0x0 0x0 0x0 0x3 0x1 0x84 0x0
2022-01-05 19:23:55 DEBUG    Factory Response[132]
2022-01-05 19:23:55 DEBUG    Adding transaction 77
2022-01-05 19:23:55 DEBUG    Getting transaction 77
2022-01-05 19:23:55 DEBUG    Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2022-01-05 19:23:55 WARNING  Modbus connection failed: Exception Response(132, 4, None)
2022-01-05 19:23:55 INFO     Updated Webserver Content
2022-01-05 19:23:55 INFO     Published to MQTT

This might be related to the exception thrown but I'm only getting a single auto-discovered sensor in Home Assistant, 'Daily Generation'

When I compare the list of ha_topics to the register output in the http export, I notice I don't have import_from_grid or export_from_grid registers.

I do have these registers though:

daily_export_energy 207
total_export_energy 18453
daily_import_energy 13
total_import_energy 3339

I am using smart_meter: True and manual_load: True

Let me know if there's anything else I can provide to help.

bohdan-s commented 2 years ago

Thanks for the log, it seems I fat fingered a value. I'll push a fix tomorrow. Sorry about that.

dbaines commented 2 years ago

It seems like at some point overnight it started failing, I assume when the inverter goes to sleep overnight but I can't be certain. 

2022-01-06 09:21:31 DEBUG    Connection to Modbus server established. Socket ('<IP>', 42711)
2022-01-06 09:21:31 DEBUG    Connection to Modbus server established. Socket ('<IP>', 41099)
2022-01-06 09:21:31 DEBUG    Scanning: read, 5000:100
2022-01-06 09:21:31 DEBUG    load_registers: read, 5000:100
2022-01-06 09:21:31 DEBUG    Connection to Modbus server established. Socket ('<IP>', 58369)
2022-01-06 09:21:31 DEBUG    Connection to Modbus server established. Socket ('<IP>', 47889)
2022-01-06 09:21:31 DEBUG    Current transaction state - TRANSACTION_COMPLETE
2022-01-06 09:21:31 DEBUG    Running transaction 3167
2022-01-06 09:21:31 DEBUG    Clearing current Frame : - 0xc
2022-01-06 09:21:31 DEBUG    Connection to Modbus server established. Socket ('<IP>', 50613)
2022-01-06 09:21:31 DEBUG    Connection to Modbus server established. Socket ('<IP>', 46811)
2022-01-06 09:21:31 DEBUG    SEND: 0xc 0x5f 0x0 0x0 0x0 0x6 0x1 0x4 0x13 0x88 0x0 0x64
2022-01-06 09:21:31 DEBUG    New Transaction state 'SENDING'
2022-01-06 09:21:31 DEBUG    Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
2022-01-06 09:21:32 DEBUG    Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2022-01-06 09:21:32 DEBUG    RECV: 0xc
2022-01-06 09:21:32 DEBUG    Processing: 0xc
2022-01-06 09:21:32 DEBUG    Factory Response[GetCommEventLogResponse: 12]
2022-01-06 09:21:32 ERROR    index out of range
2022-01-06 09:21:32 ERROR    Modbus Error: [Input/Output] Unable to decode request
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/pymodbus/transaction.py", line 208, in execute
    self.client.framer.processIncomingPacket(response,
  File "/usr/local/lib/python3.10/site-packages/pymodbus/framer/socket_framer.py", line 165, in processIncomingPacket
    self._process(callback, error=True)
  File "/usr/local/lib/python3.10/site-packages/pymodbus/framer/socket_framer.py", line 175, in _process
    raise ModbusIOException("Unable to decode request")
pymodbus.exceptions.ModbusIOException: Modbus Error: [Input/Output] Unable to decode request
2022-01-06 09:21:32 WARNING  Modbus connection failed: Modbus Error: [Input/Output] Unable to decode request
2022-01-06 09:21:32 INFO     Updated Webserver Content
2022-01-06 09:21:32 INFO     Published to MQTT

Restarting the docker container fixed the issue.

bohdan-s commented 2 years ago

@dbaines is it possible the inverter turns off over night? I'll see if I can get some more resilience in the code to re-start the connections in the case of an error

dbaines commented 2 years ago

@bohdan-s yep I think it does

bohdan-s commented 2 years ago

v0.1.3 should resolve issues with connection being dropped. Could you test for me when you have time?

dbaines commented 2 years ago

Thanks @bohdan-s I've updated but now it seems like the export isn't working

2022-01-07 19:54:36 DEBUG    load_registers: read, 7012:25
2022-01-07 19:54:36 DEBUG    Connection to Modbus server established. Socket ('<IP>', 48167)
2022-01-07 19:54:36 DEBUG    Connection to Modbus server established. Socket ('<IP>', 34209)
2022-01-07 19:54:36 DEBUG    Current transaction state - TRANSACTION_COMPLETE
2022-01-07 19:54:36 DEBUG    Running transaction 4
2022-01-07 19:54:36 DEBUG    Connection to Modbus server established. Socket ('<IP>', 44661)
2022-01-07 19:54:36 DEBUG    Connection to Modbus server established. Socket ('<IP>', 34117)
2022-01-07 19:54:36 DEBUG    SEND: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x4 0x1b 0x64 0x0 0x19
2022-01-07 19:54:36 DEBUG    New Transaction state 'SENDING'
2022-01-07 19:54:36 DEBUG    Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
2022-01-07 19:54:36 DEBUG    Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2022-01-07 19:54:36 DEBUG    RECV: 0x0 0x4 0x0 0x0 0x0 0x3 0x1 0x84 0x0
2022-01-07 19:54:36 DEBUG    Processing: 0x0 0x4 0x0 0x0 0x0 0x3 0x1 0x84 0x0
2022-01-07 19:54:36 DEBUG    Factory Response[132]
2022-01-07 19:54:36 DEBUG    Adding transaction 4
2022-01-07 19:54:36 DEBUG    Getting transaction 4
2022-01-07 19:54:36 DEBUG    Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2022-01-07 19:54:36 WARNING  Modbus connection failed: Exception Response(132, 4, None)
2022-01-07 19:54:36 WARNING  Data collection failed, skipped exporting data. Retying in 30
bohdan-s commented 2 years ago

Sorry, ignore that, You are reading 7012 for 25 registers. And that is failing. I think these are mainly for hybrid inverters, seems my SG7.0RT returns 0xFF and your model is returning an error code. I'll add code to capture this and continue correctly. Thanks for the help, reverse engineering is hard, much easier with the spec. You can revert to tag 0.1.2 or wait and I'll push a fixed build tomorrow.

bohdan-s commented 2 years ago

@dbaines @rvdblink I have pushed a huge update to v0.2.0. The way registers are processed has been re-writen so it should now only access the correct registers, and be much quicker.

dbaines commented 2 years ago

Thanks @bohdan-s I have updated but I still seem to be getting the modbus error:

2022-01-13 21:17:48 DEBUG    Factory Response[ReadInputRegistersResponse: 4]
2022-01-13 21:17:48 DEBUG    Adding transaction 5
2022-01-13 21:17:48 DEBUG    Getting transaction 5
2022-01-13 21:17:48 DEBUG    Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2022-01-13 21:17:48 DEBUG    Scraping: read, 6199:100
2022-01-13 21:17:48 DEBUG    load_registers: read, 6199:100
2022-01-13 21:17:48 DEBUG    Connection to Modbus server established. Socket ('<IP>', 59771)
2022-01-13 21:17:48 DEBUG    Connection to Modbus server established. Socket ('<IP>', 41557)
2022-01-13 21:17:48 DEBUG    Current transaction state - TRANSACTION_COMPLETE
2022-01-13 21:17:48 DEBUG    Running transaction 6
2022-01-13 21:17:48 DEBUG    Connection to Modbus server established. Socket ('<IP>', 55269)
2022-01-13 21:17:48 DEBUG    Connection to Modbus server established. Socket ('<IP>', 52833)
2022-01-13 21:17:48 DEBUG    SEND: 0x0 0x6 0x0 0x0 0x0 0x6 0x1 0x4 0x18 0x37 0x0 0x64
2022-01-13 21:17:48 DEBUG    New Transaction state 'SENDING'
2022-01-13 21:17:48 DEBUG    Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
2022-01-13 21:17:48 DEBUG    Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2022-01-13 21:17:48 DEBUG    RECV: 0x0 0x6 0x0 0x0 0x0 0xcb 0x1 0x4 0xc8 0x0 0xf0 0x0 0xd9 0x0 0xc0 0x0 0xf2 0x1 0xa8 0x1 0x6a 0x1 0x8e 0x1 0x7f 0x1 0x78 0x1 0xa2 0x1 0x78 0x1 0xaa 0x1 0x86 0x1 0xa5 0x1 0x6c 0x1 0x94 0x1 0xa6 0x1 0xa7 0x1 0xa7 0x1 0xac 0x1 0xa8 0x1 0xac 0x1 0xad 0x1 0xa8 0x1 0x42 0x1 0x9f 0x1 0xa0 0x1 0xb5 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xa5 0x2 0x19 0x4 0xc7 0x0 0x0 0x0 0x0 0x0 0x0 0x7 0x85 0x1 0xb5 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x5f 0xe6 0xa6 0x39 0x72 0x47 0x31 0xdd 0x9d 0xc9 0x3 0x73 0xb3 0xde 0xf6 0xdb 0x3f 0xd3 0x1d 0x1c 0x0 0x37 0x3 0x4 0x32 0x41 0x46 0x44 0x5f 0x30 0x36 0x30 0x30 0x31 0x2e 0x30 0x31 0x2e 0x30 0x33 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x35 0x0 0x3 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x3 0x0 0x1 0x0 0x3 0x75 0x30 0xb3 0xc9 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
2022-01-13 21:17:48 DEBUG    Processing: 0x0 0x6 0x0 0x0 0x0 0xcb 0x1 0x4 0xc8 0x0 0xf0 0x0 0xd9 0x0 0xc0 0x0 0xf2 0x1 0xa8 0x1 0x6a 0x1 0x8e 0x1 0x7f 0x1 0x78 0x1 0xa2 0x1 0x78 0x1 0xaa 0x1 0x86 0x1 0xa5 0x1 0x6c 0x1 0x94 0x1 0xa6 0x1 0xa7 0x1 0xa7 0x1 0xac 0x1 0xa8 0x1 0xac 0x1 0xad 0x1 0xa8 0x1 0x42 0x1 0x9f 0x1 0xa0 0x1 0xb5 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xa5 0x2 0x19 0x4 0xc7 0x0 0x0 0x0 0x0 0x0 0x0 0x7 0x85 0x1 0xb5 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x5f 0xe6 0xa6 0x39 0x72 0x47 0x31 0xdd 0x9d 0xc9 0x3 0x73 0xb3 0xde 0xf6 0xdb 0x3f 0xd3 0x1d 0x1c 0x0 0x37 0x3 0x4 0x32 0x41 0x46 0x44 0x5f 0x30 0x36 0x30 0x30 0x31 0x2e 0x30 0x31 0x2e 0x30 0x33 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x35 0x0 0x3 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x3 0x0 0x1 0x0 0x3 0x75 0x30 0xb3 0xc9 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
2022-01-13 21:17:48 DEBUG    Factory Response[ReadInputRegistersResponse: 4]
2022-01-13 21:17:48 DEBUG    Adding transaction 6
2022-01-13 21:17:48 DEBUG    Getting transaction 6
2022-01-13 21:17:48 DEBUG    Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2022-01-13 21:17:48 DEBUG    Scraping: read, 6299:100
2022-01-13 21:17:48 DEBUG    load_registers: read, 6299:100
2022-01-13 21:17:48 DEBUG    Connection to Modbus server established. Socket ('<IP>', 59079)
2022-01-13 21:17:48 DEBUG    Connection to Modbus server established. Socket ('<IP>', 39883)
2022-01-13 21:17:48 DEBUG    Current transaction state - TRANSACTION_COMPLETE
2022-01-13 21:17:48 DEBUG    Running transaction 7
2022-01-13 21:17:48 DEBUG    Connection to Modbus server established. Socket ('<IP>', 49051)
2022-01-13 21:17:48 DEBUG    Connection to Modbus server established. Socket ('<IP>', 53705)
2022-01-13 21:17:48 DEBUG    SEND: 0x0 0x7 0x0 0x0 0x0 0x6 0x1 0x4 0x18 0x9b 0x0 0x64
2022-01-13 21:17:48 DEBUG    New Transaction state 'SENDING'
2022-01-13 21:17:48 DEBUG    Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
2022-01-13 21:17:48 DEBUG    Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
2022-01-13 21:17:48 DEBUG    RECV: 0x0 0x7 0x0 0x0 0x0 0x3 0x1 0x84 0x0
2022-01-13 21:17:48 DEBUG    Processing: 0x0 0x7 0x0 0x0 0x0 0x3 0x1 0x84 0x0
2022-01-13 21:17:48 DEBUG    Factory Response[132]
2022-01-13 21:17:48 DEBUG    Adding transaction 7
2022-01-13 21:17:48 DEBUG    Getting transaction 7
2022-01-13 21:17:48 DEBUG    Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
2022-01-13 21:17:48 WARNING  Modbus connection failed: Exception Response(132, 4, None)
2022-01-13 21:17:48 WARNING  Data collection failed, skipped exporting data. Retying in 30 secs
2022-01-13 21:17:48 DEBUG    Processing Time: 3.196052 secs
bohdan-s commented 2 years ago

What level are you using? It is trying to read registers only used by Hybrid inverters, do you have level 3 set? Try with 1 or 2?

dbaines commented 2 years ago

Thanks @bohdan-s setting level back to 1 did the trick! Looks like it's all working now, I'll monitor and let you know if I run in to any issues :)

bohdan-s commented 2 years ago

@dbaines just pushed v0.2.1 so if only some of the scans fail it will continue with a warning, if all fail then it will flag as an error. This should allow level 3 to work again. I would suggest staying level 1 for day to day use as it will be much faster, level 1 is 1.5s on my inverter, level 3 is 7s per scan.

dbaines commented 2 years ago

@bohdan-s Looks great! Still up and running this morning.

I had to make some updates to the configuration mqtt export section to make it work with home assistant. There's now a required homeassistant: True flag and ha_topics is now ha_sensors.

Once I changed those two in my config autodiscovery was working and the sensors are showing up in home assistant! Really great stuff, thanks :)

bohdan-s commented 2 years ago

You should also be getting the running state of On or Off feed into HA as well now :)

bohdan-s commented 2 years ago

Closing this issue, as Inveter seems to be supported now