v3.4.12 is extremely disruptive for complex setups

[frankkopp]

I really appreciate open-source development, and I’m involved in some projects myself. I’m grateful to everyone who invests personal time into it.

But this latest update is genuinely painful for people with complex setups.

Consequence: All sensors will be recreated.

Action Required: You may need to update your dashboards or automations if they rely on specific entity IDs, and historical data linkage might be reset for these entities.

With an integration into Home Assistant, there’s also a measure of responsibility. Having to redo dashboards and configuration is one thing — but losing data is not acceptable.

I’ve built a significant amount of YAML configuration on top of this integration: a complex grid charging manager, battery hold manager, surplus handling, and more, plus multiple dashboards. Updating all of that will take days. The possibility of losing long-term data would be even worse, as it would undermine everything I’ve collected to optimize my setup.

Could you share more detail on what will actually change?

• Since the integration already knows all entity IDs, is there an option for a clear “before-and-after” list?
• Is there a list of which entities will lose historical data?
• Is there an option to keep existing entity IDs unchanged while still running the current version of the integration?
• Will a simple find-and-replace work (old name .solis_s6_eh3p_* to the new name), or are there exceptions?

For context: I currently find 321 occurrences of .solis_s6_eh3p_ across *.yaml in my config folder, and 545 in lovelace.* files. I hope this helps illustrate the scale of the impact and why this update feels so disruptive.

Any guidance or mitigation options would be greatly appreciated.

EDIT: As I use a static IP (I always do for HA devices) there should be an option to stay on the old entity IDs

[frankkopp]

📊 Quantified Impact

Files Affected

Category	File Count	Reference Count
Package YAML files	15+	200+ references
Lovelace dashboards	4	300+ references
Core config files	2	15+ references
Documentation	3	50+ references

Solis Entities Currently Referenced (Pattern: solis_s6_eh3p_*)

Entity Type	Approx. Count	Critical for Automation
sensor.*	~70+	✅ Yes - core power/energy/SoC
number.*	~40+	✅ Yes - TOU slots, limits
time.*	~30+	✅ Yes - TOU charge/discharge slots
switch.*	~10+	⚠️ Moderate

[prier4ever]

I completely agree with this sentiment.
Open-source development thrives on collaboration and trust, but major changes like this one really emphasize how critical backward compatibility is — especially for long-term Home Assistant users who’ve fine-tuned their setups over years.

For many of us, stability and data continuity are core reasons for choosing open-source integrations in the first place. Historical data isn’t just “nice to have”; it provides valuable context for energy optimization, performance analysis, and automation tuning. Losing that undermines the entire history-driven approach.

Breaking all entity links without a migration path or mapping tool essentially resets months or even years of careful configuration work. Even a simple JSON or YAML “entity ID translation” export could make a huge difference.

If possible, please consider offering a migration utility, a compatibility mode, or at least clear documentation outlining the changed entity structure — that would preserve a lot of user goodwill.

[0rangutan]

I am in a similar position - entity names are used all over the place on multiple dashboards and I have nearly two years of historical data.
The 3.4.12 update broke all of these and so I have had to revert back.

[GermanCaruncho]

If I had a proprietary home automation software solution, I would use this example to justify the low reliability of open-source software. Now that I’m leaving the IT sector after almost 40 years, I simply want to share the only two reflections I used to give my teams:

• Think about who it is aimed at and the repercussions of any software change.
• NEVER shoot yourself in the foot.

I’m sorry to be harsh, but we also come from last week when we had changes that “duplicated” sensors. Disruptive changes are great, unless they end up killing the product...

[frankkopp]

I’m sorry to be harsh, but we also come from last week when we had changes that “duplicated” sensors. Disruptive changes are great, unless they end up killing the product...

I see your point, and I’m not against the change per se. It’s clearly a better approach to avoid the issues we’ve had—and I’ve also had to manually clean up several “*_2” duplicates.

That said, if a change of this magnitude is necessary, the impact on existing users also needs to be taken into account. Many of us have invested a lot of time building data collection, automations, and dashboards around this integration. These are effectively production systems for our homes; even if they’re not commercial, they represent a significant investment of personal effort. Having to rebuild everything is one thing—potentially losing long-term data continuity is another.

What I’d really like to see is either:

• an automated migration (to the extent Home Assistant allows), and/or
• a configuration option to preserve the existing entity IDs.

Ideally, there would be a phased path so users can migrate gradually instead of being forced into an all-at-once break when they click update.

[Pho3niX90]

I completely understand the frustration regarding the data loss. I was personally affected by this as well and lost years of my own historical data during the transition.

Unfortunately, HACS and GitHub don't always make breaking change warnings immediately visible during updates, though we did note this in the https://github.com/Pho3niX90/solis_modbus/releases/tag/v3.4.0

Why this changed now: A recent PR was merged into the project, and when I tested it on my own production system, it completely "nuked" my unique IDs. This failure made me realize that the current patchwork of ID generation methods was unsustainable. Additionally, since we are adding support for direct Serial connections (which do not have IP addresses), we needed a single, consistent standard that works for all connection types.

Why the data couldn't be migrated: Because this integration evolved organically, there was no single standard for how IDs were generated in the past (first by IP, then IP + Port, then IP + Port + Slave). With so many conflicting formats existing in the wild, writing a script to migrate everyone's data to the new format was effectively impossible.

The Solution: We are now strictly using the Inverter Serial Number for Unique IDs. This standardizes support for both IP and Serial users and ensures that your entities will never break again due to network changes or dynamic IPs.

1. I will also have a backup system to test PR's on, for scenarios like this. To create possible migration if something like this would to happen again
2. I am busy adding more and more test cases to also ensure something like this doesn't happen again.

I am open to any PR's that could create a migration for this specific release.

[Pho3niX90]

I will have a look during the next day or 2, if some of the old funtionality of the linking can be brought back, but I will need some volunteers (that have backups) that can test it. I have deleted the current release in the meantime.

[Pho3niX90]

@0rangutan @frankkopp @GermanCaruncho @prier4ever

Here is the code for testing: #309 or https://github.com/Pho3niX90/solis_modbus/releases/tag/v3.4.12 if you want the zip

I would suggest, do a full backup, before testing.

[charliegadget]

Well I was on 3.4.1 and when there was no info on the update to 3.4.12 I thought it would be Ok, but nope! initialisation failed to load. Rolling back.

[0rangutan]

Really appreciate your efforts to resolve this @Pho3niX90.

One possible lesson here - as HA doesn't provide the release notes for an update, the minor point numbering increase probably wasn't right.
You could quite reasonably have numbered this as 4.0.0, or at least 3.5.0 - that would likely have caused some of us to proactively look into why such a version change.

[Pho3niX90]

Really appreciate your efforts to resolve this @Pho3niX90.

Once possible lesson here - as HA doesn't provide the release notes for an update, the minor point numbering increase probably wasn't right.
You could quite reasonably have numbered this as 4.0.0, or at least 3.5.0 - that would likely have caused some of us to proactively look into why such a version change.

Fully agree, it was suppose to be released as v4, but the automated version bumping didn't do it's job this time around. Ironically, the next onr will be auto bumped to v4

[Pho3niX90]

Well I was on 3.4.1 and when there was no info on the update to 3.4.12 I thought it would be Ok, but nope! initialisation failed to load. Rolling back.

Could you try https://github.com/Pho3niX90/solis_modbus/releases/tag/v3.4.0

[charliegadget]

Well I was on 3.4.1 and when there was no info on the update to 3.4.12 I thought it would be Ok, but nope! initialisation failed to load. Rolling back.

Could you try https://github.com/Pho3niX90/solis_modbus/releases/tag/v3.4.0

I could, but I am already on 3.4.1? I have had to update the names on several entities. Whats the reason for going to 3.4.0?