OpenEMS / openems

OpenEMS - Open Source Energy Management System
GNU Affero General Public License v3.0
810 stars 400 forks source link

Issue: Identification of production-meter is buggy in UI - problem analysis #1908

Closed ichsteffen closed 8 months ago

ichsteffen commented 2 years ago
- [X] bug report (problem analysis)
- [ ] feature request

The identification of meter with production is currently buggy. As quick fix some factory ids are hardcoded in the UI.

See ui/src/app/shared/edge/edgeconfig.ts

    /**
     * Is the given Meter of type 'PRODUCTION'?
     *
     * @param component the Meter Component
     * @returns true for PRODUCTION
     */
    public isProducer(component: EdgeConfig.Component) {
        if (component.properties['type'] == "PRODUCTION") {
            return true;
        }
        // TODO properties in OSGi Component annotations are not transmitted correctly with Apache Felix SCR
        switch (component.factoryId) {
            case 'Fenecon.Dess.PvMeter':
            case 'Fenecon.Mini.PvMeter':
            case 'Fenecon.Pro.PvMeter':
            case 'Kaco.BlueplanetHybrid10.PvInverter':
            case 'Kostal.Piko.Charger':
            case 'PV-Inverter.Fronius':
            case 'PV-Inverter.KACO.blueplanet':
            case 'PV-Inverter.Kostal':
            case 'PV-Inverter.SMA.SunnyTripower':
            case 'PV-Inverter.Solarlog':
            case 'PV-Inverter.SunSpec':
            case 'Simulator.ProductionMeter.Acting':
            case 'Simulator.PvInverter':
            case 'SolarEdge.PV-Inverter':
                return true;
        }

        return false;
    }

The problem is, that the component property "type" is not present in the UI.

If I understand the mechanism behind correctly, the configuration object of the meter component at OSGi level is serialized and transferred to the frontend. The serialization is done by reflection of the config class (or more precise the config annotation). If there is no AttributeDefinition of "type" inside the configuration, than this attribute is not serialized to the frontend, even if it is present inside the property field of the component annotation at the implementing class.

See as example:

@Designate(ocd = Config.class, factory = true)
@Component(name = "Simulator.PvInverter", //
                immediate = true, configurationPolicy = ConfigurationPolicy.REQUIRE, //
                property = { //
                                "type=PRODUCTION" //
                })
@EventTopics({ //
                EdgeEventConstants.TOPIC_CYCLE_BEFORE_PROCESS_IMAGE, //
                EdgeEventConstants.TOPIC_CYCLE_AFTER_PROCESS_IMAGE //
})
public class PvInverter extends AbstractOpenemsComponent

The annotation definition/class 'Config' does not have an attribute named "type".

To make the workaround unnecessary, it is sufficient to add an attribute "type" in the annotation annotation definition/class "Config" (type String would work, but type io.openems.edge.meter.api.MeterType would be better.)

This is already done in several config definitions, e.g. io.openems.edge.meter.virtual/src/io/openems/edge/meter/virtual/symmetric/add/Config.java

Could you please check if this understanding and these thoughts are correct?

sfeilmeier commented 2 years ago

Hi Steffen,

sorry for late response due to holiday. You analysis is absolutely correct. The problem here is, that Eclipse Equinox (which we used previously) and Apache Felix (which is used currently) show different behaviour here. With Eclipse the @Component property had been properly exposed to the UI. That is why we decided to 'fix' it using this method in UI until we find a proper solution to the problem. Adding an option in Config.java is of course also possible, but not feasible in all cases, e.g. with a PV-Inverter which is by definition always measuring PRODUCTION.

As a side note. This is not strictly an issue ('Could you please check if this understanding and these thoughts are correct?') but more a question, so you are invited to discuss topics like this in the OpenEMS Community forum instead in future. (https://community.openems.io).

Regards, Stefan