ottopaulsen / node-red-contrib-power-saver

A Node-RED node to saver money by turning off when the power is most expensive
Other
70 stars 17 forks source link

Reduction node not turning off the heater causing grid tariff level to break 5 kwh level #145

Open shadowano opened 1 year ago

shadowano commented 1 year ago

My complete setup is earlier described on #128

This night from 04-05 I went from an average of the 3 highest days at 4,7 kwh to 5,2 kwh. I identified that the reduction node was not called.

First a screenshot of a graph showing that:

  1. Current Hour estimate is stable above 6 the whole hour
  2. Average 3 highest values above 5 the whole hour
  3. Power reduction required increasing and increasing
  4. VVB heater is on the complete hour (according to schedule)

image

The screenshot below is showing the logs from reduction and reset actions. No reduction action was sent during this hour.

image

I'm also catching any errors thrown by the reduction and reset actions to file, but none was logged. Is there anything that can explain why the device was not turned off when required power reduction was very high?

for reference, the reduction node "On Start " tab:

const actions = [
    {
        consumption: 3,
        name: "Varmtvannsbereder",
        id: "vvb",
        minAlarmLevel: 3,
        reduceWhenRecommended: true,
        minTimeOffSec: 300,
        nameOfStrategyToOverride: "Lowest Price",
        payloadToTakeAction: {
            domain: "switch",
            service: "turn_off",
            target: {
                entity_id: ["switch.varmtvannstanken"],
            }
        },
        payloadToResetAction: {
            domain: "switch",
            service: "turn_on",
            target: {
                entity_id: ["switch.varmtvannstanken"],
            }
        }
    }
];
ottopaulsen commented 1 year ago

I have an idea. You are sending the output from the Reduction Actions node to the Schedule Merger (which is correct), but in the settings you have set nameOfStrategyToOverride: "Lowest Price". This will not work. You should change Lowest Price here to Schedule Merger.

However, since you are still having the payloadToTakeAction and payloadToResetAction, if these are set up correct, they should work instead of the override. Is there something with these that has been changed?

Normally you would not use nameOfStrategyToOverride together with payloadToTakeAction and payloadToResetAction, but if you do, they both should take effect.

shadowano commented 1 year ago

Thanks for pointing that out. I discovered that when I was copying the json, and changed it from Schedule merger to Lowest price, as I changed my setup earlier to Lowest price strategy node. So many things that are needed to change when changing strategy node :)

So you are saying that I should only be using either override on the strategy node, or use the Perform action? Maybe this should be a bit more clear in the documentation?

ottopaulsen commented 1 year ago

image

Is this not good enough?

shadowano commented 1 year ago

It is:) just didn't see it.

But how is this explaining why reduction node did not send out anything on its outputs when it broke the 5kwh limit?

This has worked fine in most cases, it turns off and on the device according to the limits set up.

ottopaulsen commented 1 year ago

Sorry, I cannot tell 🙄

ottopaulsen commented 1 year ago

Maybe this is your problem too (issue #146). In the code for reduction action, the consumption is divided by 1000 (return sensor.state / 1000). When looking again, it is probably not the reason in your case. You have hardcoded a number (3), and it is supposed to be treated as kW. However, there may be an error here.

Anyway, I recommend you use a sensor for the consumption, if you have one, or else it will think it is always using 3 kW, and will turn it off even if it is not using anything.

shadowano commented 1 year ago

In the code for reduction action, the consumption is divided by 1000 (return sensor.state / 1000). When looking again, it is probably not the reason in your case. You have hardcoded a number (3), and it is supposed to be treated as kW Correct, my number is an integer, so the method getConsumtion is just returning the number 3. It is not being divided by 1000.

reductionRequired = Math.max(0, reductionRequired - consumption); I see reductionRequired is in kWh, so this means consumption should also be in kWh. So 3 as int value is then correct, right?

I only have a sensor for the current consumption (in watt) being used, so when it's not using anything the sensor would return 0. Is this the sensor I can use?

I don't have a problem that the actions nodes doesn't trigger at all, it's just that some some hours they don't trigger when they should.

The variable called "actionTaken" is set to true when Reduction action node triggers, and reset again when Reset Action node is triggered. In the screenshot from my initial post we can see that the reduction action node was called at 00:05, and the reset action was not called until 04:18 UTC (very long time between these). This means the variable should be false and not prevent the action from being called between 4-5 GMT+1. reductionRecommended was also higher than 0. I don't have a sensor for alarmLevel so can't look into the history for this one. I will add one as this is the only one left that could prevent the action from turning off the device.

ottopaulsen commented 1 year ago

Looks like you have pretty good control, so you should be able to debug it well. I have seen another problem, not sure if it is relevant, but if a reduction action is taken, and you restart Node RED, the device that is turned off will not be turned on by the Reset Action node, since all data is cleared, and since it is off, consumption is 0, so it will never be turned off either.

A fix for this is an inject node sending some JSON into the Reduction Action node like this:

image

Config:

image image

The json is: {"increasePossible":100,"clear":true}.

And the following code in the Reset Action node:


const actions = flow.get("actions")
const ha = global.get("homeassistant").homeAssistant

const BUFFER_TO_RESET = 1 // Must have 1kW extra to perform reset

let increasePossible = msg.payload.increasePossible

if (increasePossible <= 0) {
  return null
}

function resetAction(action) {
  const info = {
    time: new Date().toISOString(),
    name: "Reset action",
    data: msg.payload,
    action
  }
  const output1 = action.payloadToResetAction ? { payload: action.payloadToResetAction } : null
  const output2 = action.nameOfStrategyToOverride ? { payload: { config: { override: "auto" }, name: action.nameOfStrategyToOverride } } : null
  const output3 = { payload: info }

  node.send([output1, output2, output3])
  increasePossible -= action.savedConsumption
  action.actionTaken = false
  action.savedConsumption = 0
  flow.set("actions", actions)
}

actions
  .filter(a => (a.actionTaken 
    && (a.savedConsumption + BUFFER_TO_RESET) <= increasePossible
    && (Date.now() - a.actionTime > a.minTimeOffSec * 1000)) || msg.payload.clear
  ).forEach(a => resetAction(a))
shadowano commented 1 year ago

Thanks for the tip for reset the reset action node :)

We'll see next month if it works better or not:)

shadowano commented 1 year ago

Hi, I have not encountered the exact same thing, but I have seen a few odd things that might be related (or not).

Do you suggest a restart of the flow once a day or something? It shouldn't be necessary right?