Hi,
I guess that OpenEMS does not provide the ‘result’ item. I’m using that to get the version number… Maybee its related to the used (old) OpenEMS version. Do you have an option to update OpenEMS?
Hi @Skeletitor
I just stumbled over this thread and I’m quite interested.
I tried my best, but I can not get it to work.
Most likely my issue is the connection with Fenecon.
I do not have a local running FEMS, so I think I don’t have the required “guest” user.
Is there a way to use my online account for this configuration?
Following is the error message that I get:
[07:47:04] INFO: Service restart after closing
[09:47:05] INFO: Starting Fenecon2Mqtt
2024-05-14 09:47:06,378 - MqttClient - MainThread - INFO - Connect to MQTT broker
2024-05-14 09:47:06,401 - connect_callback-MqttClient - paho-mqtt-client-Fenecon2Hassio_mqttClient_0 - INFO - connected OK Returned code=Success
2024-05-14 09:47:07,400 - FeneconClient - MainThread - INFO - Init
2024-05-14 09:47:07,402 - FeneconClient - MainThread - INFO - Connect to Fenecons websocket
2024-05-14 09:47:11,275 - FeneconClient - MainThread - ERROR - Fenecon connection error: [Errno -5] Name has no usable address
2024-05-14 09:47:11,277 - FeneconClient - MainThread - ERROR - Wait 5 seconds. Shut down. Let Watchdog restart this add-on.
[07:47:16] INFO: Service restart after closing
[09:47:17] INFO: Starting Fenecon2Mqtt
2024-05-14 09:47:18,642 - MqttClient - MainThread - INFO - Connect to MQTT broker
2024-05-14 09:47:18,665 - connect_callback-MqttClient - paho-mqtt-client-Fenecon2Hassio_mqttClient_0 - INFO - connected OK Returned code=Success
2024-05-14 09:47:19,664 - FeneconClient - MainThread - INFO - Init
2024-05-14 09:47:19,666 - FeneconClient - MainThread - INFO - Connect to Fenecons websocket
2024-05-14 09:47:23,525 - FeneconClient - MainThread - ERROR - Fenecon connection error: [Errno -5] Name has no usable address
2024-05-14 09:47:23,526 - FeneconClient - MainThread - ERROR - Wait 5 seconds. Shut down. Let Watchdog restart this add-on.
Hi,
nope. It just works with local FEMS installations. It may work with OpenEMS but I didn’t test that out.
Cheers
I recently checked the latest FEMS Version. Looks like they added some new Modbus-Register.
MinCellVoltage, MaxCellVoltage, MinCellTemperature and MaxCellTemperature
Will it be enough to add it manually to the add-on config ?
Thanks!
Hi!
i stumbled upon this great add-on, but I fail to get the device and entities listed as an MQTT device. doesnt the add-on support auto discovery? or am I doing sth wrong?
in mqtt explorer I can see the values dropping in.
I had the same Problem.
See all in mqtt explorer but no entities.
Did you set the right Mqtt permissions? You need to add write permissions to topic homeassistant/sensor/fenecon/# to get autodiscovery to work. Like described in the docs
hi,
did that, still no luck. the device is not listed under MQTT. any advise?
Hi Skeletitor,
Auto Discovery is also not working for me, despite having the correct write permissions for homeassistant/sensor/fenecon/#.
I have a Fenecon Home 20, which came with FEMS version 2024.7.1 (now updated to 2024.7.2). Since FEMS 2024.7.1, getEdgeConfig no longer transmits the complete configuration. The list of available channels is no longer included.
See also the release notes at Release 2024.7.0 · OpenEMS/openems · GitHub or OnRequestHandler Error - OpenEMS Community
With my amateur understanding of your source code, you check in the configuration read from getEdgeConfig whether the fems_request_channels listed in the plugin configuration actually exist. Only then are they passed to publish_hassio_discovery.
Since the channels now need to be read with a different request, it does not find any channels in the EdgeConfig and does not perform Auto Discovery.
Additionally, I noticed that it could be due to a general difference between the Home 20 and the Home 10:
Not all of the standard fems_request_channels exist anymore, or they have been renamed. The following ones I found in my setup:
_sum/ConsumptionActiveEnergy
_sum/ConsumptionActivePower
_sum/ConsumptionActivePowerL1
_sum/ConsumptionActivePowerL2
_sum/ConsumptionActivePowerL3
_sum/ConsumptionMaxActivePower
_sum/EssActiveChargeEnergy
_sum/EssActiveDischargeEnergy
_sum/EssActivePower
_sum/EssActivePowerL1
_sum/EssActivePowerL2
_sum/EssActivePowerL3
_sum/EssCapacity
_sum/EssDcChargeEnergy
_sum/EssDcDischargeEnergy
_sum/EssSoc
_sum/GridActivePower
_sum/GridActivePowerL1
_sum/GridActivePowerL2
_sum/GridActivePowerL3
_sum/GridBuyActiveEnergy
_sum/GridMaxActivePower
_sum/GridMinActivePower
_sum/GridMode
_sum/GridSellActiveEnergy
_sum/ProductionAcActiveEnergy
_sum/ProductionAcActivePower
_sum/ProductionAcActivePowerL1
_sum/ProductionAcActivePowerL2
_sum/ProductionAcActivePowerL3
_sum/ProductionActiveEnergy
_sum/ProductionActivePower
_sum/ProductionDcActualPower
_sum/ProductionDcActiveEnergy
_sum/ProductionMaxActivePower
_sum/State
battery0/Soh
batteryInverter0/AirTemperature
batteryInverter0/ArmFmVersion
batteryInverter0/BmsPackTemperature
batteryInverter0/DspFmVersionMaster
batteryInverter0/DspFmVersionSlave
batteryInverter0/RadiatorTemperature
ess0/Capacity
ess0/DcDischargePower
Since there is no charger0/charger1 and publish_hassio_discovery.py refers to it, the get_entity_value_template function also doesn’t work anymore. But as I said, I am not sure if this is due to the new version or if it is specifically related to the Home 20.
1 Like
They reduced the size of Edgeconfig by dropping all available channels. They need to be requested now.
I’ll investigate there. But give me some time.
1 Like
It seems the new backend is not available in FEMS yet.
I’ll wait until the 2024.08 version and decide how to proceed. I really like to implement the new stuff instead of release a dirty quick win version
1 Like
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.
Hoping for a good solution here!
0.2.17
- Changed from using FEMS provided sensor data to (dirty) guessing sensor units and sensor classes as Fenecon changed their backend.
- Fixed a bug wich didn’t clean up Homeassistants MQTT autodiscovery topic
- fenecon-config.json is still writen. But it contains data of FEMS-components only
1 Like
Does this mean the homeassistant integration is working with FEMS 2024.8.1?
So the integration is just guessing the fems request channels?
Hi,
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
At the moment in worked with Version 2024.7.2
2 Likes
Hello Skeletitor,
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?
Regards
nam-AH
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.
Thx. I’ll add this as a workaround.
I used the REST API long time ago and totally forgot about it 
As Benniju already said:
Pros:
- 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.