Graph bars of the past shown as spikes, future as bars

Setup, Configuration and Use Beginners
1
  • Platform information:
    • Hardware: Orangepi 3 LTS
    • OS: Armbian 5
    • openHAB version: 3.4
  • Issue of the topic: Openhab graph bars shown as spikes, future shown as bars

I am using influxdb2 and the solution described in Control a water heater and ground source heat pump based on cheap hours of spot priced electricity - #152 by masipila

For some reason my bars show as spikes in the past:

kuva
kuva1612×941 29.8 KB

But proper bars in the future:

kuva
kuva1547×935 27.9 KB

This only happens when I include the item corresponding to car charging, “Sähköauto”. If I remove that the bars of the past look as they should. I have triple checked that the settings of the car chargin item are the same as for the rest of the items.

2

I’ve had similar thing if I have control values on non-full hours. If I only have control values for full hours, then the graph renders wider bars.

3

How is it possible to have control values on non full hours? Aren’t the points all only on full hours?

Or maybe rather, how to avoid it from happening?

4

You may want to use an aggregation function over the reporting interval (e.g., hourly average or hourly maximum)

5

I sometines want to manually override the control values that have been automatically calculated. For this, I have an UI datetime widget to force a given hour’s control value on / off, see screenshot.

I have to be very careful and select full hour in this widget so that the control value will be written for the full hour. If I make a mistake and select for example 15:01 with the widget, then I will have two control values, one for 15:00 and another for 15:01.

Markus

Screenshot_20230720_155008_Firefox
Screenshot_20230720_155008_Firefox1080×2340 138 KB

6

What causes the error? Will the control point end up on e.g 15:01 if the script that sets the control points runs over a minute? My script sets control points for dishwasher, washing machine and car charging in one script and in that order. Car charging control points are set last.

7

That should not matter because we’re anyway talking about control points of tomorrow. I’d suggest that you inspect your raw data points in InfluxDB data explorer to see if this hypothesis is correct to begin with.

8

image
image1291×294 26.2 KB

I am not sure if this is the right picture, but to me these are not on the hour at all.

9

How do the other control values look like?

10

image
image1563×771 87 KB

I am not at all sure I am looking at the right values. I do not really know how to use InfluxDB Data Explorer.

11

I don’t think these latter values are your control values, they seem to be the actual start times of your dish washer or laundry machine based on the names of your measurements.

You can use the measurement names (such as nibe_control, waterheater_control) as the filter on the bottom part of the screen.

12

Dishwasher control:

image
image1511×278 45.8 KB

Car charger control:

image
image1522×301 46.8 KB

Is this of any use? I do not know what I am doing.

13

Your control values seem to follow the same pattern with each other. For some reason your control values are at 30 min past full hour when inspected with influx data explorer, it’s the time_ attribute / column that I was interested in. You can see the 0 and 1 control values there for each hour.

But anyway, the reason for the spikes in the chart is that on 2023-07-20 you had two car charger control values for the same hour (they were 10 seconds apart from each other). I suspect that you have a configuration bug.

You should have two clearly de-coupled items (and influxdb measurements). One for the control values (when the chargong should be on) and another for the actuals (when the charging actually was on). I suspect that your rules that toggle the charging on/off are also writing to the control value measurement.

14

The only rule I could find running at 30 minutes past full hour was the rule that determines the number of heating hours which, when run, also triggers the fetching of spot prices from Ensto-E. I made this now run at 15:00 only, as opposed to the earlier 14:30 and 19:30

This is probable. I have tested with a number of item names to fix the problem. There may still be duplicate rules and/or items running. Need to do a cleanup of the spaghetti this has turned into during the debugging.

Thanks for the help, will report results later.

15

My rules are structured as follows:

Rule FetchWeatherForeacast

  • Runs 3 minutes after every full hour
  • Fetches the fresh weather forecast and does nothing else

Rule CalculateHeatingHours

  • Runs daily at 14.20
  • The script action implicitly assumes that we previously fetched weather forecast data in our database but does not re-fetch it. It simply calculates the heating hours and saves the result to an Item called "HeatingHours"l

Rule FetchSpotPrices

  • Runs 14.15, 14.45, 15.15 and 15.45
  • The first rule action contains the code that fetches the spot prices from Entso-E API
  • It also invokes 4 other rules as can be seen in the screenshot below. These are “DetermineWaterHeatingControls”, “DetermineCompressorControls”, “DetermineNibeWaterHeatingControls” and “DetermineCarChargingControls”. In other words, every device that has control points has its own “Determine control points” rule which are invoked here.
    image
    image660×520 7.25 KB

Rule DetermineCompressorControls

  • These control points are re-determined whenever the HeatingHours (or HeatingSlices or MinimumHeatingPerSlice) has changed, see screenshot below
    image

Summary
The benefit of breaking down the logic like this is that

  • I don’t need to call the Entso-E API over and over again if I need to re-determine the control points for one device
  • If I need to re-determine the control points for one device, I don’t need to re-determine the other control points
  • One “DetermineXXXControlPoints” rule does only one thing, easy to maintain
  • The “When HeatingHours changed” condition means that the control points are automatically re-determined when the item “HeatingHours” changes. Which happens either automatically by the rule CalculateHeatingHours OR if I manually change it with an UI widget which looks like this:
    image
    image330×731 11.7 KB
  • The point of this UI is that I can easily override the heating parameters if there is a need to do so. Whenever these parameters change, the heating control points are re-determined.

You’re of course free to structure your rules however you want but I have found this de-coupled approach to be easy to maintain.

16

This indeed was the root cause for the problem.
For the system to work I have created items with same names as the points the forecast scripts create in InfluxDB in the future, e.g. “washer_control”, “charger_control” etc. These same items are mapped in the graphs.

However, these item states do not automatically change when the InfluxDB point changes. Hence, I had to make a script that every full hour gets the current value of the InfluxDB point and updates the corresponding item with the current value. Herein lies the error. When I updated the item the item value was updated back to InfluxDB! As a result there was two values for the same item at a bit separate times. This confused the graph.

This is how the buggy script looked before:

dh = require('kotitie/date-helper.js');
influx = require('kotitie/influx.js');
nyt = dh.getCurrentHour();

// update dishwasher control item
tiskikoneenOhjaus = influx.getCurrentControl('dishwasher_control',nyt);
console.log("Tiskikoneen ohjaus: " + tiskikoneenOhjaus);
items.getItem("dishwasher_control").sendCommand(tiskikoneenOhjaus);

// update washer control item
pesukoneenOhjaus = influx.getCurrentControl('washer_control',nyt);
console.log("Pesukoneen ohjaus: " + pesukoneenOhjaus);
items.getItem("washer_control").sendCommand(pesukoneenOhjaus);

// update car charging control item
latauksenOhjaus = influx.getCurrentControl('charger_control',nyt);
console.log("Auton latauksen ohjaus: " + latauksenOhjaus);
items.getItem("charger_control").sendCommand(latauksenOhjaus);

To solve the problem I created new items that the script updates and are then separateley tracked by the actual control rule:

dh = require('kotitie/date-helper.js');
influx = require('kotitie/influx.js');
nyt = dh.getCurrentHour();

// update dishwasher control item
tiskikoneenOhjaus = influx.getCurrentControl('dishwasher_control',nyt);
console.log("Tiskikoneen ohjaus: " + tiskikoneenOhjaus);
items.getItem("dishwasher_control_switch").sendCommand(tiskikoneenOhjaus);

// update washer control item
pesukoneenOhjaus = influx.getCurrentControl('washer_control',nyt);
console.log("Pesukoneen ohjaus: " + pesukoneenOhjaus);
items.getItem("washer_control_switch").sendCommand(pesukoneenOhjaus);

// update car charging control item
latauksenOhjaus = influx.getCurrentControl('charger_control',nyt);
console.log("Auton latauksen ohjaus: " + latauksenOhjaus);
items.getItem("charger_control_switch").sendCommand(latauksenOhjaus);

It seems like the update does not automatically happen from InfluxDB => Item, but the update happens automatically from Item => InfluxDB.