Support for other Modbus Function Codes

[jmccrohan]

Hi Stephan,

Thanks for this integration; I'm just after discovering it.

Like yourself, I have also been trying to reverse engineer the Solarman V5 protocol and have developed pysolarmanv5. It might be an easier way to implement support for other Modbus function codes. Access to the holding registers would be particularly useful for hybrid inverters to set SOC etc.

Let me know what you think.

Regards, Jon

[StephanJoubert]

Hi Jon,

I have looked at setting parameters - especially in my case controlling grid-export so it may be very useful. Will have a look and experiment a bit to see the possibilities.

Regards

[jmccrohan]

Hi Stephan,

I took some time this evening to go through your code and to try to get it working with my Solis inverter. I got it working, but I need to make some changes.

On a Solis inverter, the realtime information is stored in input (read-only) registers (Modbus Function Code 04), rather than holding registers. Also my inverter stores 32 bit values as big endian, where as your inverter seems to store them as little endian.

Register 1001: 0x1234
Register 1002: 0x5678
vs
Register 1001: 0x5678
Register 1002: 0x1234

Rather than trying to retrofit this into your existing code, would you be open to using pysolarmanv5? If you are, I will work on a PR and add additional configuration options such as word swap etc.

Let me know your thoughts.

[StephanJoubert]

@jmccrohan . I had a look at pysolarmanv5, but not yet had the opportunity to experiment with it. I am certainly open to integrating it so if you work on a PR it would be appreciated.

[TheAnt1dot3]

hey guys,

I'm also an owner of a v5 compatible data logger stick. I've already tested with your pysolarmanV5 (thanks alot for that @jmccrohan) and i am able to read out my registers. I won't mind trying to help out with integrating pysolarmanV5 with hass solarman since i believe this would benefit a growing amount of people.

Give me a shout if you need some hands :)

Thanks !

[jmccrohan]

Hi @StephanJoubert,

I've been working away on this as time allows, and would like to get your views on a few things before I submit the PR.

• The modbus slave ID is currently hardcoded to 1. Any objections to exposing this as a configuration item, with a default of value of 1?
• Given that pysolarmanv5 supports multiple modbus function codes, we'll need to define which FC each of the requests in parameters.yaml refers to; input register, holding register etc.
• Is there value in moving the inverter modbus configuration (parameters.yaml) into native HA config files? The particular use case I am thinking of is writing to registers using function code 06. Some users may wish to define particular switches, similar to the existing HA modbus integration. Users may find their amendments to parameters.yaml overwritten with upgrades via HACS etc.
• To address the endian issue described in my earlier comment, I propose implementing the swap option as referenced here.
• What are your thoughts on replacing the parsing rule for each register with a corresponding struct.unpack format?
• Is there value in retaining the status_connection and the status_lastUpdate sensors? Would they be better replaced with additional debug logging that could be turned on if needed? The status_lastUpdate sensor in particular is problematic because of the huge amount of state updates; 2880 per day @ 30 second interval.
• [very minor nitpick] Any objections to genericising the sunsynk references throughout the code to solarman?

Thanks for the great work.

Jon

[StephanJoubert]

Hi Jon,

I like the suggestions and agree that it will make the component easier to use. I have already merged a PR that replaced the configuration in the yaml file with the config flow, so the next update will be rather large and probably the ideal place for the changes.

1. Agree

2. We can add it in the parameters.yaml file - I would suggest the top portion not per-parameter if that makes sense. I would actually like to trim the yaml file slightly.

   requests:
   - start: 0x0003
   end: 0x0070
   function: 1 <-- inserted here?
   - start: 0x0096  
   end: 0x00f8
   function: 2 <-- inserted here?

3. Sounds great, I was not aware of that option.
4. Agree
5. The rule parser has a bit more than only the data type since the field (ex Uint32) may consist of registers that are not contagious. Found that on the deye specifically. I may not fully understand what you have in mind?
6. Yes we can so away with the "lastUpdate" once the debug messages are there. However I found the status_connection quite useful since HA gives me a graph to see the history of the connection which is quite useful.
7. Yes absolutely. I used the "sunsynk" name in the start and it stuck. It has no meaning at all (I don't even have a synsynk inverter). solarman makes much more sense.

Looking forward to the PR.

Stephan