Smooth transition?

[ManfredGroh]

Hey @callifo , thank you very much for this! It would be really super, if this integration is more agile!
One question to all, as I am not too experienced yet:
Is there a way for a smooth transition to this integration?
I am working since almost a year with the original one and I would be very happy if I could keep all the entities, at least the statistics entities (produced energy, energy to / from the battery, to the house, etc...)
What is the best way to do this?

BR
Manfred

[1aladdin1]

statistics should survive, if we keep the names of all entities

[robi26]

Would it be possible to somehow change the repository URL of the 'old' migration? That would be the easiest update path...

[callifo]

I'm not exactly sure, this fork incorporates unique names per hub so that it can support multiple inverter in one home assistant instance. That might be a problem?

I'm fixing some old things in the manifest file tonight.

[DAVIZINH0]

in my case the migration was smooth. the entities are the same.

But I changed manually some things in the redpomodoro version, for use multiple inverters. When i made this change, i lost all the entities and need to make changes in my automations.

maybe this is the problem. and i think not have easy solution :-(

[3dbruce]

I switched from redpomodoros version to this one yesterday evening without losing the energy statistics. I have a single Fronius Symo Gen 24 Inverter, a BYD battery and a TS 65-A3 smart meter and used the original modbus integration since April last year.
These are the steps that finally worked for me:

• Remove the HACS custom repository of https://github.com/redpomodoro/fronius_modbus and restart HA
• Remove the Fronius modbus integration entirely and accept the warning that all entities and data will be permanently deleted.
• Restart HA again
• Add the new HACS custom repository of https://github.com/callifo/fronius_modbus, download the repository and restart HA again
• Add the Fronius modbus integration again
• Now in my case the entities were recreated with their original names and the energy statistics as well as the configuration of the energy dashboard worked as before.

In my previous attempts the new entries always had a _2 suffix breaking things. The cost statistics however did not survive this migration and were set to zero afterwards. I hope to recreate them with some database magic, though.

If you try to replicate this please make sure to create a backup (or in my case a filesystem snapshot) so that you can easily rollback the changes in case of any problems. It took me 3 attempts until the sequence finally worked.

[3dbruce]

When you configure the grid connection in the energy dashboard, you can also define a price for Cost Tracking and a rate for Export Compensation. The respective costs are then recorded in internal entities, in my case sensor.fronius_smart_meter_ts_65a_3_primary_meter_1_imported_cost and sensor.fronius_smart_meter_ts_65a_3_primary_meter_1_exported_compensation
After the migration procedure described above, new cost entities were recreated with a _3 suffix but the original cost data still sat in the original entities without suffix. I did not find where HA internally stores the relation between the energy and the respective cost entities so what I did, was to move all data from the original cost entities to the new ones using some SQL commands.

[tepebox]

I was very busy the last months so I couldn't do that migration, yet. However, now I'm ready to try... @3dbruce Do you still know what you did to migrate the cost? Or at least give me some direction? Maybe AI can help me then to do the details ;-)

[tepebox]

Transition was a disaster... Lots of changes in the name... The meter was called "primary_meter" in the past, now it's "meter"... The battery names changed as well... Really not a pleasant experience and I lost a lot of history :-(

[3dbruce]

Well, the procedure I described above worked in January. When I tried to update to the latest version in August, I also encountered a lot of additional and unexpected entity name changes. What I did to preserve history was to write down a list of corresponding entity names and entity IDs before and after the upgrade and then manually updating the statistics tables to replace the old with the new entity ID:

UPDATE or REPLACE statistics SET metadata_id = (new id) WHERE metadata_id = (old id)
UPDATE or REPLACE statistics_short_term SET metadata_id = (new ID) WHERE metadata_id = (old id)

This way the history is transferred to the new IDs and kept intact for me.

Restoring the cost entities was more difficult this time, though: I asked Google Gemini to come up with an SQL query to reconstruct the cost entities from the actual energy values and this worked eventually. I don't want to copy the query here because I don't fully understand it (Welcome to the wonderful world of AI ;-).

So final and most important recommendation before you try any of this:

• Take a backup of the database and test that you can restore successfully to this backup.
• Before every SQL change, take another backup and test the result before doing the next change.
• In case of any problem restore the latest backup
  This takes time but ensures that you do not lose your history.

[friskens]

Transition was a disaster... Lots of changes in the name... The meter was called "primary_meter" in the past, now it's "meter"... The battery names changed as well... Really not a pleasant experience and I lost a lot of history :-(

If you haven't cleaned the database of the old values you can still do a back-marge to append the old to the new! If you run some sort of backup for HA then you can even do it if you have old saved versions of the database.

[friskens]

I've merged my two inverters into one "incoming solar PV" recorder entry, that will keep long term statistics, short term i also have individual MPPT:s those i merged with the old integrations equivilent ones.