pysunspec2 does not work with OutBack AXS Port

[Kheirlb]

I'm not super familar with how modbus works, but I think the suns.py/modbus.py python scripts do not play well with the OutBack AXS Port? Can anyone give me some pointers for how to get this library to work with my AXS unit?

user@hostname:~/GitHub/pysunspec2/scripts $ python3 suns.py -i 192.168.0.64 -P 5020

Timestamp: 2023-11-09T03:16:19Z
Traceback (most recent call last):
  File "/home/pi/GitHub/pysunspec2/scripts/suns.py", line 97, in <module>
    sd.scan()
  File "/home/pi/.local/lib/python3.9/site-packages/sunspec2/modbus/client.py", line 269, in scan
    model_len_data = self.read(addr + 1, 1)
  File "/home/pi/.local/lib/python3.9/site-packages/sunspec2/modbus/client.py", line 341, in read
    return self.client.read(addr, count, op)
  File "/home/pi/.local/lib/python3.9/site-packages/sunspec2/modbus/modbus.py", line 586, in read
    data = self._read(addr + read_offset, read_count, op=op)
  File "/home/pi/.local/lib/python3.9/site-packages/sunspec2/modbus/modbus.py", line 547, in _read
    raise ModbusClientException('Modbus exception %d: addr: %s count: %s' % (except_code, addr, count))
sunspec2.modbus.modbus.ModbusClientException: Modbus exception 2: addr: 43008 count: 1

I changed the port number to avoid permission issues on linux. I also tried -m /model_64110.json. No luck :(

[Kheirlb]

Hmm, today at least the common block seems to be working (not sure what changed besides a reboot).

user@hostname:~/GitHub/pysunspec2/scripts $ python3 suns.py -i 192.168.0.64 -P 5020

Timestamp: 2023-11-10T04:42:22Z
Timestamp: 2023-11-10T04:42:23Z

Model: common (1)

      ID                                                    1
      L                                                    65
      Mn                                        OutBack_Power
      Md                                             AXS_PORT
      Opt                                                None
      Vr                                     003.019.000.2049
      SN                                       AX1709F0100751
      DA                                                    0

Error: Model length 422 not equal to calculated model length 284 for model 64110
Error setting value for WritePassword: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte

The model length error makes sense. The model_64110.json only has 49 "points" defined but there are 166 points in the pdf. I think this means someone with a signed CLA just needs to submit a PR with the fixes?

[Kudrat9]

Hi @Kheirlb

You are correct. It seems like Outback added more points to their model than we have in the models repository. We'll reach out to Outback to ask if they'd be interested in published their updated model. And hopefully, that should fix this issue.

[Kheirlb]

Thanks for the reply here @Kudrat9. Any updates from Outback by chance? I would also love to have a model for DID 64115 "Split Phase Radian Inverter Real Time Block"

[Kudrat9]

@Kheirlb We've emailed the contacts we had from Outback. But we haven't heard back. Some of them turned out to be inactive accounts. We'll let you know if we hear back from them.

[Kheirlb]

Thanks Kudrat9. If anyone else is in the same boat, I have some semi-functional models for 64110 and 64115 available here https://github.com/Kheirlb/models-fork

[Kudrat9]

@Kheirlb Since we never heard back from Outback, we've decided to remove the model 64110 from the models repo to avoid confusion and issues due to the difference in the model that we have and what Outback has posted/updated. Just wanted to let you know. If Outback gets back to us with the updated model, we'll add it to the repo.

[Kheirlb]

Sadness. What could I do to get Outback to support these changes?

[Kudrat9]

I'm afraid there's much you can do. We tried to get in touch but the contacts we had might not be working on updating this model. We will try and mention this in our modbus workgroup to see if someone in the group can give us some information. But until outback decides to share their update, we can't really do anything. Vendors don't have an obligation to share their models. But since this was a case where a shared vendor model changed, it's an unusual situation.