I just updated to v.0.6.0. Everything is duplicated. Is this intended?
E.g. the battery:
Not expected, but I have an idea, why: I had to change the identifiers of devices.
Upon restart, devices get created with new ids and entities are added as child elements. Wirh that, entities get placed below the device that uses the new id. The previous device entries remain without any entities, but are not cleaned up,
Is this what you see? If so, HA should allow you to manually delete device entries without entities and you can do the cleanup manually.
I am seeing the same issue but as far as I can tell, there is no way to delete a device that still has entities attached to it. As seen in the previous post, a lot of entities stuck to the old devices/services as disabled entities and I donât see a way to clean them up.
Had a similar issue with another integration where I wasnât able to get rid of old devices until I finally went ahead and delete entities of that integration that were still attached to it.
At least all my disabled entities were still enabled when I upgraded. Getting rid of those weird duplicates is now just a matter of good cleanup work, I hope there is a way to do this 
Here a sample for the old battery0 service. It shows disabled entities, enabling them does not change anything.
And it looks like a cleanup is quite some messing with internal HA files too: Cannot delete entities - #6 by PeteRage
Havenât tried that since even though correct, it looks a lot like a messy way to clean this up. Maybe if there is a way to easily detect the unused entities and then remove them it would be nice, but as it is with duplicates present itâs hard to tell what to remove and not break anything.
Edit: This looks like our issue: Remove leftover-devices and -entities from integration that is uninstalled - #5 by DarrenHill
Edit: I took a simple device/service (ctrlApiModbusTcp0) which only had one entity in it (Enabled) and tested this, it worked. I went into the integration, select the duplicate device, edited the entity and added a deleteme label to it, same for the device/service. Stopped home assistant with ha core stop and edited core.entity_registry, removed the line for the enabled entity with deleteme label, proceeded to do the same with core.device_registry and ctrlApiModbusTcp0 with deleteme label.
Device and entity are now gone. Looks like cleanup has to happen manually via core registry files, which will be quite a pain to do but something I donât have to do right away. Itâs cosmetically at this point since everything else seems to work just fine.
Please dont mess around with deleting files.
I had a look and was able to reproduce the problem. I think it has to do with disabled entities which cause a problem.
Looks like HA is not able to detect that disabled entities, which got re-added below a new parent (or no longer added). Instead, it just keeps these entities.
The easiest solution which I see: Remove the entire config entry completely and re-add it again.
This will still keep historic data. So your statistics will not be negatively impacted.
But: What gets lost, is your personal config of enabled and disabled entities. So you will have re-enable entities which you had enabled manually before and disabled default ones which you donât want/need.
This will clean up the situation.
I currently have no idea how I could provide a new version which would resolve this situation without re-creating the full config entry.
Root cause explanation: The problem is caused by a device identifier change which v0.6.0 brings. However, this is a bugfix. Previously the device alias was used, which is empty for multiple devices, and with that not unique. Now I use the regular device name. This problem became visible only in v0.6.0, which allows to create entities for potentially every device, uncovering the previous mistake
As I got aware during this discussion of the importance of the correct device identifiers I reviewed the identifiers once more and noticed that the device identifiers (for being future-proof) require one more extension.
This is why I have uploaded v0.6.1 in this minute, providing this additional correction.
So, please update first to v0.6.1, and re-create the config entry only afterwards. Otherwise you will have to do it again when you upgrade from v0.6.0 to a higher version.
As I see via the docs, there are also ways to deal with such changes during a version update, but it means significant implementation effort. Sorry, everybody for taking this shortcut. But I thought I better do another correction with v0.6.1 right away.
I also explained the situation in the release notes of v0.6.1.
I will do my best to not mess around with IDs anymore in the future. 
1 Like
Why canât the config entries be migrated by the integration?
They could. It is technically doable. Thats what I also said above:
As I see via the docs, there are also ways to deal with such changes during a version update
But that kind of implementation would have had to be part of v0.6.0 already (in which it was not, as I did not forsee this problem).
So I cannot undo the problem anymore. And thats why I quickly added another correction in v0.6.1, to make sure that this manual interaction is not just fixing a mandatory problem which was already part of the very first version, but even a potential future problem for more complex openems installations (which we apparently dont cover yet here)
1 Like
Hey,
No worries, this is still beta and some things are simply not known beforehand
I think just removing the config and re-adding is a good enough approach for a beta version and I will do just that. Iâll just have to check what entries I have enabled (almost 200 by now) and mass re-enable them again (possible via entities page).
Thanks for your efforts, other than some beta pains I have had 0 issues with the integration since the reconnect was added. Multiple updates of FEMS went through without issues!
Edit: And a heads up, your unique identifiers have changed again, they now have an added sum_ to their names which caused the history to be lost, e.g. productionactivepower, consumptionactivepower, etc.
Works fine for me. I removed the whole integration and re-added it. Bit of work, but itâs a 0.x version.
Also my âmissingâ heat pump entities showed up. Perfect
I removed my rest calls already. And I will keep the mqtt based addon only for some time to not loose the statistics.
This is the best Fenecon-Integration by far !
1 Like
Can agree on that, I gladly take those 0.x pains when it results in a great implementation
Yes, true. I forgot to mention it.
Previously, _sum entities were placed directly within the root device. This was an exceptional handling. As part of the cleanup of all kind of hard-coded limitations and special treatments of entities and devices, this implementation was also removed. Starting with v0.6, the integration just transparently publishes structures as they are existing in the backend. In result, there is now a _sum device and all its channels below it.
There is one more feature of v0.6 which I did not explicitly mention before: The limitation above which I had announced with v0.5 is now resolved.
I have added an implementation which allows to configure calculations for number properties in number_properties.json. So starting with v0.6, _PropertyForceChargeMinPower shows and consumes total numbers which get converted to phase based values before showing/sending them back to the backend, same as it is also in the regular UI.
This setting will have to be monitored. Reason: The corresponding OpenEMS implementation is marked with a FixMe label. So the config might need adjustment with an upcoming release of FEMS/OpenEMS.
I have just installed the 0.6.1 right now and skipped the 0.6.0. I have noticed that all channles were disabled after the installation. Then i just reinstalled it and now it works well. What I noticed though, is that all entities that were in _sum were previously placed in the âroot deviceâ and now that device was just empty and the _sum Channels have their own âDeviceâ/Service. This also means that _sum was added in the middle of all these entity IDs wich broke my dashboards. But this was easily fixed by renaming the âfems⌠_sumâ to just âfemsâŚâ like the main device was named and then allowing the entity IDs to be changed.
But it is very nice that I can now fully control my FEMS from Home Assistant.
EDIT: I think I started writing this before the current discussion and didnât notice it. But I think renaming the device is an ok solution.
I am all for it! Losing some statistics is a minor nuisance for me since most energy values are handled via HomeAssistant and powercalc energy meters (for more data points). It just meant editing things on my end (and realizing I should unify my sensors and templates into a file âŚ). Itâs a good change!
I noticed this in the commit messages. Wondering how this could handle systems that allow for disabling phases (KEBA has the hardware for it, OpenEMS has an open PR to implement it). Maybe it doesnât matter since itâs a min value for all phases and it would just display the combined power. But if disabling phases becomes a thing then min power could mean a single phase. Maybe thatâs related to the FixMe label 
Hoping for a great release for you and maybe even enough cleanup and work to make it into Home Assistant! It would be well deserved.
I wrote a small blog post of what one can do with this new integration: pimp your SG-Ready.
I contacted the electrician who installed it, and after some searching an a hint from Fenecon he could enable it. Not itâs visible in Fenecon web interface.
But the ctrlPrepareBatteryExtension0 does not show up, Not even after a reload.
Any ideas?
What do you need the battery extension for? It donât think that has anything to do with the reserve soc. You really shouldnât touch that as an end user.
Config changes in the backend are not yet handled properly by the integration.
Please try the following:
- rename <config_dir>/.storage/openems_config
- restart Home Assistant
- now try to reconfigure. The new component should show up in the popup which allows to add devices.
1 Like