Is supporting modifying settings (e.g. power limit, battery usage) in scope for this project?

[bertybuttface]

I noticed home-assistant-solaredge-modbus seems to have support for writing values as well as reading them.

This requires a Modbus RS-485 connection vs just using TCP Modbus.

They have support for some quite useful settings, for example the EXPORT_CONTROL modes and the STOREDGE_CHARGE modes here.

Is this something you wish this package to support?

I'm happy to help with pull requests / testing but I don't want to be responsible for feature creep ruining your hard work so far.

Do you see this package as being a more correct feature complete version of home-assistant-solaredge-modbus?

[bertybuttface]

Ah I just found this: binsentsu/home-assistant-solaredge-modbus#47 (comment)

Is this still your position? Multiple inverters, no control, no batteries?

[WillCodeForCats]

How could my position be no batteries when this clearly supports batteries?

[bertybuttface]

Ok so the no batteries thing is no longer relevant, how about control?

[WillCodeForCats]

I would say any of my comments on a different integration that I stopped participating in are not relevant at all to reference in this one.

[bertybuttface]

Understood, thanks for explaining how the two packages are related below.

[WillCodeForCats]

My skill level with Python and Home Assistant development today is completely different than when I was trying to figure out how to hack things into that integration. During my learning process I also learned I really didn't like how that integration was architected, which led to my total reimplementation goals here.

My coding experience is primarily C/C++ and Perl. I had not used Python before Home Assistant.

[WillCodeForCats]

I've generally adopted the position that if someone figures out a combination of conflicting settings that damage their gear or change a setting that violates a grid tie agreement with their power company, it's not my problem. I've noted the battery stuff as not officially supported by SolarEdge and it's off by default, so anything battery is use at the user's own risk (it already logs a warning if battery detection is enabled).

If you read through #63 you'll see that battery access is very mixed: some don't work, some have had to contact SolarEdge, and some it works fine out of the box. I don't have batteries so I can't really help with any of that: I can implement what docs say and make some best guesses since there isn't any documentation on behavior or data validation like there is with the SunSpec model. The document that has the battery info is not publicly released on the SolarEdge website like the inverter and meter data stuff is, so that is why I consider battery stuff to be unsupported.

I gave up on that other integration since it failed to meet one of my basic needs for too long: multiple inverter support. There was a working pull request to add that, but I see it's still not merged. First I tried to backport changes into a fork with multiple inverter support, but then they started to diverge into changes that were beyond my skill level with Python and HA at the time. Back then I didn't know anything about HA development or even Python, but since then I've learned how to write my own integration (see WillCodeForCats/tekmar-482), then I took everything I learned from my Tekmar integration and rebuilt this one from the ground up starting with the v2.0.0 release. I think my integration is more robust with better error handling, updated dependencies, seeks to follows Home Assistant developer guidelines, has a more user friendly setup, and I am also a user so I make improvements from my own observations. They complete similar tasks on the surface, but solaredge-modbus-multi is its own integration now. It is not a version of another or relying on other work, and I've worked to re-implement everything with my own code.

As far as adding battery control functions, I have some ideas for that and it will probably happen eventually.