Component installed via Apache Felix File Install / manual install not in EdgeConfig

to replicate the following behavior I boiled the setup down to minimal example consisting out of edge ↔ backend ↔ ui as described in getting started guide.

Now, I install another component (e.g. this meter), which was NOT registered inside EdgeApp.bndrun when the edge was compiled. The installation is done via Apache Felix Web Console->Bundles->Install and configuration in the same web console. The meter is working but inside the edge the EdgeConfig->AcutalEdgeConfig->Builder->addComponent is NOT called. (Same applies if installed via Apache Felix File Install with an existing config in the config folder).
That’s why - afaik - the component is not forwarded to the backend via the web socket and not visible in the UI connected to the backend (and also not in an UI additionally connected to the edge)

As a workaround you can deinstall any other component which causes all components to be inserted to the EdgeConfig again (including the meter). But this does not work if the edge restarts and loads its modules via FileInstall from a folder.

Why this is a problem: We want to automatically install / update components as JAR into the edge via Felix File Install.

Does anybody have hints how to fix this or work around this in another way?

Hint: Might be related to Warn message "Component was missing!"

1 Like

Hi Philipp,

thanks for reporting this. We are using dynamic loading of Bundles in Backend, but have not done that yet in Edge.

I would have to dig into this…

Currently there is the EdgeConfigWorker (openems/ at develop · OpenEMS/openems · GitHub) which updates the EdgeConfig on ConfgurationEvents (openems/ at develop · OpenEMS/openems · GitHub).

I assume we have to find a system event that gets triggered when a new Bundle is installed and then handle it in the same way.


Hi Stefan,
thanks for your explanation, confirmation and hints.
Starting from there, I was looking into the ServiceListener which could deliver such a trigger. But at the moment development efforts are not feasible for us and we will live with the described workarounds.
Maybe we pick it up later again.