node-red-contrib-power-saver 4.2.1 → 4.2.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/docs/.vuepress/config.js +16 -13
- package/docs/.vuepress/public/ads.txt +0 -1
- package/docs/README.md +1 -3
- package/docs/changelog/README.md +30 -0
- package/docs/contribute/README.md +1 -1
- package/docs/examples/README.md +1 -2
- package/docs/faq/README.md +1 -1
- package/docs/faq/best-save-viewer.md +7 -2
- package/docs/guide/README.md +18 -4
- package/docs/nodes/README.md +7 -4
- package/docs/nodes/dynamic-commands.md +6 -5
- package/docs/nodes/dynamic-config.md +8 -2
- package/docs/nodes/old-power-saver-doc.md +27 -1
- package/docs/nodes/ps-elvia-add-tariff.md +7 -3
- package/docs/nodes/ps-general-add-tariff.md +9 -3
- package/docs/nodes/ps-receive-price.md +13 -3
- package/docs/nodes/ps-schedule-merger.md +17 -1
- package/docs/nodes/ps-strategy-best-save.md +23 -5
- package/docs/nodes/ps-strategy-fixed-schedule.md +11 -3
- package/docs/nodes/ps-strategy-heat-capacitor.md +16 -2
- package/docs/nodes/ps-strategy-lowest-price.md +21 -3
- package/docs/nodes/strategy-input.md +3 -1
- package/package.json +13 -13
- package/src/strategy-lowest-price.html +0 -1
package/docs/.vuepress/config.js
CHANGED
|
@@ -2,31 +2,33 @@ import navbar from "./navbar";
|
|
|
2
2
|
import { path } from "@vuepress/utils";
|
|
3
3
|
import { registerComponentsPlugin } from "@vuepress/plugin-register-components";
|
|
4
4
|
import { searchPlugin } from "@vuepress/plugin-search";
|
|
5
|
-
import { googleAnalyticsPlugin } from "@vuepress/plugin-google-analytics";
|
|
6
5
|
|
|
7
|
-
import { defaultTheme
|
|
6
|
+
import { defaultTheme } from "@vuepress/theme-default";
|
|
7
|
+
import { defineUserConfig } from "vuepress";
|
|
8
|
+
import {viteBundler} from "@vuepress/bundler-vite"
|
|
8
9
|
|
|
9
10
|
export default defineUserConfig({
|
|
10
11
|
base: "/",
|
|
12
|
+
bundler: viteBundler({}),
|
|
11
13
|
description: "A Node-RED node collection to save money on hourly changing power prices",
|
|
12
14
|
head: [
|
|
13
15
|
["link", { rel: "shortcut icon", type: "image/x-icon", href: "euro.png" }],
|
|
14
|
-
[
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
],
|
|
16
|
+
// [
|
|
17
|
+
// "script",
|
|
18
|
+
// {
|
|
19
|
+
// async: true,
|
|
20
|
+
// crossorigin: "anonymous",
|
|
21
|
+
// src: "https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-9857859182772006",
|
|
22
|
+
// },
|
|
23
|
+
// ],
|
|
22
24
|
],
|
|
23
25
|
lang: "en-US",
|
|
24
26
|
plugins: [
|
|
25
27
|
registerComponentsPlugin({ componentsDir: path.resolve(__dirname, "./components") }),
|
|
26
28
|
searchPlugin({}),
|
|
27
|
-
googleAnalyticsPlugin({
|
|
28
|
-
|
|
29
|
-
}),
|
|
29
|
+
// googleAnalyticsPlugin({
|
|
30
|
+
// id: "G-Z2QNNCDQZG",
|
|
31
|
+
// }),
|
|
30
32
|
],
|
|
31
33
|
theme: defaultTheme({
|
|
32
34
|
contributors: false,
|
|
@@ -79,4 +81,5 @@ export default defineUserConfig({
|
|
|
79
81
|
"/changelog/": [{ text: "Changelog", children: ["/changelog/README.md"] }],
|
|
80
82
|
},
|
|
81
83
|
}),
|
|
84
|
+
title: "PowerSaver"
|
|
82
85
|
});
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
google.com, pub-9857859182772006, DIRECT, f08c47fec0942fa0
|
package/docs/README.md
CHANGED
|
@@ -7,7 +7,7 @@ heroText: node-red-contrib-power-saver
|
|
|
7
7
|
tagline: A collection of nodes to Node-RED that automates saving money on variable electricity prices
|
|
8
8
|
actions:
|
|
9
9
|
- text: Guide
|
|
10
|
-
link: /guide
|
|
10
|
+
link: /guide/
|
|
11
11
|
type: primary
|
|
12
12
|
- text: Nodes
|
|
13
13
|
link: /nodes/
|
|
@@ -33,8 +33,6 @@ footer: Created by Otto Paulsen and contributors
|
|
|
33
33
|
footerHtml: true
|
|
34
34
|
---
|
|
35
35
|
|
|
36
|
-
<AdsenseAdd type="artikkel"/>
|
|
37
|
-
|
|
38
36
|
This is a collection of nodes for the popular [Node-RED](https://nodered.org/) that you can use to save money on variable electricity prices. Node-RED is a widely used low-code programming tool that can be used together with many smart home solutions to create automations.
|
|
39
37
|
|
|
40
38
|
Please remember to take a look at our [privacy rules](./privacy.md).
|
package/docs/changelog/README.md
CHANGED
|
@@ -7,6 +7,15 @@ sidebarDepth: 1
|
|
|
7
7
|
|
|
8
8
|
List the most significant changes.
|
|
9
9
|
|
|
10
|
+
## 4.2.3
|
|
11
|
+
|
|
12
|
+
- Update dependencies
|
|
13
|
+
|
|
14
|
+
## 4.2.2
|
|
15
|
+
|
|
16
|
+
- Remove ads from doc.
|
|
17
|
+
- Remove console.log msg from node.
|
|
18
|
+
|
|
10
19
|
## 4.2.1
|
|
11
20
|
|
|
12
21
|
- Bugfix version 4.2.0. Change was not effective.
|
|
@@ -16,6 +25,8 @@ List the most significant changes.
|
|
|
16
25
|
- Format time on node status with HH:MM format. No AM/PM any more.
|
|
17
26
|
- Remove warning for `No schedule` in debug output.
|
|
18
27
|
|
|
28
|
+
|
|
29
|
+
|
|
19
30
|
## 4.1.5
|
|
20
31
|
|
|
21
32
|
- Fixed bug based on [this issue](https://github.com/ottopaulsen/node-red-contrib-power-saver/issues/184). Now correctly uses the value for `outputOutsidePeriod` when the planning period spans midnight, and there is no data available before midnight. In this case, the period from midnight to end time cannot be planned, so `outputIfNoSchedule` will be used until end time, and `outputOutsidePeriod` will be used from then. See the issue for more details.
|
|
@@ -24,6 +35,8 @@ List the most significant changes.
|
|
|
24
35
|
|
|
25
36
|
- Update dependencies.
|
|
26
37
|
|
|
38
|
+
|
|
39
|
+
|
|
27
40
|
## 4.1.3
|
|
28
41
|
|
|
29
42
|
- Fix bug that saved some data in wrong context storage.
|
|
@@ -37,6 +50,8 @@ List the most significant changes.
|
|
|
37
50
|
|
|
38
51
|
- Update dependencies
|
|
39
52
|
|
|
53
|
+
|
|
54
|
+
|
|
40
55
|
## 4.1.0
|
|
41
56
|
|
|
42
57
|
- Fix bug with override function. It did not override longer than until next scheduled change. Now it overrides until set to auto again.
|
|
@@ -50,6 +65,8 @@ There are a couple of new nodes that open for many interesting use cases.
|
|
|
50
65
|
A rewrite like this may lead to changes in behavior, intended or not.
|
|
51
66
|
There are some breaking changes, but most users should not be affected by them.
|
|
52
67
|
|
|
68
|
+
|
|
69
|
+
|
|
53
70
|
### New features
|
|
54
71
|
|
|
55
72
|
- New node `ps-schedule-merger` or `Schedule Merger`, used to merge schedules from multiple Best Save and/or Lowest Price nodes,
|
|
@@ -71,6 +88,8 @@ There are some breaking changes, but most users should not be affected by them.
|
|
|
71
88
|
- Some bug-fixes may be regarded as breaking.
|
|
72
89
|
- There may be some changes to what data that is stored in the context.
|
|
73
90
|
|
|
91
|
+
|
|
92
|
+
|
|
74
93
|
### Bug fixes
|
|
75
94
|
|
|
76
95
|
- Fix so the `If no schedule, send` config works as one should expect for the end of the schedule.
|
|
@@ -140,6 +159,8 @@ There are some breaking changes, but most users should not be affected by them.
|
|
|
140
159
|
|
|
141
160
|
- Update github actions to deploy automatically to the npm library.
|
|
142
161
|
|
|
162
|
+
|
|
163
|
+
|
|
143
164
|
## 3.5.0
|
|
144
165
|
|
|
145
166
|
- Select what context storage to store data in the node configuration.
|
|
@@ -186,6 +207,8 @@ There are some breaking changes, but most users should not be affected by them.
|
|
|
186
207
|
- Fix node status so it says "No price data" when there is no price data available.
|
|
187
208
|
- Added an FAQ section to the doc.
|
|
188
209
|
|
|
210
|
+
|
|
211
|
+
|
|
189
212
|
## 3.2.3
|
|
190
213
|
|
|
191
214
|
- Remove unused imports
|
|
@@ -231,6 +254,8 @@ There are some breaking changes, but most users should not be affected by them.
|
|
|
231
254
|
- Fix bug in Lowest Price node when period goes over midnight.
|
|
232
255
|
- Fix documentation - lots of pages were failing.
|
|
233
256
|
|
|
257
|
+
|
|
258
|
+
|
|
234
259
|
## 3.0.7
|
|
235
260
|
|
|
236
261
|
- Fix Nord Pool current state node input.
|
|
@@ -273,6 +298,8 @@ There are some breaking changes, but most users should not be affected by them.
|
|
|
273
298
|
- New documentation.
|
|
274
299
|
- Change node category to Power Saver.
|
|
275
300
|
|
|
301
|
+
|
|
302
|
+
|
|
276
303
|
## 2.1.0
|
|
277
304
|
|
|
278
305
|
- Accept config as input, making it possible to dynamically change config
|
|
@@ -291,6 +318,8 @@ There are some breaking changes, but most users should not be affected by them.
|
|
|
291
318
|
|
|
292
319
|
- Bugfix
|
|
293
320
|
|
|
321
|
+
|
|
322
|
+
|
|
294
323
|
## 2.0.2
|
|
295
324
|
|
|
296
325
|
- Fix so Nord Pool data can be read directly from the current state node
|
|
@@ -310,3 +339,4 @@ There are some breaking changes, but most users should not be affected by them.
|
|
|
310
339
|
## 1.0.9
|
|
311
340
|
|
|
312
341
|
- Fix bug in saving last hour of the day.
|
|
342
|
+
|
package/docs/examples/README.md
CHANGED
package/docs/faq/README.md
CHANGED
|
@@ -17,7 +17,7 @@ Then paste it here and see the result below:
|
|
|
17
17
|
|
|
18
18
|
###
|
|
19
19
|
|
|
20
|
-
|
|
20
|
+
|
|
21
21
|
|
|
22
22
|
## Explanation
|
|
23
23
|
|
|
@@ -33,6 +33,9 @@ Other information about the calculation etc.
|
|
|
33
33
|
|
|
34
34
|
Here you can see some summary and average for each date in the data set. Hover over the column title for explanation.
|
|
35
35
|
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
|
|
36
39
|
### Hours
|
|
37
40
|
|
|
38
41
|
Here is your dta represented per hour, as well as potential savings calculated by the tool. Negative numbers are hidden, but you can select to show them.
|
|
@@ -47,6 +50,8 @@ There are the same number of columns as you have configured as `Max in sequence`
|
|
|
47
50
|
The cells show how much you will save per hWh by turning that hour off for `x` hours,
|
|
48
51
|
starting at that hour. It is the difference between the price at that hour and the price x hours later. Click on a cell to see the cells used in the calculation.
|
|
49
52
|
|
|
53
|
+
|
|
54
|
+
|
|
50
55
|
#### Saving for sequence of x hours
|
|
51
56
|
|
|
52
57
|
These cells show how much you can save per kWh in average per hour by turning off a sequence of x hours starting at that hour. Click on a cell to see the cells used in the calculation.
|
|
@@ -59,7 +64,7 @@ If the number is black, it could be used, but only if all other criteria are sat
|
|
|
59
64
|
|
|
60
65
|
###
|
|
61
66
|
|
|
62
|
-
|
|
67
|
+
|
|
63
68
|
|
|
64
69
|
## Something seems wrong
|
|
65
70
|
|
package/docs/guide/README.md
CHANGED
|
@@ -8,6 +8,8 @@ sidebar: "auto"
|
|
|
8
8
|
|
|
9
9
|
This is a collection of nodes for the popular [Node-RED](https://nodered.org/) that you can use to save money on variable electricity prices. Node-RED is a widely used low-code programming tool that can be used together with many smart home solutions to create automations.
|
|
10
10
|
|
|
11
|
+
|
|
12
|
+
|
|
11
13
|
The solution can be used to control switches or other entities in a smart home system, and for example turn on when the price is low, and turn off when the price is high.
|
|
12
14
|
There are different ways to calculate what hours to turn on and off, and these are implemented as **strategy nodes**. Each strategy node can be configured to fit different purposes.
|
|
13
15
|
|
|
@@ -19,6 +21,8 @@ Tibber and Nord Pool are only available in the nordics, so if you live outside t
|
|
|
19
21
|
|
|
20
22
|
Grid tariff is normally not part of the electricity price, so if this varies by the hour, it must be added before sent to the strategy nodes for calculation. This can be done by putting a `ps-xxx-add-tariff` node between the price receiver and the strategy.
|
|
21
23
|
|
|
24
|
+
|
|
25
|
+
|
|
22
26
|
The strategy nodes have 3 outputs. Output 1 is used to "turn on", output 2 is used to "turn off", and on output 3, the calculated schedule and some other information is sent. You can use this to make graphs, or just send it to a debug node to view it.
|
|
23
27
|
|
|
24
28
|
Example:
|
|
@@ -33,7 +37,7 @@ The node collection fits very well with Home Assistant (HA), as Node-RED is freq
|
|
|
33
37
|
|
|
34
38
|
###
|
|
35
39
|
|
|
36
|
-
|
|
40
|
+
|
|
37
41
|
|
|
38
42
|
## Getting started
|
|
39
43
|
|
|
@@ -47,6 +51,8 @@ May also be installed via npm:
|
|
|
47
51
|
|
|
48
52
|
Make sure that you upgrade now and then to get the latest version. See [changelog](../changelog/README.md) for changes.
|
|
49
53
|
|
|
54
|
+
|
|
55
|
+
|
|
50
56
|
### Get price data
|
|
51
57
|
|
|
52
58
|
This solution is useless without price data. In the nordics, there are at least two very common places to get price data from:
|
|
@@ -116,6 +122,8 @@ If you are a Tibber customer, use the `tibber-query` node from the [Tibber API](
|
|
|
116
122
|
|
|
117
123
|
See more details in the [documentation](../nodes/ps-receive-price#tibber-input) for the `ps-receive-price` node.
|
|
118
124
|
|
|
125
|
+
|
|
126
|
+
|
|
119
127
|
Se documentation for [node-red-contrib-tibber-api](https://flows.nodered.org/node/node-red-contrib-tibber-api) for details about the Tibber query.
|
|
120
128
|
|
|
121
129
|
::: tip Tibber query
|
|
@@ -135,7 +143,7 @@ Data can be sent from both the `current state` node or the `events: state` node.
|
|
|
135
143
|
|
|
136
144
|
###
|
|
137
145
|
|
|
138
|
-
|
|
146
|
+
|
|
139
147
|
|
|
140
148
|
### Add grid tariff
|
|
141
149
|
|
|
@@ -154,6 +162,8 @@ If your grid is not supported, you may code this yourself.
|
|
|
154
162
|
If the grid tariff is the same the whole day, you can skip this step i the flow.
|
|
155
163
|
:::
|
|
156
164
|
|
|
165
|
+
|
|
166
|
+
|
|
157
167
|
### Calculate and run schedule
|
|
158
168
|
|
|
159
169
|
This is the step where the value is produced. Based on the prices received, the optimal schedule for you is calculated automatically, based on your configuration. You can choose between the following strategies:
|
|
@@ -177,6 +187,8 @@ Choose the lowest price strategy if you need the power to be on for x hours, but
|
|
|
177
187
|
Choose the heat capacitor strategy for controlling for example room heating, where you can turn the heat a little down when electricity is expensive, and a little up when it is cheap, using trading principles (only that you know up front when the prices will change).
|
|
178
188
|
:::
|
|
179
189
|
|
|
190
|
+
|
|
191
|
+
|
|
180
192
|
### Use schedule signals
|
|
181
193
|
|
|
182
194
|
Use the outputs to control switches, thermostats or other entities to control your power consumers.
|
|
@@ -202,7 +214,7 @@ There are many ways you can use the output:
|
|
|
202
214
|
|
|
203
215
|
###
|
|
204
216
|
|
|
205
|
-
|
|
217
|
+
|
|
206
218
|
|
|
207
219
|
### Display schedule
|
|
208
220
|
|
|
@@ -228,7 +240,7 @@ There are more details and more information in the documentation for each [node]
|
|
|
228
240
|
|
|
229
241
|
###
|
|
230
242
|
|
|
231
|
-
|
|
243
|
+
|
|
232
244
|
|
|
233
245
|
## Migration from v2
|
|
234
246
|
|
|
@@ -239,6 +251,8 @@ You may directly replace the `Power Saver` node by two of the new nodes (`ps-rec
|
|
|
239
251
|
|
|
240
252
|
See more details in the [documentation for the `ps-strategy-best-save`](../nodes/ps-strategy-best-save.md) node.
|
|
241
253
|
|
|
254
|
+
|
|
255
|
+
|
|
242
256
|
## Disclaimer
|
|
243
257
|
|
|
244
258
|
This software is offered for free as open source. You use it totally on your own risk. The developers take no responsibility of any consequences caused by use or misuse of this software.
|
package/docs/nodes/README.md
CHANGED
|
@@ -1,4 +1,3 @@
|
|
|
1
|
-
<AdsenseAdd type="øverst"/>
|
|
2
1
|
|
|
3
2
|
# Nodes
|
|
4
3
|
|
|
@@ -6,7 +5,7 @@ Here is an overview of the nodes, and links to detailed descriptions for eah of
|
|
|
6
5
|
|
|
7
6
|
###
|
|
8
7
|
|
|
9
|
-
|
|
8
|
+
|
|
10
9
|
|
|
11
10
|
## Strategy nodes
|
|
12
11
|
|
|
@@ -38,7 +37,7 @@ A strategy for setting a fixed daily or weekly schedule.
|
|
|
38
37
|
|
|
39
38
|
###
|
|
40
39
|
|
|
41
|
-
|
|
40
|
+
|
|
42
41
|
|
|
43
42
|
## Utility nodes
|
|
44
43
|
|
|
@@ -54,6 +53,8 @@ Node to convert different types of input data to the format used by the strategy
|
|
|
54
53
|
|
|
55
54
|
Node to combine multiple schedules into one schedule.
|
|
56
55
|
|
|
56
|
+
|
|
57
|
+
|
|
57
58
|
## Grid tariff nodes
|
|
58
59
|
|
|
59
60
|
### [ps-general-add-tariff](./ps-general-add-tariff)
|
|
@@ -68,6 +69,8 @@ Node to add a variable grid tariff (or any value) to the prices before sending t
|
|
|
68
69
|
|
|
69
70
|
Node to add Elvia grid tariff to the prices before sending them to the strategy nodes.
|
|
70
71
|
|
|
72
|
+
|
|
73
|
+
|
|
71
74
|
## Other nodes
|
|
72
75
|
|
|
73
76
|
These are a couple of other nodes for using the Elvia API, but these are not important to the Power Saver, so they are not given any further documentation here.
|
|
@@ -82,4 +85,4 @@ Use this to get the Elvia grid tariff for a selected tariff type.
|
|
|
82
85
|
|
|
83
86
|
###
|
|
84
87
|
|
|
85
|
-
|
|
88
|
+
|
|
@@ -1,6 +1,3 @@
|
|
|
1
|
-
###
|
|
2
|
-
|
|
3
|
-
<AdsenseAdd type="øverst"/>
|
|
4
1
|
|
|
5
2
|
# Dynamic commands
|
|
6
3
|
|
|
@@ -13,6 +10,8 @@ This applies to the following nodes:
|
|
|
13
10
|
|
|
14
11
|
Commands can be sent together with config or price data. You can command multiple commands in one message, but then put them all in the same commands-object.
|
|
15
12
|
|
|
13
|
+
|
|
14
|
+
|
|
16
15
|
## Commands
|
|
17
16
|
|
|
18
17
|
### sendSchedule
|
|
@@ -45,7 +44,7 @@ When you do this, the current schedule is actually recalculated based on the las
|
|
|
45
44
|
|
|
46
45
|
###
|
|
47
46
|
|
|
48
|
-
|
|
47
|
+
|
|
49
48
|
|
|
50
49
|
### reset
|
|
51
50
|
|
|
@@ -70,6 +69,8 @@ This operation cannot be undone.
|
|
|
70
69
|
However, it is normally not a big loss, as you can just feed the node with new price data and start from scratch.
|
|
71
70
|
:::
|
|
72
71
|
|
|
72
|
+
|
|
73
|
+
|
|
73
74
|
### replan
|
|
74
75
|
|
|
75
76
|
By sending this command, you can have the node read the last received prices from the context storage,
|
|
@@ -88,4 +89,4 @@ instead of fetching prices again.
|
|
|
88
89
|
|
|
89
90
|
###
|
|
90
91
|
|
|
91
|
-
|
|
92
|
+
|
|
@@ -8,6 +8,8 @@ This applies to the following nodes:
|
|
|
8
8
|
- Heat Capacitor
|
|
9
9
|
- Schedule Merger
|
|
10
10
|
|
|
11
|
+
|
|
12
|
+
|
|
11
13
|
Dynamic config is sent on the input as a message with a payload containing a `config` object and optionally a `name`.
|
|
12
14
|
Example:
|
|
13
15
|
|
|
@@ -33,7 +35,7 @@ The `name` is the exact same value as you set as name in the nodes config.
|
|
|
33
35
|
|
|
34
36
|
###
|
|
35
37
|
|
|
36
|
-
|
|
38
|
+
|
|
37
39
|
|
|
38
40
|
## Output values
|
|
39
41
|
|
|
@@ -47,6 +49,8 @@ When a config is sent like this, and without price data, the schedule will be re
|
|
|
47
49
|
|
|
48
50
|
However, you can send config and price data in the same message. Then both will be used.
|
|
49
51
|
|
|
52
|
+
|
|
53
|
+
|
|
50
54
|
## Override
|
|
51
55
|
|
|
52
56
|
It is possible to send an override message to a strategy node (Best Save or Lowest Price) and to the Schedule Merger node.
|
|
@@ -72,6 +76,8 @@ Legal values for override are:
|
|
|
72
76
|
| `"off"` | The node will only send output `off` |
|
|
73
77
|
| `"auto"` | The node will work according to the schedule. This is the standard and the default mode. |
|
|
74
78
|
|
|
79
|
+
|
|
80
|
+
|
|
75
81
|
## Config saved in context
|
|
76
82
|
|
|
77
83
|
The nodes config is saved in the nodes context.
|
|
@@ -81,4 +87,4 @@ When Node-RED starts or the flow is redeployed, the config defined in the node r
|
|
|
81
87
|
|
|
82
88
|
###
|
|
83
89
|
|
|
84
|
-
|
|
90
|
+
|
|
@@ -1,5 +1,7 @@
|
|
|
1
1
|
# node-red-contrib-power-saver v2 (deprecated)
|
|
2
2
|
|
|
3
|
+
|
|
4
|
+
|
|
3
5
|
A Node-RED node to save money when power prices are changing. Saving is done by postponing power consumption until the price is lower.
|
|
4
6
|
|
|
5
7
|
You can configure maximum number of hours to save in a sequence, and minimum time to recover after a maximum saving period.
|
|
@@ -20,6 +22,8 @@ This node is currently rather new, and has been tried for a few weeks, enough to
|
|
|
20
22
|
|
|
21
23
|
Feel free to try it, and report back problems or ideas as [Github issues](https://github.com/ottopaulsen/node-red-contrib-power-saver/issues).
|
|
22
24
|
|
|
25
|
+
|
|
26
|
+
|
|
23
27
|
## Installation
|
|
24
28
|
|
|
25
29
|
Install in Node-RED via the Manage Palette menu.
|
|
@@ -30,6 +34,8 @@ May also be installed via npm:
|
|
|
30
34
|
|
|
31
35
|
Make sure that you upgrade now and then to get the latest version. See [changelog](CHANGELOG) for changes.
|
|
32
36
|
|
|
37
|
+
|
|
38
|
+
|
|
33
39
|
## Input
|
|
34
40
|
|
|
35
41
|
3 different types of input are accepted:
|
|
@@ -42,6 +48,8 @@ Choose the one that fits you best. Of course, all inputs are JSON, but the Tibbe
|
|
|
42
48
|
|
|
43
49
|
From version 2.1.0, you can also send a config object as input for dynamically changing the node config.
|
|
44
50
|
|
|
51
|
+
|
|
52
|
+
|
|
45
53
|
### Tibber input
|
|
46
54
|
|
|
47
55
|
If you are a Tibber customer, you can use the `tibber-query` node from the [`node-red-contrib-tibber-api` node](https://flows.nodered.org/node/node-red-contrib-tibber-api). Set it up with the following query:
|
|
@@ -71,6 +79,8 @@ Send the result from the `tibber-query` node with the query above directly to th
|
|
|
71
79
|
|
|
72
80
|
[See example with Tibber, a switch and MQTT](doc/example-tibber-mqtt.md)
|
|
73
81
|
|
|
82
|
+
|
|
83
|
+
|
|
74
84
|
### Nordpool input
|
|
75
85
|
|
|
76
86
|
This is especially designed to work for Home Assistant (HA), and the [Nord Pool custom component](https://github.com/custom-components/nordpool). The Nord Pool component provides a _sensor_ that gives price per hour for today and tomorrow (after 13:00). Send the output from this sensor directly to the `power-saver` node. Make sure this is done whenever the node is updated, as well as when the system starts up.
|
|
@@ -81,6 +91,8 @@ Data can be sent from both the `current state` node or the `events: state` node.
|
|
|
81
91
|
|
|
82
92
|
[See example with Nord Pool and `events: state` node](doc/example-nordpool-events-state.md)
|
|
83
93
|
|
|
94
|
+
|
|
95
|
+
|
|
84
96
|
### Other input
|
|
85
97
|
|
|
86
98
|
If you cannot use any of the two above (Tibber or Nord Pool), create the input to the node with the payload containing JSON like this:
|
|
@@ -100,6 +112,8 @@ If you cannot use any of the two above (Tibber or Nord Pool), create the input t
|
|
|
100
112
|
}
|
|
101
113
|
```
|
|
102
114
|
|
|
115
|
+
|
|
116
|
+
|
|
103
117
|
## Output
|
|
104
118
|
|
|
105
119
|
### Output 1
|
|
@@ -114,6 +128,8 @@ A payload with the word `false` is sent to output 2 whenever the power / switch
|
|
|
114
128
|
|
|
115
129
|
When a valid input is received, and the schedule is recalculated, the resulting schedule, as well as some other information, is sent to output 3. You can use this to see the plan and verify that it meets your expectations. You can also use it to display the schedule in any way you like.
|
|
116
130
|
|
|
131
|
+
|
|
132
|
+
|
|
117
133
|
Example of output:
|
|
118
134
|
|
|
119
135
|
```json
|
|
@@ -163,6 +179,8 @@ Example of output:
|
|
|
163
179
|
|
|
164
180
|
The `schedule` array shows every time the switch is turned on or off. The `hours` array shows values per hour containing the price (received as input), whether that hour is on or off, the start time of the hour and the amount per kWh that is saved on hours that are turned off, compared to the next hour that is on.
|
|
165
181
|
|
|
182
|
+
|
|
183
|
+
|
|
166
184
|
## Configuration
|
|
167
185
|
|
|
168
186
|
Currently there is only one strategy for saving. This is the _mostSaved_ strategy. This strategy turns off the hours where the price difference is largest compared to the next hour that is on. The idea is that the power you are not using when the switch is turned off, will be used immediately when the switch is turned on. This would fit well for turning of a water heater or another thermostat controlled heater.
|
|
@@ -175,6 +193,8 @@ You can configure the following:
|
|
|
175
193
|
- Wether to send on/off just after a reschedule is done without waiting until the next scheduled switch.
|
|
176
194
|
- What to do if there is no valid schedule any more (turn on or off).
|
|
177
195
|
|
|
196
|
+
|
|
197
|
+
|
|
178
198
|
### Dynamic config
|
|
179
199
|
|
|
180
200
|
It is possible to change config dynamically by sending a config message to the node. The config messages has a payload with a config object like this example:
|
|
@@ -198,6 +218,8 @@ The config sent like this will be valid until a new config is sent the same way,
|
|
|
198
218
|
|
|
199
219
|
When a config is sent like this, the schedule will be replanned based on the last previously received price data. If no price data has been received, no scheduling is done.
|
|
200
220
|
|
|
221
|
+
|
|
222
|
+
|
|
201
223
|
## Algorithm
|
|
202
224
|
|
|
203
225
|
The calculation that decides what hours to turn off works as follows:
|
|
@@ -212,6 +234,8 @@ The calculation that decides what hours to turn off works as follows:
|
|
|
212
234
|
|
|
213
235
|
I say "in most cases", because there is a chance that a group of two or more sequences combined can give a better plan than a single sequence preceeding those two, but where the selection of the one sequence causes the group to be discarded. If anyone encounters this situation, I would be happy to receive the price data set, and try to improve the algorithm even further.
|
|
214
236
|
|
|
237
|
+
|
|
238
|
+
|
|
215
239
|
## Integration with MagicMirror
|
|
216
240
|
|
|
217
241
|
Are you using [MagicMirror](https://magicmirror.builders/)? Are you also using [Tibber](https://tibber.com/)? If so, there is a module for MM called [MMM-Tibber](https://github.com/ottopaulsen/MMM-Tibber), that easily can be used to show savings from this node.
|
|
@@ -222,6 +246,8 @@ The purple lines show savings per kWh.
|
|
|
222
246
|
|
|
223
247
|
Read more about this in the [MMM-Tibber documentation](https://github.com/ottopaulsen/MMM-Tibber#show-savings).
|
|
224
248
|
|
|
249
|
+
|
|
250
|
+
|
|
225
251
|
## Change Log
|
|
226
252
|
|
|
227
253
|
See [CHANGELOG.md](CHANGELOG.md)
|
|
@@ -232,4 +258,4 @@ Contributions are welcome. Please start by creating a Github Issue with suggeste
|
|
|
232
258
|
|
|
233
259
|
###
|
|
234
260
|
|
|
235
|
-
|
|
261
|
+
|
|
@@ -14,7 +14,7 @@ You need an Elvia API subscription key to use this node. See [configuration](#el
|
|
|
14
14
|
|
|
15
15
|
###
|
|
16
16
|
|
|
17
|
-
|
|
17
|
+
|
|
18
18
|
|
|
19
19
|
## Description
|
|
20
20
|
|
|
@@ -22,6 +22,8 @@ When grid tariff changes from hour to hour, this should normally also be conside
|
|
|
22
22
|
|
|
23
23
|

|
|
24
24
|
|
|
25
|
+
|
|
26
|
+
|
|
25
27
|
## Configuration
|
|
26
28
|
|
|
27
29
|
::: warning Elvia API subscription key
|
|
@@ -36,6 +38,8 @@ The first time you use this node, you must create a `ps-elvia-config` entry. Cli
|
|
|
36
38
|
|
|
37
39
|

|
|
38
40
|
|
|
41
|
+
|
|
42
|
+
|
|
39
43
|
Then enter the Elvia API subscription key:
|
|
40
44
|
|
|
41
45
|

|
|
@@ -53,7 +57,7 @@ The next time you use this node, you can select the same config as you created t
|
|
|
53
57
|
|
|
54
58
|
###
|
|
55
59
|
|
|
56
|
-
|
|
60
|
+
|
|
57
61
|
|
|
58
62
|
## Input
|
|
59
63
|
|
|
@@ -65,4 +69,4 @@ The output is the [common strategy input format](./strategy-input.md)
|
|
|
65
69
|
|
|
66
70
|
###
|
|
67
71
|
|
|
68
|
-
|
|
72
|
+
|
|
@@ -11,7 +11,7 @@ Node to add a value, for example a variable grid tariff, to the price before it
|
|
|
11
11
|
|
|
12
12
|
###
|
|
13
13
|
|
|
14
|
-
|
|
14
|
+
|
|
15
15
|
|
|
16
16
|
## Description
|
|
17
17
|
|
|
@@ -26,6 +26,8 @@ When using two nodes in series to support for example different rates for weeken
|
|
|
26
26
|
make sure each day is handled by only one node, else both nodes will add to the price.
|
|
27
27
|
:::
|
|
28
28
|
|
|
29
|
+
|
|
30
|
+
|
|
29
31
|
Here is how this node is normally used:
|
|
30
32
|
|
|
31
33
|

|
|
@@ -36,6 +38,8 @@ If there is one price now, and another price from a specific date, you can use t
|
|
|
36
38
|
|
|
37
39
|
## Configuration
|
|
38
40
|
|
|
41
|
+
|
|
42
|
+
|
|
39
43
|
### Add and delete periods
|
|
40
44
|
|
|
41
45
|
You can have from 1 to 24 periods during the day, with different values to add for each hour. Click the `Add period` button to add more periods. Click the `X` button to delete a period.
|
|
@@ -49,6 +53,8 @@ Be careful to use the correct unit when entering the price here. If the price is
|
|
|
49
53
|
If the price is `36 cents` enter `0.36`.
|
|
50
54
|
:::
|
|
51
55
|
|
|
56
|
+
|
|
57
|
+
|
|
52
58
|
### Days
|
|
53
59
|
|
|
54
60
|
Check which days the price is valid for. For the price to be added, both the time and the day must be correct.
|
|
@@ -70,7 +76,7 @@ If this is empty, the config is valid until forever.
|
|
|
70
76
|
|
|
71
77
|
###
|
|
72
78
|
|
|
73
|
-
|
|
79
|
+
|
|
74
80
|
|
|
75
81
|
## Input
|
|
76
82
|
|
|
@@ -84,4 +90,4 @@ If there is a config property in the input payload, it is passed on to the outpu
|
|
|
84
90
|
|
|
85
91
|
###
|
|
86
92
|
|
|
87
|
-
|
|
93
|
+
|
|
@@ -7,6 +7,8 @@ next: ./ps-schedule-merger.md
|
|
|
7
7
|
|
|
8
8
|

|
|
9
9
|
|
|
10
|
+
|
|
11
|
+
|
|
10
12
|
## Description
|
|
11
13
|
|
|
12
14
|
The `ps-receive-price` node is used to convert prices from Tibber or Nord Pool to the format used by the strategy nodes. It takes its input directly from the output of the following nodes (see details below):
|
|
@@ -29,7 +31,7 @@ There is no configuration except from node name.
|
|
|
29
31
|
|
|
30
32
|
###
|
|
31
33
|
|
|
32
|
-
|
|
34
|
+
|
|
33
35
|
|
|
34
36
|
## Input
|
|
35
37
|
|
|
@@ -58,6 +60,8 @@ If you are a Tibber customer, you can use the `tibber-query` node from the [`nod
|
|
|
58
60
|
}
|
|
59
61
|
```
|
|
60
62
|
|
|
63
|
+
|
|
64
|
+
|
|
61
65
|
Send the result from the `tibber-query` node with the query above directly to the `ps-receive-price` node. Make sure it is refreshed when new prices are ready. Prices for the next day are normally ready at 13:00, but refreshing every hour can be a good idea.
|
|
62
66
|
|
|
63
67
|
[See example with Tibber, a switch and MQTT](../examples/example-tibber-mqtt.md)
|
|
@@ -92,6 +96,8 @@ Go to the [Tibber Developer pages](https://developer.tibber.com/), sign in, and
|
|
|
92
96
|
}
|
|
93
97
|
```
|
|
94
98
|
|
|
99
|
+
|
|
100
|
+
|
|
95
101
|
Then copy the `id` of the house you want to use prices for. It may look like this:
|
|
96
102
|
|
|
97
103
|
```
|
|
@@ -126,7 +132,7 @@ This is the query you shall put in the `tibber-query` node.
|
|
|
126
132
|
|
|
127
133
|
###
|
|
128
134
|
|
|
129
|
-
|
|
135
|
+
|
|
130
136
|
|
|
131
137
|
### Nord Pool input
|
|
132
138
|
|
|
@@ -142,6 +148,8 @@ When using the `current state` node, configure the output properties to set `msg
|
|
|
142
148
|
|
|
143
149
|
[See example with Nord Pool and `events: state` node](../examples/example-nordpool-events-state.md)
|
|
144
150
|
|
|
151
|
+
|
|
152
|
+
|
|
145
153
|
### Other input
|
|
146
154
|
|
|
147
155
|
If you cannot use any of the two above (Tibber or Nord Pool), create the input to the node with the payload containing JSON like this:
|
|
@@ -161,10 +169,12 @@ If you cannot use any of the two above (Tibber or Nord Pool), create the input t
|
|
|
161
169
|
}
|
|
162
170
|
```
|
|
163
171
|
|
|
172
|
+
|
|
173
|
+
|
|
164
174
|
## Output
|
|
165
175
|
|
|
166
176
|
The output is the [common strategy input format](./strategy-input.md), so it can be sent directly to the strategy nodes, or via any `ps-xxx-add-tariff` node.
|
|
167
177
|
|
|
168
178
|
###
|
|
169
179
|
|
|
170
|
-
|
|
180
|
+
|
|
@@ -7,6 +7,8 @@ next: ./ps-general-add-tariff.md
|
|
|
7
7
|
|
|
8
8
|

|
|
9
9
|
|
|
10
|
+
|
|
11
|
+
|
|
10
12
|
## Description
|
|
11
13
|
|
|
12
14
|
This node can be used to merge schedules from multiple strategy nodes, and create one resulting schedule. It can be useful for example to have multiple lowest price nodes to cover different periods of the day. Send all schedules as input to this node and get one schedule as output. It works for schedules from Lowest Price, Best Save and Fixed Schedule.
|
|
@@ -21,6 +23,8 @@ The schedules that are merged must be for the exact same period and have the exa
|
|
|
21
23
|
If a schedule with prices for a different period is received, all saved schedules are deleted, and not used any more.
|
|
22
24
|
:::
|
|
23
25
|
|
|
26
|
+
|
|
27
|
+
|
|
24
28
|
The merge can be done using one of two functions:
|
|
25
29
|
|
|
26
30
|
- OR
|
|
@@ -42,6 +46,8 @@ sure the switch is turned on or off, and then merge the schedule from the Fixed
|
|
|
42
46
|
the schedule from for example the Lowest Price node, using the Schedule Merger node.
|
|
43
47
|
:::
|
|
44
48
|
|
|
49
|
+
|
|
50
|
+
|
|
45
51
|
## Configuration
|
|
46
52
|
|
|
47
53
|

|
|
@@ -57,7 +63,7 @@ the schedule from for example the Lowest Price node, using the Schedule Merger n
|
|
|
57
63
|
|
|
58
64
|
###
|
|
59
65
|
|
|
60
|
-
|
|
66
|
+
|
|
61
67
|
|
|
62
68
|
### Dynamic config
|
|
63
69
|
|
|
@@ -77,6 +83,8 @@ The following config values can be changed dynamically:
|
|
|
77
83
|
|
|
78
84
|
See [Dynamic Config](./dynamic-config.md) for details and how to send dynamic config.
|
|
79
85
|
|
|
86
|
+
|
|
87
|
+
|
|
80
88
|
### Dynamic commands
|
|
81
89
|
|
|
82
90
|
You can send dynamic commands to this node, for example to make it resend output.
|
|
@@ -113,6 +121,8 @@ You can make your own input by supplying a payload containing an hours array. Ex
|
|
|
113
121
|
}
|
|
114
122
|
```
|
|
115
123
|
|
|
124
|
+
|
|
125
|
+
|
|
116
126
|
## Output
|
|
117
127
|
|
|
118
128
|
There are three outputs. You use only those you need for your purpose.
|
|
@@ -129,6 +139,8 @@ A payload with the value set in config, default `false`, is sent to output 2 whe
|
|
|
129
139
|
|
|
130
140
|
When valid input is received, and the schedule is recalculated (after the timeout), the resulting schedule, as well as some other information, is sent to output 3. You can use this to see the plan and verify that it meets your expectations. You can also use it to display the schedule in any way you like.
|
|
131
141
|
|
|
142
|
+
|
|
143
|
+
|
|
132
144
|
Example of output:
|
|
133
145
|
|
|
134
146
|
```json
|
|
@@ -215,12 +227,16 @@ Example of output:
|
|
|
215
227
|
|
|
216
228
|
The `schedule` array shows every time the switch is turned on or off. The `hours` array shows values per hour containing the price (received as input), whether that hour is on or off and the start time of the hour. The `saving` value is always `null`.
|
|
217
229
|
|
|
230
|
+
|
|
231
|
+
|
|
218
232
|
## Usage ideas
|
|
219
233
|
|
|
220
234
|
### Multiple Lowest Price
|
|
221
235
|
|
|
222
236
|
If you want a switch to be on for example two of the cheapest hours between 00:00 and 08:00, and then the two cheapest hours between 12:00 and 20:00, you can do this by combining the schedule from two Lowest Price nodes, one for each of the mentioned periods. Merge the two using a Schedule Merger node with the `OR` function. Make sure to send `off` if no schedule for all nodes.
|
|
223
237
|
|
|
238
|
+
|
|
239
|
+
|
|
224
240
|
### Day-filter for strategy nodes
|
|
225
241
|
|
|
226
242
|
If you have a strategy node, for example Lowest Price or Best Save, that you want to have effect only on weekdays,
|
|
@@ -8,6 +8,8 @@ next: ./ps-strategy-lowest-price.md
|
|
|
8
8
|
|
|
9
9
|
Strategy node to postpone power consumption until the price is lower.
|
|
10
10
|
|
|
11
|
+
|
|
12
|
+
|
|
11
13
|
## Description
|
|
12
14
|
|
|
13
15
|
This strategy turns off the hours where the price difference is largest compared to the next hour that is on. The idea is that the power you are not using when the switch is turned off, will be used immediately when the switch is turned on (during the first hour). This would fit well for turning off a water heater or another thermostat controlled heater.
|
|
@@ -18,6 +20,8 @@ Be aware that the norwegian [FHI](https://www.fhi.no/nettpub/legionellaveiledere
|
|
|
18
20
|
|
|
19
21
|
The picture at the bottom of the page, under [Integration with MagicMirror](#integration-with-magicmirror), illustrates this by the purple strokes, taking the price from the top of the price curve to the level of the first hour after the save-period.
|
|
20
22
|
|
|
23
|
+
|
|
24
|
+
|
|
21
25
|
## Configuration
|
|
22
26
|
|
|
23
27
|

|
|
@@ -39,7 +43,7 @@ NB! The `Min recover` only has effect if the previous save-period is of length `
|
|
|
39
43
|
|
|
40
44
|
###
|
|
41
45
|
|
|
42
|
-
|
|
46
|
+
|
|
43
47
|
|
|
44
48
|
### Dynamic config
|
|
45
49
|
|
|
@@ -61,6 +65,8 @@ The following config values can be changed dynamically:
|
|
|
61
65
|
|
|
62
66
|
See [Dynamic Config](./dynamic-config.md) for details and how to send dynamic config.
|
|
63
67
|
|
|
68
|
+
|
|
69
|
+
|
|
64
70
|
### Dynamic commands
|
|
65
71
|
|
|
66
72
|
You can send dynamic commands to this node, for example to make it resend output.
|
|
@@ -79,6 +85,8 @@ When a payload with `priceData` is received, this is saved to the nodes context
|
|
|
79
85
|
The source is saved as `lastSource`. If config- or command-messages are received without price data,
|
|
80
86
|
the data saved in context is used for replanning.
|
|
81
87
|
|
|
88
|
+
|
|
89
|
+
|
|
82
90
|
## Output
|
|
83
91
|
|
|
84
92
|
There are three outputs. You use only those you need for your purpose.
|
|
@@ -91,13 +99,15 @@ A payload with the value set in config, default `true`, is sent to output 1 when
|
|
|
91
99
|
|
|
92
100
|
A payload with the value set in config, default `false` is sent to output 2 whenever the power / switch shall be turned off.
|
|
93
101
|
|
|
102
|
+
|
|
103
|
+
|
|
94
104
|
### Output 3
|
|
95
105
|
|
|
96
106
|
When a valid input is received, and the schedule is recalculated, the resulting schedule, as well as some other information, is sent to output 3. You can use this to see the plan and verify that it meets your expectations. You can also use it to display the schedule in any way you like.
|
|
97
107
|
|
|
98
108
|
###
|
|
99
109
|
|
|
100
|
-
|
|
110
|
+
|
|
101
111
|
|
|
102
112
|
Example of output:
|
|
103
113
|
|
|
@@ -157,6 +167,8 @@ Example of output:
|
|
|
157
167
|
|
|
158
168
|
The `schedule` array shows every time the switch is turned on or off. The `hours` array shows values per hour containing the price (received as input), whether that hour is on or off, the start time of the hour and the amount per kWh that is saved on hours that are turned off, compared to the next hour that is on.
|
|
159
169
|
|
|
170
|
+
|
|
171
|
+
|
|
160
172
|
### Output saved in context
|
|
161
173
|
|
|
162
174
|
The `schedule` and the `hours` arrays from Output 3 are both saved to the nodes context in an object with key `lastPlan`. This may be used in the plan for the next day, for example if an off-period at the end of one day continues into the next day. In that case, the `saving` values for the last hours in the day have to be recalculated, since the next hour on is changed when the new day is calculated.
|
|
@@ -165,7 +177,7 @@ You can see the saved data if you select the node in Node-RED, and view "Context
|
|
|
165
177
|
|
|
166
178
|
###
|
|
167
179
|
|
|
168
|
-
|
|
180
|
+
|
|
169
181
|
|
|
170
182
|
## Algorithm
|
|
171
183
|
|
|
@@ -181,6 +193,8 @@ The calculation that decides what hours to turn off works as follows:
|
|
|
181
193
|
|
|
182
194
|
I say "in most cases", because there is a chance that a group of two or more sequences combined can give a better plan than a single sequence preceeding those two, but where the selection of the one sequence causes the group to be discarded. If anyone encounters this situation, I would be happy to receive the price data set, and try to improve the algorithm even further.
|
|
183
195
|
|
|
196
|
+
|
|
197
|
+
|
|
184
198
|
## Data used for calculation
|
|
185
199
|
|
|
186
200
|
Normally data is received for one or two whole days, and all this data is used to do the calculation. In addition, if the node has run before, so there is historical data, the last period on or off before the period data is received for, is considered in the calculation, so that the rules in the configuration are followed also between days.
|
|
@@ -195,6 +209,8 @@ It is common to have two different context storages defined, `memory` and `file`
|
|
|
195
209
|
It is also common to have a `default` context storage defined, and often this points to either `memory` or `file`.
|
|
196
210
|
However, the configuration can be different from this.
|
|
197
211
|
|
|
212
|
+
|
|
213
|
+
|
|
198
214
|
You can find this configuration in the `settings.js` file for Node-RED, usually in the node-red config folder.
|
|
199
215
|
In Home Assistant, this is normally `/config/node-red/settings.js`.
|
|
200
216
|
|
|
@@ -213,6 +229,8 @@ Please read the [Node-RED documentation](https://nodered.org/docs/user-guide/con
|
|
|
213
229
|
|
|
214
230
|
The data that is saved is the config, the last used prices and the last calculated schedule.
|
|
215
231
|
|
|
232
|
+
|
|
233
|
+
|
|
216
234
|
When Node-RED restarts, the config is reset to what is defined in the node config, so by default,
|
|
217
235
|
nothing is read from the context storage after a restart. However, if you send a `replan` command to the
|
|
218
236
|
nodes input, a plan is recalculated, using the last received prices. One way to do this is to use an `inject` node,
|
|
@@ -230,7 +248,7 @@ This is an alternative to fetching new prices and send as input.
|
|
|
230
248
|
|
|
231
249
|
###
|
|
232
250
|
|
|
233
|
-
|
|
251
|
+
|
|
234
252
|
|
|
235
253
|
## Integration with MagicMirror
|
|
236
254
|
|
|
@@ -248,4 +266,4 @@ If you like to analyze the data output by the node, take a look at the [Best Sav
|
|
|
248
266
|
|
|
249
267
|
###
|
|
250
268
|
|
|
251
|
-
|
|
269
|
+
|
|
@@ -11,6 +11,8 @@ Strategy node to set a fixed schedule.
|
|
|
11
11
|
This can be used by itself, but it is also perfect to combine with other strategies
|
|
12
12
|
and the [Schedule Merger](./ps-schedule-merger.md) node in order to force periods of the day either on or off.
|
|
13
13
|
|
|
14
|
+
|
|
15
|
+
|
|
14
16
|
## Description
|
|
15
17
|
|
|
16
18
|
This strategy can be used to set a period of the day or the week fixed to on or off.
|
|
@@ -23,6 +25,8 @@ Here is an example of how to combine it with the Lowest Price node:
|
|
|
23
25
|
|
|
24
26
|

|
|
25
27
|
|
|
28
|
+
|
|
29
|
+
|
|
26
30
|
## Configuration
|
|
27
31
|
|
|
28
32
|

|
|
@@ -41,7 +45,7 @@ Here is an example of how to combine it with the Lowest Price node:
|
|
|
41
45
|
|
|
42
46
|
###
|
|
43
47
|
|
|
44
|
-
|
|
48
|
+
|
|
45
49
|
|
|
46
50
|
### Dynamic config
|
|
47
51
|
|
|
@@ -64,6 +68,8 @@ The following config values can be changed dynamically:
|
|
|
64
68
|
|
|
65
69
|
See [Dynamic Config](./dynamic-config.md) for details and how to send dynamic config.
|
|
66
70
|
|
|
71
|
+
|
|
72
|
+
|
|
67
73
|
### Dynamic commands
|
|
68
74
|
|
|
69
75
|
You can send dynamic commands to this node, for example to make it resend output.
|
|
@@ -77,6 +83,8 @@ The node requires the price-data input in order to know what times to generate s
|
|
|
77
83
|
This is especially important when merging the schedule using the Schedule Merger node,
|
|
78
84
|
as all schedules that are merged must be for the exact same period.
|
|
79
85
|
|
|
86
|
+
|
|
87
|
+
|
|
80
88
|
## Output
|
|
81
89
|
|
|
82
90
|
There are three outputs. You use only those you need for your purpose.
|
|
@@ -97,7 +105,7 @@ The aoutput is similar to the output from the other strategy nodes.
|
|
|
97
105
|
|
|
98
106
|
###
|
|
99
107
|
|
|
100
|
-
|
|
108
|
+
|
|
101
109
|
|
|
102
110
|
## Usage ideas
|
|
103
111
|
|
|
@@ -110,4 +118,4 @@ Lowest Price schedule using the Schedule Merger node with the `OR` function.
|
|
|
110
118
|
|
|
111
119
|
###
|
|
112
120
|
|
|
113
|
-
|
|
121
|
+
|
|
@@ -9,6 +9,8 @@ next: ./ps-strategy-fixed-schedule.md
|
|
|
9
9
|
|
|
10
10
|
A strategy for moving consumption from expensive to cheap periods utilizing climate entities.
|
|
11
11
|
|
|
12
|
+
|
|
13
|
+
|
|
12
14
|
## Description
|
|
13
15
|
|
|
14
16
|
The heat capacitor strategy utilizes a large body of mass, like your house or cabin, to procure heat at a time where electricity is cheap, and divest at a time where electricity is expensive.
|
|
@@ -19,6 +21,8 @@ It is a good application for cabins/heated storage spaces, as the entity never a
|
|
|
19
21
|
|
|
20
22
|

|
|
21
23
|
|
|
24
|
+
|
|
25
|
+
|
|
22
26
|
## Configuration
|
|
23
27
|
|
|
24
28
|

|
|
@@ -39,7 +43,7 @@ The node consumes price information and outputs $\Delta T$ on its first output a
|
|
|
39
43
|
|
|
40
44
|
###
|
|
41
45
|
|
|
42
|
-
|
|
46
|
+
|
|
43
47
|
|
|
44
48
|
### The impact of **Time +1C**
|
|
45
49
|
|
|
@@ -51,6 +55,8 @@ To get started, 90 minutes can be used for air heaters. Later, one can study the
|
|
|
51
55
|
|
|
52
56
|
The setpoint, $S_p$, indicates the ideal temperature.
|
|
53
57
|
|
|
58
|
+
|
|
59
|
+
|
|
54
60
|
### Max temperature adjustment
|
|
55
61
|
|
|
56
62
|
A max temperature adjustment $M_{ta}$ value of $0.65~^{\circ}C$ will change the setpoint temperature by $\pm0.65~^{\circ}C$. Please note that a larger number will indicate a longer heating time (Time +1C = 60 and Max Temp Adj.= $0.75~^{\circ}C$ results in a heating time of $60\times0.75\times 2= 90$ minutes
|
|
@@ -72,6 +78,8 @@ In the scenario where one should invest at 03:00 at night, and divest at 08:00 i
|
|
|
72
78
|
- 08:00 to 09:00: $-2~^{\circ}C$
|
|
73
79
|
- 09:00 and onward: $-1~^{\circ}C$
|
|
74
80
|
|
|
81
|
+
|
|
82
|
+
|
|
75
83
|
### Min Savings
|
|
76
84
|
|
|
77
85
|
The heating and cooling periods can be seen as buy - sell pairs. That is, heat is procured at time t, and the same heat is sold at t+dt. The savings can then be estimated as the price difference $S=price(t+dt) - price(t)$. If this saving is less that the minimum savings requirement, it will be removed. The algorithm removes these in a prioritized order, starting with the pair with the smallest gain.
|
|
@@ -100,6 +108,8 @@ The config sent like this will be valid until a new config is sent the same way,
|
|
|
100
108
|
|
|
101
109
|
When a config is sent like this, and without price data, the schedule will be replanned based on the last previously received price data. If no price data has been received, no scheduling is done. You can send config and price data in the same message. Then both will be used.
|
|
102
110
|
|
|
111
|
+
|
|
112
|
+
|
|
103
113
|
## Output
|
|
104
114
|
|
|
105
115
|
There are three outputs. You use only those you need for your purpose.
|
|
@@ -132,6 +142,8 @@ The number of degrees which has been added or subtracted to the setpoint
|
|
|
132
142
|
}
|
|
133
143
|
```
|
|
134
144
|
|
|
145
|
+
|
|
146
|
+
|
|
135
147
|
### Output 3
|
|
136
148
|
|
|
137
149
|
The current schedule as well as some other information. You can use this to see the plan and verify that it meets your expectations. You can also use it to display the schedule in any way you like.
|
|
@@ -153,6 +165,8 @@ The "trades" key contains a list of dictionaries indicating the trades:
|
|
|
153
165
|
|
|
154
166
|
A trade consists of a `buy action` and a `sell action`. You buy electricity in the heating period, and sell it during the cooling period. `buyPrice` indicates the price at which the electricity is bought, while `sellPrice` indicates the price at which it is sold. This yields the `tradeValue`, which is how much is gained by moving one kWh from the expensive to the cheap period. If you run two 1kWh heaters and is able to turn it off from a 50% load for an hour, you earn 1kWh _ 2 _ 50% \* 0.2558 = 0.2558.
|
|
155
167
|
|
|
168
|
+
|
|
169
|
+
|
|
156
170
|
The temperature variations from the setpoint are shown in a list at the end of the dictionary. The array has minute resolution, meaning that the first value is valid from 07.02.2022 00:00 till 00:01. As such, this is an indexed list, and the `buyIndex` and `sellIndex` values is a reference to the index in this array.
|
|
157
171
|
|
|
158
172
|
Full example:
|
|
@@ -356,4 +370,4 @@ Full example:
|
|
|
356
370
|
|
|
357
371
|
###
|
|
358
372
|
|
|
359
|
-
|
|
373
|
+
|
|
@@ -9,10 +9,14 @@ next: ./ps-strategy-heat-capacitor.md
|
|
|
9
9
|
|
|
10
10
|
Strategy node to turn on power the hours when the price is lowest during a given period, and turn off the other hours.
|
|
11
11
|
|
|
12
|
+
|
|
13
|
+
|
|
12
14
|
## Description
|
|
13
15
|
|
|
14
16
|
The node can work on a specific period from 1 to 24 hours during a 24 hour period. Inside this period, you can decide how many hours that shall be on. The rest of the period will be off. Outside the period, you can select that the output shall be either on or off. You can also decide that the hours on shall be consecutive (one continuous period) or spread around in multiple on-periods.
|
|
15
17
|
|
|
18
|
+
|
|
19
|
+
|
|
16
20
|
## Configuration
|
|
17
21
|
|
|
18
22
|

|
|
@@ -35,6 +39,8 @@ If you want to use a period of 24 hours, set the From Time and To Time to the sa
|
|
|
35
39
|
::: tip Example with Consecutive On-Period
|
|
36
40
|
One example to need a consecutive on-period can be if you want to control the washing machine. Let's say it needs 3 hours, and you want it to run between 22:00 and 06:00. Set `From Time = 22:00`, `To Time = 06:00` and check the `Consecutive On-Period` flag. This will turn on the cheapest 3-hour period from 22:00 to 06:00.
|
|
37
41
|
|
|
42
|
+
|
|
43
|
+
|
|
38
44
|
NB! It is not recommended to run the washing machine when you are sleeping or away.
|
|
39
45
|
:::
|
|
40
46
|
|
|
@@ -66,7 +72,7 @@ If you leave `Max price` blank, it has no effect.
|
|
|
66
72
|
|
|
67
73
|
###
|
|
68
74
|
|
|
69
|
-
|
|
75
|
+
|
|
70
76
|
|
|
71
77
|
### Dynamic config
|
|
72
78
|
|
|
@@ -92,6 +98,8 @@ The following config values can be changed dynamically:
|
|
|
92
98
|
|
|
93
99
|
See [Dynamic Config](./dynamic-config.md) for details and how to send dynamic config.
|
|
94
100
|
|
|
101
|
+
|
|
102
|
+
|
|
95
103
|
### Dynamic commands
|
|
96
104
|
|
|
97
105
|
You can send dynamic commands to this node, for example to make it resend output.
|
|
@@ -113,13 +121,15 @@ A payload with the value set in config, default `true`, is sent to output 1 when
|
|
|
113
121
|
|
|
114
122
|
A payload with the value set in config, default `false` is sent to output 2 whenever the power / switch shall be turned off.
|
|
115
123
|
|
|
124
|
+
|
|
125
|
+
|
|
116
126
|
### Output 3
|
|
117
127
|
|
|
118
128
|
When a valid input is received, and the schedule is recalculated, the resulting schedule, as well as some other information, is sent to output 3. You can use this to see the plan and verify that it meets your expectations. You can also use it to display the schedule in any way you like.
|
|
119
129
|
|
|
120
130
|
###
|
|
121
131
|
|
|
122
|
-
|
|
132
|
+
|
|
123
133
|
|
|
124
134
|
Example of output:
|
|
125
135
|
|
|
@@ -195,6 +205,8 @@ Example of output:
|
|
|
195
205
|
|
|
196
206
|
The `schedule` array shows every time the switch is turned on or off. The `hours` array shows values per hour containing the price (received as input), whether that hour is on or off, the start time of the hour and the amount per kWh that is saved on hours that are turned off, compared to the next hour that is on.
|
|
197
207
|
|
|
208
|
+
|
|
209
|
+
|
|
198
210
|
## Restarts and saved context
|
|
199
211
|
|
|
200
212
|
The config, last received prices and the last calculated schedule are saved to the nodes context.
|
|
@@ -217,6 +229,8 @@ contextStorage: {
|
|
|
217
229
|
}
|
|
218
230
|
```
|
|
219
231
|
|
|
232
|
+
|
|
233
|
+
|
|
220
234
|
By default, this node saves context to the `default` context storage. In the example above, this is memory.
|
|
221
235
|
Then it is not preserved over a restart.
|
|
222
236
|
Please read the [Node-RED documentation](https://nodered.org/docs/user-guide/context) for more details about this.
|
|
@@ -238,6 +252,8 @@ and set `msg.payload` to the following JSON value:
|
|
|
238
252
|
|
|
239
253
|
This is an alternative to fetching new prices and send as input.
|
|
240
254
|
|
|
255
|
+
|
|
256
|
+
|
|
241
257
|
## Tips & tricks
|
|
242
258
|
|
|
243
259
|
### Multiple nodes works together
|
|
@@ -247,6 +263,8 @@ combine the output from them into one schedule using the Schedule Merger node:
|
|
|
247
263
|
|
|
248
264
|

|
|
249
265
|
|
|
266
|
+
|
|
267
|
+
|
|
250
268
|
### Highest price
|
|
251
269
|
|
|
252
270
|
If you want to find the `x` hours with the highest prices, do as follows:
|
|
@@ -257,4 +275,4 @@ If you want to find the `x` hours with the highest prices, do as follows:
|
|
|
257
275
|
|
|
258
276
|
###
|
|
259
277
|
|
|
260
|
-
|
|
278
|
+
|
|
@@ -2,6 +2,8 @@
|
|
|
2
2
|
|
|
3
3
|
The common input for strategy nodes is a payload with a `priceData` array containing an object for each hour. Each object has a `value` which is the price, and a `start` which is the start time for the hour.
|
|
4
4
|
|
|
5
|
+
|
|
6
|
+
|
|
5
7
|
Example:
|
|
6
8
|
|
|
7
9
|
```json
|
|
@@ -40,4 +42,4 @@ This format is used for:
|
|
|
40
42
|
|
|
41
43
|
###
|
|
42
44
|
|
|
43
|
-
|
|
45
|
+
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "node-red-contrib-power-saver",
|
|
3
|
-
"version": "4.2.
|
|
3
|
+
"version": "4.2.3",
|
|
4
4
|
"description": "A module for Node-RED that you can use to turn on and off a switch based on power prices",
|
|
5
5
|
"main": "index.js",
|
|
6
6
|
"scripts": {
|
|
@@ -46,24 +46,24 @@
|
|
|
46
46
|
"url": "https://github.com/ottopaulsen/node-red-contrib-power-saver.git"
|
|
47
47
|
},
|
|
48
48
|
"devDependencies": {
|
|
49
|
-
"@vuepress/bundler-vite": "2.0.0-
|
|
50
|
-
"@vuepress/
|
|
51
|
-
"@vuepress/plugin-register-components": "2.0.0-
|
|
52
|
-
"@vuepress/plugin-search": "2.0.0-
|
|
53
|
-
"@vuepress/
|
|
49
|
+
"@vuepress/bundler-vite": "2.0.0-rc.18",
|
|
50
|
+
"@vuepress/utils": "2.0.0-rc.18",
|
|
51
|
+
"@vuepress/plugin-register-components": "2.0.0-rc.54",
|
|
52
|
+
"@vuepress/plugin-search": "2.0.0-rc.55",
|
|
53
|
+
"@vuepress/theme-default": "2.0.0-rc.60",
|
|
54
54
|
"chai": "^4.3.10",
|
|
55
|
-
"eslint": "
|
|
55
|
+
"eslint": "9.14.0",
|
|
56
56
|
"expect": "29.7.0",
|
|
57
|
-
"mocha": "^10.2
|
|
58
|
-
"node-red": "^
|
|
59
|
-
"node-red-node-test-helper": "0.3.
|
|
60
|
-
"sass-loader": "^
|
|
61
|
-
"vuepress": "2.0.0-
|
|
57
|
+
"mocha": "^10.8.2",
|
|
58
|
+
"node-red": "^4.0.5",
|
|
59
|
+
"node-red-node-test-helper": "0.3.4",
|
|
60
|
+
"sass-loader": "^16.0.3",
|
|
61
|
+
"vuepress": "2.0.0-rc.18"
|
|
62
62
|
},
|
|
63
63
|
"dependencies": {
|
|
64
64
|
"floating-vue": "2.0.0-beta.24",
|
|
65
65
|
"lodash.clonedeep": "4.5.0",
|
|
66
|
-
"luxon": "3.
|
|
66
|
+
"luxon": "3.5.0",
|
|
67
67
|
"nano-time": "1.0.0",
|
|
68
68
|
"node-fetch": "2.6.7"
|
|
69
69
|
}
|