We are currently experiencing some problems with UI widgets that cannot parse parameters properly.
After some digging it turns out, that OpenEMS has a different handling of component configurations, depending on whether they initially come via the Felix Console or the OpenEMS UI.
Felix - (Create) a new component configuration via Felix may contain Integer and Boolean Values like in this example config output file:
imbalanceHoldTime=I"30"
verbose=B"false"
Creating/modifying such a component via OpenEMS UI leads to the following output: OpenEMS UI - (Create)
imbalanceHoldTime="30"
verbose="false"
Note the missing “Typeanchor” I and B above.
OpenEMS UI - (Modify)
imbalanceHoldTime="30"
verbose=B"false"
The different handling of the configuration generates errors in some OpenEMS UI widgets. Because e.g. in Javascript the parameter “verbose” is handled as string “false” and not as boolean ‘false’.
Digging further, leads us to JsonUtils:getAsBestType. Fixing this, would fix the OpenEMS UI (Modify). But this method is probably not responsible for OpenEMS UI (Create). We are still evaluating this.
Just want to take the opportunity to inform you about this behavior.
This is neither easy to find nor easy to test. But it may have a huge impact on customers experience.
@c.lehne Thanks for reporting. I just had a similar problem today with a value being updated via OpenEMS UI, which lead to an Integer value without "Typeanchor” I. Afterwards the Component could anymore read the Config properly during @Activate.
There have been updates to Apache Bundles recently. Could these have caused the issues? I never found the missing Typeanchor to be a problem before.
I am still not sure, where it comes from. We are still using org.apache.felix:org.apache.felix.scr version 2.2.6. So I don’t think that the library has to do with it. I checked all our library updates of the last 3 months but can’t find an obvious candidate.
We did several checks and it looks like OpenEMS edge and OpenEMS backend can handle both versions of boolean true, so it really seems to be now issue (same for Integer/Numbers).
So in the end we changed the UI widget to something like that
And now it works, no matter if we use a felix configuration or a configuration via OpenEMS UI.
I did not feel very comfortable with that. But changing JSON Handling within OpenEMS Edge looks like it has a huge impact on a large number of different modules. And I did not feel very comfortable with that too.
@c.lehne: Not sure if it helps to solve the issue, but we generally (nowadays) avoid the EdgeConfig object in the UI if we need a configuration property. Instead we subscribe to the _Property*-Channels.
I’ve faced similar issue with openHAB and its config handling which rely on the same components.
In your case issue might indeed come from other layer, but in case of openHAB faulty component was Felix Fileinstall which did not handle properly so called “typed” properties. A little explanation - configs which are saved with imbalanceHoldTime=I"30" format are typed, while files saved without I, as a imbalanceHoldTime="30" are treated as untyped.
Issue is that once fileinstall miss-detect configuration kind config pushed into configuration admin might be different depending on mutation conducted through UI. This comes from fact that saved configurations could be also saved in untyped form. It could be also that they are saved properly, but wrongly interpreted. I’ve found that with array values. Reason for this misalignment is - typed properties utility is shaded across several Felix components, as far I remember including Config Admin. It leads to situation where proper handling in CM results in improper handling in Fileinstall. I’ve summarized a technical side of it in a blog post few weeks ago: » Felix Config Admin with Fileinstall and array values Middleware Warez