Problem beim ToU Controller

Guten Morgen,

Ich und @GrisuBerlin sind auf ein Problem gestoßen. Wenn der Controller arbeitet, scheint “etwas” die Influx zu blockieren:

2024-03-29T14:17:07,216 [eTariff0] INFO  [fusetariff.optimizer.Optimizer] # Start next run of Optimizer
2024-03-29T14:17:07,225 [eTariff0] ERROR [.PredictorPersistenceModelImpl] [predictor1] Historic data is not available: query result is empty
2024-03-29T14:17:07,226 [eTariff0] ERROR [l.PredictorSimilardayModelImpl] [predictor0] InfluxDB read is temporarily blocked [0,410].
io.openems.common.exceptions.OpenemsException: InfluxDB read is temporarily blocked [0,410].
	at io.openems.shared.influxdb.proxy.QueryProxy.assertQueryLimit(QueryProxy.java:275)
	at io.openems.shared.influxdb.proxy.FluxProxy.executeQuery(FluxProxy.java:291)
	at io.openems.shared.influxdb.proxy.FluxProxy.queryHistoricData(FluxProxy.java:78)
	at io.openems.shared.influxdb.InfluxConnector.queryHistoricData(InfluxConnector.java:343)
	at io.openems.edge.timedata.influxdb.TimedataInfluxDbImpl.queryHistoricData(TimedataInfluxDbImpl.java:194)
	at io.openems.edge.predictor.similardaymodel.PredictorSimilardayModelImpl.createNewPrediction(PredictorSimilardayModelImpl.java:105)
	at io.openems.edge.predictor.api.prediction.AbstractPredictor.getPrediction(AbstractPredictor.java:64)
	at io.openems.edge.core.predictormanager.PredictorManagerImpl.getPrediction(PredictorManagerImpl.java:94)
	at io.openems.edge.controller.ess.timeofusetariff.optimizer.Utils.createSimulatorParams(Utils.java:146)
	at io.openems.edge.controller.ess.timeofusetariff.optimizer.Optimizer.createParams(Optimizer.java:101)
	at io.openems.edge.controller.ess.timeofusetariff.optimizer.Optimizer.forever(Optimizer.java:51)
	at io.openems.common.worker.AbstractWorker$1.run(AbstractWorker.java:156)
2024-03-29T14:17:07,271 [eTariff0] ERROR [s.common.worker.AbstractWorker] Worker error. IndexOutOfBoundsException: toIndex = 2784
java.lang.IndexOutOfBoundsException: toIndex = 2784
	at java.base/java.util.ImmutableCollections$AbstractImmutableList.subListRangeCheck(ImmutableCollections.java:274)
	at java.base/java.util.ImmutableCollections$AbstractImmutableList.subList(ImmutableCollections.java:266)
	at io.openems.edge.predictor.similardaymodel.PredictorSimilardayModelImpl.getSlicedArrayList(PredictorSimilardayModelImpl.java:155)
	at io.openems.edge.predictor.similardaymodel.PredictorSimilardayModelImpl.createNewPrediction(PredictorSimilardayModelImpl.java:132)
	at io.openems.edge.predictor.api.prediction.AbstractPredictor.getPrediction(AbstractPredictor.java:64)
	at io.openems.edge.core.predictormanager.PredictorManagerImpl.getPrediction(PredictorManagerImpl.java:94)
	at io.openems.edge.controller.ess.timeofusetariff.optimizer.Utils.createSimulatorParams(Utils.java:148)
	at io.openems.edge.controller.ess.timeofusetariff.optimizer.Optimizer.createParams(Optimizer.java:101)
	at io.openems.edge.controller.ess.timeofusetariff.optimizer.Optimizer.forever(Optimizer.java:51)
	at io.openems.common.worker.AbstractWorker$1.run(AbstractWorker.java:156)

Bei mir bisher nur beim Debuggen. Das scharfe System arbeitet.
Ich habe den Eindruck, dass dem Controller, bzw. dem Predictor, irgendetwas fehlt.

Bisher kann ich noch nicht viel an Infos liefern, steige aber tiefer ein, wenn etwas Zeit ist.

Gruß,
Klinki

Hast du die aktuellste Version von openEMS ?
Wir hatten glaube ich irgendwas ähnliches mit dem TimeData Ding :smiley:
Grüße !

wir hatten die Referenz auf den timedata-provider vergessen,bzw. nicht initialisiert. Das ist es aber nicht.
Das Problem tritt auch sporadisch auf, bzw. ich hab noch keine Systematik erkennen können.
Gruß
klinki

1 Like

Die Warnung InfluxDB read is temporarily blocked wird hier generiert → openems/io.openems.shared.influxdb/src/io/openems/shared/influxdb/proxy/QueryProxy.java at develop · OpenEMS/openems · GitHub

Der Grund für dieses Limit ist, dass die InfluxDB gelegentlich überlastet ist. In diesem Fall werden die Queries teilweise blockiert, damit sich die Datenbank wieder erholen kann.

Dieser Fehler scheint auch getriggert zu werden, wenn es die historischen Daten noch gar nicht gibt. Vermutlich müsste man in der InfluxDB unterscheiden, welcher Fehler genau aufgetreten ist.

Ich selbst arbeite beim Time-of-Use-Controller bisher nur mit der lokalen RRD4j.

Gruß,
Stefan

Hi Stefan,
Nach etwas InfluxDB-Tuning scheint sich dieses Problem erledigt zu haben.

Dafür jetzt ein anderes Thema:

Ich hatte gestern einen “Consumption not metered” Zähler in Betrieb genommen, aber heute wieder deaktiviert (nicht gelöscht).

Seit dem funktioniert der ToU-Controller nicht mehr:

Apr 05 14:43:57 fhemNEU java[3302183]: 2024-04-05T14:43:57,646 [ctrlToU1] INFO  [fusetariff.optimizer.Optimizer] # Start next run of Optimizer
Apr 05 14:43:57 fhemNEU java[3302183]: 2024-04-05T14:43:57,694 [ctrlToU1] ERROR [s.common.worker.AbstractWorker] Worker error. IndexOutOfBoundsException: toIndex = 2688
Apr 05 14:43:57 fhemNEU java[3302183]: java.lang.IndexOutOfBoundsException: toIndex = 2688
Apr 05 14:43:57 fhemNEU java[3302183]:         at java.base/java.util.ImmutableCollections$AbstractImmutableList.subListRangeCheck(ImmutableCollections.java:274)
Apr 05 14:43:57 fhemNEU java[3302183]:         at java.base/java.util.ImmutableCollections$AbstractImmutableList.subList(ImmutableCollections.java:266)
Apr 05 14:43:57 fhemNEU java[3302183]:         at io.openems.edge.predictor.similardaymodel.PredictorSimilardayModelImpl.getSlicedArrayList(PredictorSimilardayModelImpl.java:155)
Apr 05 14:43:57 fhemNEU java[3302183]:         at io.openems.edge.predictor.similardaymodel.PredictorSimilardayModelImpl.createNewPrediction(PredictorSimilardayModelImpl.java:132)
Apr 05 14:43:57 fhemNEU java[3302183]:         at io.openems.edge.predictor.api.prediction.AbstractPredictor.getPrediction(AbstractPredictor.java:64)
Apr 05 14:43:57 fhemNEU java[3302183]:         at io.openems.edge.core.predictormanager.PredictorManagerImpl.getPrediction(PredictorManagerImpl.java:94)
Apr 05 14:43:57 fhemNEU java[3302183]:         at io.openems.edge.controller.ess.timeofusetariff.optimizer.Utils.createSimulatorParams(Utils.java:145)
Apr 05 14:43:57 fhemNEU java[3302183]:         at io.openems.edge.controller.ess.timeofusetariff.optimizer.Optimizer.createParams(Optimizer.java:101)
Apr 05 14:43:57 fhemNEU java[3302183]:         at io.openems.edge.controller.ess.timeofusetariff.optimizer.Optimizer.forever(Optimizer.java:51)
Apr 05 14:43:57 fhemNEU java[3302183]:         at io.openems.common.worker.AbstractWorker$1.run(AbstractWorker.java:156)

Ich hatte alles Mögliche ausprobiert und bin beim Debuggen darauf gestoßen, dass im predictor.similardaymodel der Kanal für die _sum/UnmanagedConsumptionActivePower immer nur null-Werte zurücklieferte. Daraufhin habe ich bei den Predictors (persistent und similar day) besagten Kanal deaktiviert.
Jetzt läuft der Controller wieder.

Verstehe ich das richtig und “UnmanagedConsumptionActivePower” ist “Sonstiger” Verbrauch?
Darauf könnte man (ich) zunächst verzichten. Problem ist nur, dass im Influx ein Kanal nicht so einfach gelöscht, bzw. neu erstellt werden kann.

Außer das in den Predictors selbst abzufangen, fällt mir aktuell nicht viel dazu ein.

Gruß,
Klinki

Ich bin mal etwas tiefer eingestiegen. Kurz zum Verständnis:
UnmanagedConsumptionActivePower: ungesteuerte Lasten. Also aktuell alle Verbraucher außer EVCS
ConsumptionActivePower: Alle Verbraucher

Da die Wallbox nicht benutzt wird, sollten UnmanagedConsumptionActivePower und ConsumptionActivePower gleich sein, oder? Zumindest sieht es in Grafana so aus.

Auch ein Vergleich der Queries aus buildHistoricDataQuery in FluxProxy brachte keine Erkenntnis. Influx Data Explorer lieferte bei beidem Ergebnisse, die augenscheinlich deckungsgleich sind.

Der Fehler wird anschließend im Predictor bei

var mainData = getSlicedArrayList(result, numOfDataPerDay);

geworfen.

Hat jemand noch eine Idee?

Gruß,
Klinki

Vielleicht bin ich einen Schritt weiter.
Wenn ich es recht verstehe, wird für den Predictor ein zweidimensionales Array für das fragliche Zeitfenster erzeugt mit einer bestimmten Auflösung (96 Datensätze pro Tag).
Kann es sein, dass der Predictor durcheinanderkommt, wenn man die Auflösung innerhalb der Influx-Konfiguration (write interval) ändert ?

Ich habe in io.openems.edge.predictor.similardaymodel versuchsweise 2 Methoden geändert um die Neu-Indizierung sicherer zu machen:

	private static List<List<Integer>> getSlicedArrayList(List<Integer> arrlist, int n) {
	    var m = arrlist.size();
	    List<List<Integer>> twoDimensionalArrayList = new ArrayList<>();
	    for (var i = 0; i < m; i = i + n) {
	        int end = Math.min(i + n, m); // 
	        twoDimensionalArrayList.add(arrlist.subList(i, end));
	    }
	    return twoDimensionalArrayList;
	}

und

	private static List<Integer> getAverage(List<List<Integer>> twoDimensionalArrayList) {

	    
	    List<Integer> averageList = new ArrayList<>();
	    int maxCols = twoDimensionalArrayList.stream().mapToInt(List::size).max().orElse(0); // max column size

	    for (var i = 0; i < maxCols; i++) {
	        var sumRow = 0;
	        var validRows = 0; // Count of non-null rows for the current column
	        for (var j = 0; j < twoDimensionalArrayList.size(); j++) {
	            List<Integer> row = twoDimensionalArrayList.get(j);
	            if (i < row.size() && row.get(i) != null) { // index exists? null needed?
	                sumRow += row.get(i);
	                validRows++;
	            }
	        }
	        if (validRows > 0) {
	            averageList.add(sumRow / validRows); 
	        } else {
	            averageList.add(0); 
	        }
	    }
	    return averageList;
	}

Mein Verständnis für die Vorhersage reicht aber nicht aus um zu sagen, ob für jeden Slice ein Wert vorhanden sein muss, oder ob mal null-values rauswerfen kann/sollte.
Vielleicht könnte sich das ein Profi mal anschauen?

Gruß,
Klinki

1 Like