inverter: add first fronius-modbus backend

[filiplajszczak]

This adds a pure Fronius Modbus command builder for the current inverter control verbs, keeping the register mapping and rate/sign/revert handling testable without any transport or hardware dependency.

It is dead code for the moment, but intentionally so. I’m building the backend inside-out and wanted to start with the smallest pure/testable piece first.

expanded, see #337 (comment)

Ref #329

[MaStr]

Would it be make sense to push more to a feature branch until the first wired version is ready?

[Copilot]

Pull request overview

Adds a transport-agnostic Fronius GEN24 Modbus “command builder” module so inverter control register writes can be generated and unit-tested without hardware/IO dependencies.

Changes:

• Introduces fronius_modbus_commands.py with register constants, value conversions, and builder functions for current control verbs.
• Adds unit tests validating register write ordering and key behaviors (sign handling, scaling, clamping, revert timer preservation).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File	Description
src/batcontrol/inverter/fronius_modbus_commands.py	New pure helpers to build Fronius Modbus holding-register writes for charge/discharge control verbs.
tests/batcontrol/inverter/test_fronius_modbus_commands.py	New tests exercising scaling/sign/clamping and expected register write sets for each verb.

[filiplajszczak]

Would it be make sense to push more to a feature branch until the first wired version is ready?

I’ve grouped the work into a larger branch with the first wired fronius-modbus backend: control/read pieces, inverter composition, TCP transport, factory wiring, and basic validation. I’m also addressing the review comments there.

[MaStr]

Does it make sense to group the different modbus modules in a sub package?
I think so, because, then we have the inverter types on one level and support classes further down the hierarchy.

Or am I overthinking again?

[Copilot]

Pull request overview

Copilot reviewed 20 out of 20 changed files in this pull request and generated 6 comments.

[filiplajszczak]

Does it make sense to group the different modbus modules in a sub package? (...)

I think we could take it in that direction. I recently worked through a very similar plugin-boundary discussion in Briefcase while adding PythonAnywhere publishing support: https://blog.pythonanywhere.com/223/ Discussion: beeware/briefcase#2678 PR: beeware/briefcase#2701

In that case, Briefcase already had plugin patterns for platforms/debuggers, and publication channels extended that architecture. The useful outcome was not just tidier files, but a clearer boundary between core and provider-specific implementation.

So I can either keep this PR to the smaller fronius_modbus package cleanup, or explore a slightly more explicit plugin-style backend pattern if that’s the direction you want.

Or am I overthinking again?

I think this is exactly the kind of tradeoff that is worth overthinking a bit.

[MaStr]

I went through the linked blog article.

Maybe, I explained my idea in the wrong direction.

Currently, alle new module parts are inside the folder "inverter". I proposed to move the submodules for the Fronius-modbus inverter type into a deeper subfolder: ˋinverter/fronius-modbusˋ

Reason is to have the inverter spawned by factory right next to them and additional stuff a folder below inverter.

On discord (we are lurking in a barely used channel) we discussed a plugin mechanism for consumers, but that didn't came pretty far. I did not intend to discuss plugins or not- especially for inverters, which are core functions for batcontrol.

[filiplajszczak]

Thanks, that clarified it.

I went ahead and reshaped the branch in that direction: the Fronius Modbus support modules now live in an internal inverter/fronius_modbus/ package, and the factory imports the backend from there.

[MaStr]

Thank you for the contribution and patience to discuss this with me!

[MaStr]

I went through the code, looks okay with one thing, that I was wondering and didn't discover (bc of time):

Does the class reconnect on connection loss?
How is the shutdown behavior? Does it leave th4 inverter in a kind of clean state?

[filiplajszczak]

Does the class reconnect on connection loss? How is the shutdown behavior? Does it leave the inverter in a kind of clean state?

Good catch. I added one reconnect/retry on connection loss and a best-effort restore to automatic mode on shutdown before closing the transport, to make the backend a bit more resilient and leave the inverter in a cleaner state on exit.