Question about the integration

[mike4001]

Hi, I just found your integration as a user of callifos fork.

1. I read that some entities would get adjusted names. But apart from that is the integration replaceable with yours without loosing anything?
2. And of course these are not "my" integrations but I am asking myself, wouldn't a colaboration not make sense? It seems to me that you are using the more modern modbus integration but there are gifted programmers on callifos integration as well. Why not work together if this is somehow possible?

Just some thoughts :-)

[Varitras]

Hi mike,
yes, you can move to this integration without losing anything. But as always: backup first, please :)
Only two display names change: SoC Minimum -> Modbus storage reserve, Battery API mode -> Self-consumption optimisation. Entity ids are the same.
New: SoC Minimum (Web API), Web API SoC mode, Backup reserve, Throttle reason. The minimum requirement is now Home Assistant 2026.9.
Best way is to replace the folder in custom_components, or in HACS: remove the old repository without removing the integration, add this one as a custom repository, download it and restart.

I'm afraid a merge upstream is not possible. The Modbus layer was rewritten onto Home Assistant's shared Modbus connection, so there are too many changes across the whole repo. The only way I can imagine is replacing the old version completely with this one. I'm not sure callifo wants that, but he is welcome to take it. But Individual fixes that don't depend on the new base I am happy to send upstream as pull requests.

Thanks :)

[mike4001]

Thank you for your answers. OK I kind of understand, if you changed to much underlaying code this is no simple thing you can add to the other integration.

But I can give you some feedback.

I have a Home Assistant at Home (Symo Gen24 12.0) and a Home Assistant at my company (Verto 30.0 Plus). The Home Assistant at the company is basically just for me to fool around as it does not do much. So I switched over to your integration to do some testing.

Basically it is working but there are a few points :-)

1. I get a statistics fault that sensor.reserva_capacity no longer has a state class and so no long term statistics can be generated anymore.
2. Generally when I change a mode (for instance Self-consumption optimisation) is now at Automatic. If I change this to Manual it switches immediately back to Automatic and after 5-10 seconds it switches back to Manual. Don't know if this is intended but I noticed it and this did not happen in the other integration
3. Why is there a different Modbus Min SoC and WebApi Min SoC? Is this necessary because if I change one the other one should change itself?
4. There is currently a mix of sliders and numerical inputs for the percentages in the battery page. For me personally I like to see the percentage.

[Varitras]

Thank you for the testing

1, 2 and 4 are fixed in 1.1.2. After the update and a restart Home Assistant re-checks the statistics and the repair should clear on its own. If it stays, dismiss it rather than deleting the statistics.
And i've added a section to the readme to clarify why there is a second min Soc.
Please let me know if you notice anything else.

...

Two minimum SoC values

The inverter has two minimum-SoC settings, read by two different regulators, and the integration shows both:

Entity	Register	Who applies it
Modbus storage reserve	model 124 MinRsvPct	The SunSpec storage control, only while a Modbus storage mode other than Auto is active (StorCtl_Mod not 0). In Auto the inverter ignores it.
SoC Minimum (Web API)	BAT_M0_SOC_MIN	The inverter's own battery management, the value its web UI shows, whenever Web API SoC mode is manual. In Auto this is the only minimum that counts.

Synchronisation goes one way: writing Modbus storage reserve also writes SoC Minimum (Web API) while the SoC mode is manual, because a web value under an automatic window would be ignored by the inverter. A change of the web minimum, in Home Assistant or in the inverter's UI, is not written into the Modbus register: that register only means something under an active Modbus mode, and the integration does not write registers whose effect depends on a mode the user did not choose.

In practice: if you only use the inverter's own battery management (storage mode Auto), set Web API SoC mode to manual and use SoC Minimum (Web API) and SoC Maximum; leave the Modbus reserve alone. If you use the Modbus storage modes, set Modbus storage reserve; it is mirrored to the web window while that is manual.
...

[mike4001]

Thank you for the fixes.

ad 1) is fixed for me
ad 2) is fixed. Even the entities which get activated and deactivated after a mode change now react instantly.
ad 3) OK I understand now how they behave.
ad 4) Thanks for changing this. I just find that in the case of SoC you normally write a round number such as 80 / 90 / 100 instead of moving around a slider and land on 83 ;-) So the input field is just better suited for this.

So sorry to say but I don't have anything more to add. Everything works in my short period of testing :-)

[mike4001]

OK, some logs popped up. Just wanted to let you know if this is something to fix or just to ignore

1. Warning Message:
   Logger: custom_components.fronius_modbus.coordinator
   Quelle: custom_components/fronius_modbus/coordinator.py:229
   Failed to read meter_200: holding block read at address 40069 (count 55) returned Modbus exception code 11

2. Error Message:
   Logger: homeassistant.components.fronius
   Quelle: helpers/update_coordinator.py:512
   Error fetching fronius_modbus_inverter_1_192.168.178.152 data: An error occurred while attempting to fetch data: could not connect to 192.168.178.152:502
   Error fetching fronius_modbus_inverter_1_192.168.178.152 data: An error occurred while attempting to fetch data: read_holding_registers(40253, 104): Response timeout after 10 seconds for transaction with ID 0x1cad

3. Warning Message:
   Logger: tmodbus.transport.async_tcp
   Quelle: runner.py:280
   Received unexpected response with Transaction ID: 7340. Discarding bytes: 1C AC 00 00 00 63 01 03 60 00 67 00 32 41 9C 15 E3 15 DB 15 DF FF FC 10 20 10 2A 10 1F 09 51 09 4E 09 53 FF FF 0F B1 FF FF 13 86 FF FE 0F A1 FF FF 85 DF FF FD 03 E8 FF FF 56 5B 13 9C FF FE FF FF 80 00 FF FF 80 00 11 48 FF FF 01 B3 80 00 80 00 80 00 FF FF 00 04 00 04 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 04
   Received unexpected response with Transaction ID: 7341. Discarding bytes: 1C AD 00 00 00 D3 01 03 D0 00 A0 00 6C FF FB FF FE FF FE FF FE FF FF FF FF 00 05 FF FF 00 01 4D 50 50 54 20 31 00 00 00 00 00 00 00 00 00 00 2D 18 99 65 11 B5 18 A5 76 9D 32 44 1C EF 80 00 FF FF FF FF FF FF 00 02 4D 50 50 54 20 32 00 00 00 00 00 00 00 00 00 00 2B 4A 9C A7 11 5C 22 DF C4 41 32 44 1C EF 80 00 FF FF FF FF FF FF 00 03 4D 50 50 54 20 33 00 00 00 00 00 00 00 00 00 00 13 C7 96 2F 07 9B 1F 47 A7 94 32 44 1C EF 80 00 FF FF FF FF FF FF 00 04 53 74 43 68 61 20 34 00 00 00 00 00 00 00 00 00 00 00 D0 5F 00 00 18 C1 07 A1 32 44 1C EF 80 00 FF FF FF FF FF FF 00 05 53 74 44 69 73 43 68 61 20 35 00 00 00 00 00 00 F2 C5 D0 5F 82 21 17 33 84 10
   Received unexpected response with Transaction ID: 7342. Discarding bytes: 1C AE 00 00 00 63 01 03 60 00 67 00 32 41 9C 15 E3 15 DB 15 DF FF FC 10 20 10 2A 10 1F 09 51 09 4E 09 53 FF FF 0F B1 FF FF 13 86 FF FE 0F A1 FF FF 85 DF FF FD 03 E8 FF FF 56 5B 13 9C FF FE FF FF 80 00 FF FF 80 00 11 48 FF FF 01 B3 80 00 80 00 80 00 FF FF 00 04 00 04 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 04

[Varitras]

You can ignore all 3.

1. The meter did not answer the inverter once. Keep an eye on it; if it happens very frequently, there might be an issue with the connection between the inverter and the meter.
2. and 3. is from the Fronius Core Integration. The Inverter failed to answer in time twice and 3. was the late reply from 2.

[mike4001]

1.2.0b4 still working great. Just some small feedback.

1. Maybe you can round the fan percentages to 1-2 decimals? I assume there is just some weird conversion happening.

2. Our inverter is throttled to a hard limit of 400 Watts export (We are actually not allowed to export a single Watt to the grid but our solar guy put in a limit of 400 Watts :-))

Yet the integration says "Throttle reason: no throttling"

This value did not change all day

[Varitras]

Sure thing :)
Fans (and other long numbers) are fixed in b5.
At the moment only the operating state, active power control and the AC limit are shown under throttle reason.

Could you check these sensors while the limit is active and take a screenshot of their history?

What	Device	1.2.0b4	1.2.0b5 and later
Production limit (W)	Inverter	Aktuelle Produktionsgrenze	Aktuelle Erzeugungs-Leistungsgrenze
Production limit reached	Inverter	Leistungsgrenze erreicht	Erzeugungs-Leistungsgrenze erreicht
Grid power	Smart Meter	Leistung	Wirkleistung
PV power	Inverter	PV-Leistung	PV-Leistung
AC power	Inverter	AC-Leistung	AC-Wirkleistung

And the output from the inverter API with active limit (Please remove the IDs and Serial Numbers)

http://IP-Inverter/api/components/inverter/readable

Could you please create an issue next time? That way, I can keep better track of things. Thanks :)
Issue: #26

[callifo]

Hi @Varitras , looks like a lot of work has gone into the re-write.

I only forked redpomodoro because he abandoned it and there were a bunch of people doing great fixes and updates all in isolation. I'm not a developer so the bulk of the effort has come from other contributors. As to avoid what happened with redpomodoro, you have longer term plans to maintain this version or get co-contributors to assist supporting?

From a feature parity perspective, is that close to 1:1 now?

It seems like getting everyone on the same page would be in the best interest moving forward, so I would be happy to attempt to re-direct users across to this fork going forward.

[Varitras]

Hi @callifo
First of all, thank you for your work on your Fork :)
We could also do it this way: you could take over my code, and we'd work in your Repo. Would that be an option for you?
One possible move would be:

• The code on your main becomes my current code. Files that only exist in your version (hub.py, base.py, extmodbusclient.py, your load tests) leave the current state.
• Your whole history stays: every commit of you and all contributors remains in main's history, mine is added alongside. Both lines meet in one merge commit.
• Your tags and releases (0.3.x) stay and can still be installed via HACS, which matters for everyone on Home Assistant older than 2026.9.
• The repository itself (URL, stars, issues, discussions, releases, settings) stays yours.
• If you don't like the result, a revert of the merge commit brings the old state back.

Before the move (in my fork)

• I close the remaining gaps:
  • Migrate the unique ids of ac_mod_temperature, dc_mod_temperature and batt_mod_temperature (from 0.3.3) to my module_temperature_1/3/4, so entity ids and history are kept.
  • We decide together on the load calculation: 0.3.4 reports a signed net demand (negative with a balcony inverter behind the meter), my version clamps at 0.
• I extend the migration tests to cover updates from 0.3.4.
• I merge your main into my fork with the "ours" strategy. Your history is then part of mine and the pull request has no conflicts. Nothing of yours is lost: every change since 0.3.1 is either already in my version or ported in the step above.
• I take over your brand icon and add a short "not affiliated with Fronius" note to the README.

The move

• You add me as a collaborator with the Maintain role.
• Repository settings (on your side): allow merge commits and disable squash merging. CI runs on every pull request; a red check is information, not a block. We decide case by case.
• One pull request from my main to yours. You merge it with "Create a merge commit": no squash and no rebase, so the full history of both repositories stays.
• In the same pull request:
  • manifest.json: codeowners both of us, documentation and issue_tracker pointing to your repository.
  • README links and badges updated.
  • Version above 0.3.4 (continuing at 1.4.x).
  • Tag style agreed (with or without a leading v).
• CI: my workflows (tests, hassfest, HACS validation) move along and run on every pull request; your current tests target the old code base. My own local routine (a pre-push check, a failing test before a fix) is just how I work. Nobody else has to follow it.
• Wiki: you enable the wiki and create a first page; I then push my wiki there with its history.

Release to existing users

• First a beta (pre-release) from your repository, so volunteers can test the migration from 0.3.x before everyone gets it.
• Users on Home Assistant older than 2026.9 are not offered the update by HACS (minimum version in hacs.json) and stay on 0.3.x.
• Then a stable release; the README states the Home Assistant minimum and the entities whose display names changed.

After the move

• I archive my fork with a README pointing to your repository. Users of my fork switch the custom repository in HACS; the domain is the same, so entries and history are kept.
• How we work together in the shared repository is still open. My aim: easy for contributors. Pull requests with CI, and a test with a fix where it makes sense, but no hurdles that keep people from contributing.

Entities that change from 0.3.4 to my version (entity ids and history stay)

Display name changes

Entity (key)	English	German
soc_minimum (number + sensor)	SoC Minimum → Modbus storage reserve	Minimaler SoC → Modbus-Speicherreserve
api_battery_mode (select)	Battery API mode → Self-consumption optimisation	Batterie-API-Modus → Eigenverbrauchs-Optimierung
events2 (sensor)	Events → Event severity	Ereignisse → Ereignisstufe
inverter_temperature (sensor)	Temperature → Internal temperature	Temperatur → Innentemperatur
max_charge (sensor)	Max charging power → Charge/discharge reference power	Lade-Referenzwert → Lade-/Entlade-Referenzleistung
ac_limit_enable (select)	unchanged	AC-Begrenzung aktivieren → AC-Leistungsbegrenzung aktivieren
acpower, power, wpha/wphb/wphc (sensor)	unchanged	Leistung → Wirkleistung (also AC- and L1–L3)
exported / imported (sensor)	unchanged	Exportiert → Eingespeist / Importiert → Bezogen
export_soft_limit (number + sensor)	unchanged	had no German text → Weiche Einspeisebegrenzung

Not migrated yet (I fix this before the move)

• ac_mod_temperature, dc_mod_temperature, batt_mod_temperature (added in 0.3.3) → my module_temperature_1/3/4 ("AC module 1 temperature", "DC module temperature (3)", "DC or battery module temperature").

State values

• Select options and enum sensor states are keys now: Auto → auto, Charge from Grid → charge_from_grid, On grid operating → on_grid_operating, Enabled/Disabled → enabled/disabled. Automations and templates comparing against the old texts need updating.

New entities (additions only)

• Component sensors from the web interface: module temperatures, fans, per-phase AC power and voltages, production limit, grid validity, battery state of health and limits, and more.
• Throttle reason, Web API SoC mode, SoC Minimum (Web API), inverter and service event entities.

[callifo]

This all makes sense to me, I will start with adding you as the maintainer.

Edit: Invite sent, allow merge commits and disable squash merging done, wiki enabled.

[Varitras]

One more thing I noticed while checking the migration: 0.3.4-rc2 ("fix capitals in translations") lowercased the data keys, and with them the unique ids of 28 sensor keys (inverter, meter and storage, e.g. AphA → apha, WHRtg → whrtg) and of the Inverter connection select. There is no migration for that, so anyone updating to rc2 gets new entities with new entity ids (often with "_2"), while the old ones stay behind orphaned with their history.

Released as 0.3.4 like this, it would hit all your users. If we move to my code, that is already handled: my migration takes over both spellings, and where rc2 left the old entity beside the new one, the old one with its history is kept. If 0.3.4 comes out before that, I would keep the old keys (or add a unique id migration) before releasing.

[callifo]

One more thing I noticed while checking the migration: 0.3.4-rc2 ("fix capitals in translations") lowercased the data keys, and with them the unique ids of 28 sensor keys (inverter, meter and storage, e.g. AphA → apha, WHRtg → whrtg) and of the Inverter connection select. There is no migration for that, so anyone updating to rc2 gets new entities with new entity ids (often with "_2"), while the old ones stay behind orphaned with their history.

Released as 0.3.4 like this, it would hit all your users. If we move to my code, that is already handled: my migration takes over both spellings, and where rc2 left the old entity beside the new one, the old one with its history is kept. If 0.3.4 comes out before that, I would keep the old keys (or add a unique id migration) before releasing.

Yeah I did worry about that, but I'm not competent enough to work out how to fix 😄 I did test it on my own Gen24, and I think some of mine did get new entities but I wasnt sure if that was part of the original entity naming (some of mine had the inverter size in the entity name, some didnt). I havent pushed it to release yet for that reason, hoping some others might provide feedback.

Are you able to point how I might properly migrate these entities for existing users?

[Varitras]

Thanks für the Invite :)

On the rc2 unique ids: you don't need to fix them in 0.3.x. My suggestion is to not release 0.3.4 as stable and go straight to the move. My code migrates both spellings: users on 0.3.3 keep their entity ids and full history. Users who installed rc2 keep their original entities with all history up to the rc2 update; what rc2 recorded under the new lowercase duplicates since then is not merged back, and energy totals catch up in one step at the update. Since rc2 was a pre-release, that should only affect a few testers.

My plan for the next steps:

• I prepare the pull request to your main as described (merge commit, full history of both).
• The first release from your repository is a pre-release v1.4.0b2 (my fork already had a 1.4.0b1), so people can test the migration from 0.3.x before it goes stable.
• After that I archive my fork and point it to your repository.

[Varitras]

PR ist Open and ready to merge.

[mike4001]

Great to here you working together :-)

One thought from my side:

HACS (soon to be the HA marketplace) still uses the repository from redpomodoro => Is it possible to let them exchange this with @callifo ´s repository? (Found it: https://hacs.dev/docs/publish/remove/ )

There are still opening new issues in the issue section of redpomodoro so I think people are not aware that this has been abandoned.

[callifo]

It should be possible, we can modify the existing list and replace it, might need some OK from the maintainer though.

[Varitras]

https://github.com/orgs/home-assistant/discussions/5394

Do not uninstall the old repository. The Marketplace removes the integration’s configuration with it, and the update then has nothing to carry over. Instead, take a backup, replace the folder config/custom_components/fronius_modbus with the one from this release by hand, and restart. The Marketplace has no way yet to switch repositories, so it will not offer updates for this one (discussion). If you still run HACS, removing the repository there keeps the entry.

This only affects people who switch the repo.

[mike4001]

Hi, thanks for the heads up, but can you explain this a little bit more? (I have already updated to Home Assistant 2026.11)

So I want to switch back from Varitras/fronius_modbus/ to the latest release from callifo/fronius_modbus/ as this is the way forward

What does it mean the "the configuration gets deleted" ?

Are entities and history kept and does this only mean I have to type in the inverters IP, password, ... again?

[Varitras]

The Marketplace only uninstalls an integration together with its setup, so removing this repository also deletes the entry, its devices and its entities, including names, areas and other settings. When you set it up again, Home Assistant creates new entities, and their entity ids can differ from the old ones. Your history stays in the database, but it is stored under the old entity ids, so any entity with a new id starts empty and dashboards and automations using the old id stop working. The Marketplace has no way to switch repositories yet.

I did it this way:

Moving from this fork to callifo/fronius_modbus (Home Assistant 2026.11 or newer)

These steps edit an internal Marketplace file. They are unsupported and may stop working with a future Home Assistant. Take a backup first. Do not edit the file while Home Assistant is running: it writes its own copy back when it stops.

Prepare SSH. Home Assistant has to be stopped for this, so the web terminal will not do; you need an SSH client such as PuTTY or the Windows terminal. There is no default password.

1. Install the app Terminal & SSH.
2. In its options, set Password or Authorized Keys, and add jq under Packages.
3. Under Network, enter a port, for example 22, and restart the app.
4. Connect as user root: ssh root@<home-assistant-address>

Switch the repository.

1. Add callifo/fronius_modbus to the Marketplace by its URL. Do not install it.
2. Copy custom_components/fronius_modbus from 1.4.0b2 to config/custom_components/fronius_modbus. The Samba app is the easiest way.
3. Stop Home Assistant: ha core stop
4. Change the owner:

cd /config/.storage

jq 'if (.data["1358328449"].installed and .data["1091499680"]) then (.data["1358328449"] |= del(.installed, .installed_commit, .version_installed) | .data["1091499680"] += {"installed": true, "version_installed": "1.4.0b2", "installed_commit": "8fa8c55"}) else error("fork not installed, or callifo not added") end' marketplace.repositories > marketplace.new && mv marketplace.new marketplace.repositories

The command changes only two entries in the Marketplace's list of repositories. It marks this fork (1358328449, its GitHub id) as not installed and callifo/fronius_modbus (1091499680) as installed at version 1.4.0b2. It writes the result to a new file and replaces the original only if that worked. If it stops with an error, nothing has changed: start Home Assistant again and check step 1.

5. Start Home Assistant: ha core start

To get later betas, switch on Show beta versions for callifo/fronius_modbus in the Marketplace.

Afterwards you can remove the port again, so SSH is closed.

[mike4001]

Thank you for the detailed explaination. I already had SSH setup but frankly I did not want to meddle with these files ...

So I made a backup of HA and just went for a normal delete & install

1. Uninstalled your orginal fork, deleted everything
2. Installed callifo´s fork (sadly I had to install 0.3.3 first)
3. Made the update to 1.4.0b2

But I have to say it was not that bad

1. Mostly history of the temperature sensors, fan sensors and some other small stuff was gone
2. The smartmeter retained all data
3. All MPPT data is still there, AC data (beside active power) is still there
4. All battery voltages, loading, unloading, ... data still there

So of course this is not clean by any means but basically => no harm done :-)

[Varitras]

Sounds good.
See you over there :)

[Varitras]

I completely forgot about the integration: https://github.com/mayerwin/HA-Merge-Sensor-History
It lets you transfer the history to the new entities pretty easily.