Updated without any issues. Seems to work just fine.
1 Like
Thank you for the fast feedback!
I found a problem myself during the entry creation for users who do not have advanced mode enabled.
I made a small fix and created v0.8.2 which solves this issue.
Edit: Found one more issue, causing sessions to the backend not closed while creating a new config entry. Also fixed this one and created v0.8.3
Hello all,
After the update to FEMS 2025.5, I noticed critcal problems how the backend reacts to user entity updates. Updating component configs via ha_openems on a FEMS system with version 2025.5 can cause the deactivation of FEMS apps. I observed this personally with the EV charging control app.
Details and measures to re-enable the component again are describe here:
https://github.com/Lamarqe/ha_openems/issues/18
I hope that Fenecon will fix this problem soon.
In parallel I will implement a solution in ha_openems, allowing it to send group component updates (Same as the regular FEMS UI does). However, the solution will require extra configurations to define which properties must be updated in a group. Due to limited test coverage of my personal system, these extra configurations will remain incomplete. So it will be really important that Fenecon resolves the problem.
Update:
I implemented the group update feature with v0.8.5. Furthermore I fixed a bug which caused component properties to be sent with an uppercase first char (should be lowercase). With that, differences between ha_openems and the regular Fenecon UI are removed and the problem is resolved.
As the impact of this problem was pretty large with FEMS 2025.5 and there were no additional issues reported with earlier v0.8 versions, I released v0.8.5 for everybody.
I have uploaded a pre-release of v1.0.0 earlier today.
This version introduces the update capability: It is able to detect pending FEMS updates, trigger the installation and monitor its progress (same as what is available via the regular UI).
The update notification and installation trigger has been tested by me against my personal FEMS system. The progress indicator has been tested only against mock data which I extracted from my personal system.
So same as for previous releases: I am looking for testers who have not yet updated to the most recent FEMS version, test it, and afterwards share feedback here. If it works as intended, I will make v1.0.0 available for everybody.
2 Likes
Just installed, nothing exploded 
I did not make any configuration changes yet, and my FEMS is up to date. So, I have to wait a bit to see the new logic.
But monitoring looks just fine.
Hi,
found something that changed with 1.0.0
The charge mode and Priority for the wallbox is not displayed anymore.
You can select something, but itâs not written back (FEMS config does not change)
and next time you open it, the display is empty again.
Interesting. The same entities work for me (I use the decluttering examples, but that should not make any difference). 
Can you please try two things:
- Clear your browser/app cache (shift+page reload should be sufficient, too), then retry.
- If this does not fix it: Please enable debug logging and check if a
updateComponentConfigmessage gets sent to the backend when you change the value in the UI. If yes, please post the debug message here.
How does the saying go? Every boot is good.
After we left with the car (therefore unplugging it from the wallbox) and returning home (plug it in again), everything works like a charm
Some hung process somewhere, âŚwho knows.
Thanks again for this great integration. Really cool.
Hey.
FYI:
I plan to release a final version of the add-on, which will include the retirement announcement, once the HA-OpenEMS integration reaches its public 1.0 release.
2 Likes
Update went fine
Progress bar went thru two times. I guess the first time was download. The second time the update itself??
@Skeletitor: Thank you passing the torch and your support! 
Super grateful to see this taking place. Thank you for getting us to the point. Your add-on was a great inspiration when I got started 6 months ago.
After receiving positive test feedback, I added the âupdate release details linkâ with v1.0.1 (which I had already ninja-edited into the screenshot above ) and published the version for everybody.
That means we passed the beta phase. From now on, I expect less development activity taking place.
If there are no critical bugs to be fixed, I will publish releases maximally once per month, aligned with the home assistant releases.
Talking about next releases: I currently I do not intend to extend features. Possible ideas are:
- Buttons to manually check for updates and restart the backend
- Support of updating non-property channels for people who purchased the âFEMS App REST/JSON Write Accessâ
However, currently I donât intend to implement these in the near future.
3 Likes
Yep, for me it also worked multiple times by nowđ
And also worked again 
Great job mate!
Edit: Quick PR since the documentation URL didnât work anymore: Update manifest.json by TheSerapher ¡ Pull Request #20 ¡ Lamarqe/ha_openems ¡ GitHub
Edit 2: Maybe it makes sense to also use the supplied âissue_trackerâ option to link to the Github issues: Integrations - HACS
One tip for people who use the meter0 Device: Home Assistant can now automatically convert the prefix of units, so you can now change the meter0/Voltage entities from mV to Volts:
This is excellent! I will try that!
Was hoping that this is also possible for other units like mHz but there is no option there (yet).
Edit: mA to A works after all, no idea how I overlooked thatâŚ
I also didnât notice until now. I guess it was probably added in a recent update.
And I also noticed that mHz cannot be converted in this way, probably the unit is too uncommonâŚ
It is also not in the const.py: core/homeassistant/const.py at 3c91c78383973f77dc8f4968491ce2bf046415aa ¡ home-assistant/core ¡ GitHub