How can I prevent the error “Coefficient [ess0,ALL,ACTIVE] was not found. Ess-Power is not (yet) fully initialized.” from occurring?

English Forum Software-Development
1

I’m developing an OpenEMS setup with the following configuration:

ess0: Custom ModbusDevice ESS
Interfaces: ManagedSymmetricEss, SymmetricEss, ModbusComponent, OpenemsComponent, TimedataProvider, EventHandler

meter0: Custom ModbusDevice PV-Inverter (MeterType=Production)

Interfaces: ManagedSymmetricPvInverter, ElectricityMeter, ModbusComponent, OpenemsComponent, TimedataProvider, EventHandler

ctrl0: Custom Controller
Implements a simple ESS charge/discharge control logic similar to ControllerEssBalancing

Occasionally, when starting the application, I encounter the error mentioned above, which prevents the controller from operating correctly. The error does not occur consistently—sometimes the system starts without issue, but if it fails once, it tends to keep failing.

I’ve found that deleting and recreating the ess0 instance via the Apache Felix Web Console Configuration resolves the issue temporarily, but I’m unsure of the root cause.

I suspect the problem may be related to the timing of object initialization, such as EssPower. Is there a recommended way to ensure proper initialization and avoid this error?

For reference, I found a similar topic here, but my setup uses SymmetricEss rather than AsymmetricEss.

2

Hi and Welcome to OpenEMS @masa ,

unfortunately without knowing anything about your Devices and Code it is hard to tell you the exact cause of the “Issue”.

However:

The error “Coefficient [ess0,ALL,ACTIVE] was not found. Ess-Power is not (yet) fully initialized” occurs when the EssPower component tries to access coefficients before the ESS components have been registered. This is a timing issue in OSGi component initialization.

To prevent this error, ensure proper initialization ordering:

1. Add EventHandler to your ESS component and wait for the first cycle:

  @EventTopics({EdgeEventConstants.TOPIC_CYCLE_AFTER_CONTROLLERS})
  public class YourEssImpl implements ManagedSymmetricEss, EventHandler {
      private boolean initialized = false;

      @Override
      public void handleEvent(Event event) {
          if (!initialized) {
              initialized = true;
          }
      }
  }

2. Check initialization in your controller before using EssPower:

try {
      power.getCoefficient(ess, SingleOrAllPhase.ALL, Pwr.ACTIVE);
  } catch (OpenemsException e) {
      // ESS not yet registered in EssPower, skip this cycle
      return;
  }

3. Ensure proper OSGi references in your components:

  @Reference(
      policy = ReferencePolicy.DYNAMIC,
      policyOption = ReferencePolicyOption.GREEDY,
      cardinality = ReferenceCardinality.MANDATORY
  )

  private EssPower power;

4. Add initialization delay if needed:

  @Activate
  private void activate(ComponentContext context, Config config) {
      // Delay to ensure EssPower registers this ESS
      new Thread(() -> {
          try { Thread.sleep(1000); } catch (Exception e) {}
          // Your initialization code
      }).start();
  }
3

Thanks for the reply.

Our custom ESS implementation for the ModbusDevice class implements ManagedSymmetricEss, and includes the following snippet (based on the existing SimulatorEssSymmetricReactingImpl code):

@Reference
private Power power;

@Override
public Power getPower() {
return this.power;
}

Since this error occurs intermittently on application startup, I’ve come to understand that it’s likely due to timing issues with OSGi component initialization.

Regarding suggestion #2, I had tried implementing that check. However, if the initialization order is reversed and the Controller calls the setActivePowerEqualsWithPid method from the ManagedSymmetricEss interface even once, the error persists afterward.

If no other workaround seems viable, I think I’ll go ahead and mark this as solved.

4

Hi @masa and welcome to the OpenEMS Community.

I see you are evaluating OpenEMS as a commercial company. I wish you a lot of success and hope for your project testimonial if it works out. Also please consider joining the OpenEMS Association - it’s cheap and helps us funding the organizational structures etc.

Regarding your question: Yes, most likely there is a timing issue or some issue with activate/modified/deactivate in your code. Are you able to share your implementation on Github, so some experts could have a look at obvious errors?

Thanks,
Stefan

2 Likes
5

Hi @stefan.feilmeier

Thank you for your kind support.
At this point, I believe the issue is more related to the OSGi application itself rather than OpenEMS. I’ll try the suggested approaches and monitor the behavior. If the problem still isn’t resolved, I’m considering sharing the implementation on GitHub so you can take a closer look.

6

Would be still great, if you could share it either way we resolve it or not as Stefan told OpenEMS is an OpenSource Project and relies and the Activity of their Users :frowning:

1 Like