Feature request: ps-strategy-heat-capacitor should also use `setTimeout()`

ottopaulsen / node-red-contrib-power-saver

A Node-RED node to saver money by turning off when the power is most expensive

Other

71 stars 17 forks source link

Feature request: ps-strategy-heat-capacitor should also use `setTimeout()` #94

Open marhoy opened 1 year ago

marhoy commented 1 year ago

The best-save and lowest-price nodes uses setTimeout() to sleep until the next on/off event occurs. Thus, they are able to wake up and turn things on/off at the right times.

But the heat-capacitor node only sends its output whenever it receives any input: It lacks the method to wake itself up whenever it's time to send new input. Thus, even though the schedule says it should increase temperature at e.g. 14:00, the output will not be sent until a new input arrives. The new input will typically be new/updated priceData, but there's no guarantee that new priceData will arrive at suitable times.

As an example: In my flow, I fetch Tibber/Elvia-data at deployment time, and then every 60 minutes from there. So if I deploy at xx:42, the heat-capacitor node will only send/change output every xx:42.

jenseo commented 1 year ago

@marhoy I had the same issue but solved it by setting the query (inject node) to re-fetch at every change of our, it's one of the repeat options you find there. Not optimal though, in case the Api is down or similar

marhoy commented 1 year ago

@jenseo Yes, it's possible to find a workaround, sort of. But:

The data from the Tibber-API really only changes once per day (around 1300), so it's not necessary to poll it every hour.
You could e.g. inject some dynamic config-parameter to the scheduler every now and then to force the scheduler to produce output. But it's still not optimal.

You really want the scheduler to figure out by itself when it needs to send updated outputs (like the two other schedulers do).

Consider e.g. if I manually adjust one of the thermostats that the scheduler writes its setpoint to. If I do that, I want that manual value stay there for at least a while (I'm OK with it being overruled the next time there is a scheduling event).

TomTorger commented 1 year ago

Hmm... I could add something similar to the other nodes, but not quite sure of what configuration options etc. the user would need.

I did add support for dynamic commands in current PR, so I guess that will solve it for the more advanced users :-)