OEM-Bundle: implement a OpenEMS OEM bundle #2428
Conversation
This approach should make it easier to handle proprietary distributions of OpenEMS Edge and Backend
|
@clehne: As discussed previously. Would this approach suite your requirements? |
There was a problem hiding this comment.
Like that. It is a really good starting point for an oem provider. I only have some "technical" change requests.
My thoughts went in a similar direction. Internally, we have a rudimentary prototype of an own oem provider, which I wanted to publish later. Luckily it is not far away from this PR. It provides us some more information:
-
a provider for APP Urls, because we add a
setWebsiteURL(..)to every App (see example here (this makes syncing a pain.) -
we removed AggregatedInflux:AllowedChannels and provide the list of averageChannels and cumulatedChannels via oemProvider.
-
Also we made kind of a whitelist for the influxDb, which is delivered by our oemProvider implementation. This helps us keep our productive database clean, because it forces us to take care of
componentIds.
Would be nice if we can get at least 1. and 2. into the Oem provider. But I would do this in further PRs.
What do you think about 3. a whitelist for influx db? It is probably not your usecase. But could it be useful to others.
io.openems.oem.openems/.settings/org.eclipse.core.resources.prefs
Outdated
Show resolved
Hide resolved
| // TODO ,def -> | ||
| // def.setAutoGenerateField(!OpenemsConstants.MANUFACTURER.equals("OpenEMS | ||
| // Association e.V.")) | ||
| ); |
There was a problem hiding this comment.
@michaelgrill I need your support here, how to solve this.
There was a problem hiding this comment.
As i already talked with you about this in general handling apps, @clehne may also have an opinion on this. We were discussing to move the apps maybe completely to the OEM specific bundle then everyone has their own "available" apps, but it would probably result in a lot of duplicated code when not sharing a simple app like "KEBA EVCS" or so.
For now you can just remove those lines 🙂
There was a problem hiding this comment.
Thanks Michael. As also Christians feedback was positive, I'll continue with this PR to have a first OEM bundle. From there we'll discuss individually how we extract the remaining OEM specific changes like AggregatedInflux, Apps, etc.
There was a problem hiding this comment.
As i already talked with you about this in general handling apps, @clehne may also have an opinion on this. We were discussing to move the apps maybe completely to the OEM specific bundle then everyone has their own "available" apps, but it would probably result in a lot of duplicated code when not sharing a simple app like "KEBA EVCS" or so.
For now you can just remove those lines 🙂
@michaelgrill Right now I do not have a final opinion on apps handling. I think also that we should finish this PR and delay the app handling to a new PR.
In general it would be good to
- have a common base for most of the apps.
- have a OEM specific link for each app url and probably for the app image.
- have the opportunity for own apps.
The keba EVCS app is a good example. We tried to use it but this leads to problems with our evcs cluster app for charge parks. Later we needed a lot of workarounds for e.g. alfen, compleo apps just because of the keba evcs app.
In the end we decided to put our own different keba app beside the official keba app.
I think this is a good compromise for now, as your and our company proceed with different speeds. But later we should find a way to integrate both sets of apps into one base.
# Conflicts: # io.openems.shared.influxdb/src/io/openems/shared/influxdb/proxy/FluxProxy.java
|
|
|
|
1 similar comment
|
|
|
|
This approach should make it easier to handle proprietary distributions of OpenEMS Edge and Backend