While looking into integrating my future Fenecon Home 20 into HA I stumbled over this add-on and probably a related post (in German):
I assumed, hopefully correctly, that the issue with the add-on comes from that function missing so I left a comment to answer the question why this function would be needed in FEMS, not only OpenEMS.
yes it works.
The difference is: In the older versions I was able to determine the units of the various values from FEMS. This is not longer possible since 2023.06.X (or I don’t know how to do it). In the current version I basically guess them.
If you know the names of the components and channels, you will get your data as in the older versions of this add-on.
To get the names of the components and channels I use the windows or linux command:
curl -s http://x:[email protected]:80/rest/channel/.*/.* -o channel-names.txt
Than have a look to channel-names.txt
I am looking for a home management system and do a test of home assistant and openhab since yesterday.
I integrated my fenecon home 10 to HA with REST api with a copy and paste of the config shown in
Can you tell something about the advantages and disadvantages of your solution compared to the implementation with REST Api?
In my case, I use the values from Fenecon2MQTT for Live/Instant values in the UI (and excluded them from the recorder, as they are pushed every second and would totally overload my database (in my experience at least, but maybe this improved in newer Home Assistant versions, and if Home Assistant is running on a proper SSD))
Because of this, I use the Modbus registers for the values that are available and use REST for the rest, because not all channels are published on Modbus and set them to poll with differnet intervals for each request (for example SoC polling only every minute).
But another advantage of Fenecon2MQTT is that it is probably easier to setup for beginners (at least if you already have an MQTT-Broker).
One small “disadvatage” of Fencon2MQTT is that is technically based on a badly / un- documented API, and it might change as you cloud see in the previous posts, while the Modbus and REST-API are officially documented and also used by commecial customers, so it’s less likely the be changed in my opinon.
fast – data changes are displayed immediately. No time based trigger is uses in background like in Modbus or REST.
easy to install (especially if MQTT is already in use)
flexible – easily add new components/channels and define your overrides if necessary
Cons:
DB is more stressed. I’ve been using it since the first version. HA runs as a VM on Proxmox. 4xN100CPU+100GB NVME. The size is more or less static at 3.2 GB. → no problems at all
An unofficial WebSocket connection is used. Like the local web frontend. Changes must be reverse engineered.
Everyone has to weigh up the points for themselves.
Hi Skeltitor,
today my new home assistant green was delivered.
Could you give me a hint how to download and install your Add-On Fenecon2Mqtt ?
Until now, I have no account at GitHub.
Thank you
Just go in the settings, then Add-Ons, then Add-On Store, then click the three dots, then Repositorys and then add https://github.com/Skeletitor/ha_addon_fenecon2mqtt to the list. Then you can install the addon and set the configuration, for which you will also need an MQTT-Broker.
The installation was successful. The values are updated every second. Many thanks for the great add-on.
I then renamed the entities. The names of all but the last one in the list were then changed back after a short time.
Is there any way to set the entity names permanently?
Yes, I also have this issue. I think it’s due to the deletion of the discovery topics each time the addon is restarted. Maybe it’s possible to leave the discovery topics persistently? @Skeletitor
You can just rename them in the sensor overwrites though, if you really need to change the names.