Yep, it would be very good to have a way to add scaling factors to some entities like you can do in Fenecon2mqtt since openEMS uses some really weird scaling and this uncommon units.
I don’t know how this could be implemented best for this integration though. In Fenecon2mqtt you could add a custom value template and override the unit.
mHz is MilliHertz.
The problem here is on Home Assistant. It simply does not support Millihertz yet.
Edit: For now, I will remove it from the frequency units. So it just gets recorded as a measurement without implicit conversion to other frequency units.
1 Like
Tried adding the new entities to the energy dashboard but Home Assistant doesn’t seem to be able to find them. Maybe there is a sensor info missing to make them proper energy sensors? I am guessing they need to be declared as Energy sensors for this to work 
Edit: Probably caused by the weird unit being used of Wh_Σ instead of Wh. I think this needs to be updated/overwritten so HomeAssistant can use it for the energy dashboard. This also means the sensors aren’t Energy classes either since it wouldn’t pick up on Wh_Σ. Home Assistant expects a very specific unit too, so we have to switch this to plain Wh.
Pick a sensor which measures grid consumption in either of cal, Gcal, GJ, GWh, J, kcal, kJ, kWh, Mcal, MJ, mWh, MWh, TWh, Wh.
Yes, good point. For now, I just ignored this sum “unit” without further thinking about it.
I have to somehow map it to just Wh. Noted down.
2 Likes
Expanded the issue, energy sensors also need state_class total_increasing set for them, otherwise some functions won’t work with them - see comment I left in the issue.
Created a PR on how I though it could work 
Running it on my HA right now and sensor work as expected again (after HA restart).
Thank you for the PR. I realized it a bit differently and asked for test feedback.
I also pushed v0.2 today. It properly reestablishes the connection after a loss.
Furthermore it stores the FEMS config within Home Assistant instead of always reading it from the device.
This will allow to start the integration when HA runs up, even though the FEMS system is not reachable.
Hi, since I updated to that version, i get the error
2025-02-28 12:12:48.684 WARNING (MainThread) [py.warnings] /config/custom_components/openems/init.py:40: RuntimeWarning: coroutine ‘OpenEMSBackend.read_config’ was never awaited
backend.read_config()
2025-02-28 12:12:48.684 INFO (MainThread) [homeassistant.components.sensor] Setting up openems.sensor
in my log when reloading the integration and all of the entities are unavailable.
Interestingly v0.1.0 is still displayed in the settings:
Looks like you didn’t actually release version 0.2? Can’t see it in the repo 
Scratch that, it did show up now. But same issue es @benniju, all sensors are not available. I actually only installed your change to the Wh sum detection which seems to have issues: Handle Wh_Σ explicitly · Lamarqe/ha_openems@16b1305 · GitHub
Reverting that and going back to my PR version made all sensor come back
Could this be caused by not specifically passing out the unit again when creating your sensor_types? Some units might be missing causing the subsequent assignment here to fail: ha_openems/custom_components/openems/sensor.py at 16b1305dafa9ce1076750aef3415f6ae57a77a30 · Lamarqe/ha_openems · GitHub
Otherwise your implementation for Wh_Σ is way better, complete newb with HA Integrations and Python so definitely fine tune your version and once it works I will install it.
Moved this in the issue itself, no sense to discuss this here
Sorry folks, I thought I had this well tested, but it turned out that my “database cleanup” did not cover the scenario you were running into. 
I have published v0.2.1 in this minute. Now it should work again.
@TheSerapher : v0.2.1 also contains the changes for the Wh_Σ. Let me know if it works. In contrast to your proposal, only entities using this unit will be created using SensorStateClass.TOTAL_INCREASING. It might be insufficient. (On the other hand creating all Wh entities like that will cause errors for entities which represent an energy measurement, eg remaining battery capacity. In this case, we will require corrections on entity level. 
I checked those entries that come with Wh out of the box and couldn’t find anything at quick glance that would benefit from total increasing so using it on the sums seems fine to me!
Yes, it works now! Units are Wh again, I will close the issue on GitHub.
Well done! I love your responsiveness on these issues and coming up with solutions. Even with smaller issues the integration works really well for me. With the next FEMS upgrade I will see if the reconnect works. Or if I need to restart
Thanks for the fix! I have noticed though that the version number displayed in Home Assistant is still 0.1.0 like shown in my screenshot, not a big deal though. But maybe it has something to do with the Updates only showing up in HACS and not in the normal Home Assistant Settings?
Thanks for the hint.
Looks like I also need to change manifest.json#L13
Next times, I will try to make sure to keep it aligned.
1 Like
Just saw them! Nice work, looks way better with logos
1 Like
Just wanted so say thank you for taking the time to implement a real integration for this. Up until now I had custom REST sensors set up to fetch data every 10 seconds, but the last days it started to be very unreliable and checking the logs in the FEMS web interface it appears that a recent firmware update might have introduced some kind of rate limiting (still, no idea why this triggers if I have <10 sensors which update every 10 seconds, but whatever).
Now this implementation with websockets is even better and updates very fast, not sure if that could become a problem with too many data points for HA to handle but so far it’s certainly nice to have.
Thanks again and keep up the good work!
1 Like
I had been running with fenecon2mqtt with the same update frequency without any large issues. Historic graphs were difficult on my Raspberry Pi 5 until I discovered ApexCharts for Home Assistant. Since then I have lots of graphs on dashboards which work just fine even with that many datapoints. And I enjoy the live updates way too much to throttle them 
I uploaded a new version last night which allows to change the Fenecon configuration from HomeAssistant. This first version supports only setting of boolean properties.
This is tested in my private setup currently with two properties:
- ctrlEvcs0/enabledCharging (enable wallbox charging)
- ctrlEmergencyCapacityReserve0/IsReserveSocEnabled (enable battery reserve).
Here a screen capture of the functionality. On the left the regular FEMS UI and on the right side home assistant. You can see the FEMS UI updating after toggeling the entity in home assistant:
Theoretically, there are ~20 more properties in my personal setup (most notable the “enabled” property of each component) which could now be controlled, but I consciously did not try these. I also would not recommend to change these values as this clearly exceeds intended user actions from the regular UI and only Fenecon could tell what it would mean to change these properties (brick warning 
).
In the next step, I will extend this capability to String (Enum based) and number properties.
2 Likes
Great, the IsReserveSocEnabled is working for me! I first tried the charge from grid, because that’s the first thing I saw and it didn’t work, which makes sense based on your post.
This is great! Being able to turn off my EVCS from HA was one one feature I’d wanted for a while. Will test this out!
Thanks a lot for your work on this, it works really well so far