Water boiler control optimized for dynamic electricity pricing

[dr-m]

I recently switched my electricity contract from fixed to dynamic pricing. A large consumer is a boiler that provides warm water for 1 to 2 days. Thanks to its smallish volume and high power, it will heat up from cold to hot in less than 1 hour. Coincidentally, the current dynamic electricity pricing of Nord Pool is set in 1-hour intervals.

I got a Shelly Pro 2, upgraded its proprietary firmware to 1.3.0 and further to Tasmota 14.1.0 using these instructions. Power1 drives a 3-phase contactor that drives the 3×2kW water boiler resistor through a thermostat. Input 1 is wired to a signal "night time electricity tariff is available", which I do not currently do not use. The Tasmota configuration is as follows:

# Detach Switch1 (night electricity) from Power1 (water boiler)
Backlog0 SwitchMode1 15; SwitchTopic1 0
# Enable Power1 for 1 hour at a time
PulseTime 3700

Conveniently, pressing the Reset button in the electricity panel will turn on (or toggle) the state of the heater.

Edit: This example was wrong; We need SwitchMode 15 to fully detach a Switch from the corresponding Power output.

Every 24 hours, a cron job on a Linux box (actually, OpenWrt router) fetches the Nord Pool electricity prices for Finland in JSON format from https://sahkotin.fi. It fetches the prices for the next 23 hours, sleeps until the start of the cheapest hour, and finally sends a command to turn on the heat:

#!/bin/sh
set -eu
: ${PRICES=/tmp/prices.json}
: ${PRICEURL="https://sahkotin.fi/prices"}
: ${TASMOTA="http://192.168.1.136"}

# Fetch the next 23 hours of electricity prices
now=$(date +%s)
start=$(date -u +%Y-%m-%dT%H:00:00.000Z -d "@$now")
end=$(date -u +%Y-%m-%dT%H:00:00.000Z -d @$(($now + 82800)))
wget -qO "$PRICES" "$PRICEURL?start=$start&end=$end"

# Determine the cheapest hour in the future
if which jq > /dev/null; then
  bestdate=$(jq '.["prices"]|min_by(.value).date' < "$PRICES"|
	         sed -e 's/[T"]/ /g;s/:00\.000Z//;')
else
  # On OpenWrt there is no jq installed by default, but
  # https://openwrt.org/docs/guide-developer/jshn
  set +u
  . /usr/share/libubox/jshn.sh
  json_load "$(cat "$PRICES")"
  dump(){ eval "echo -e \$$1_value\\\\t\$$1_date";}
  bestdate=$(json_for_each_item dump prices|awk '
BEGIN{v="NaN";d="";}
{if($1<0+v){v=$1;d=$2;}}
END{sub(/T/," ",d);sub(/:00\.000Z/,"",d);print d}
')
fi

# Wait for the start of the cheapest hour
delay=$(($(date +%s -u -d "$bestdate") - $now))
[ "$delay" -gt 0 ] && sleep $delay
wget -qO - "$TASMOTA/cm?cmnd=POWER+ON" > /dev/null

Above, the logic for determining the earliest start time of the minimum price is implemented both in the OpenWrt specific https://openwrt.org/docs/guide-developer/jshn as well as in https://jqlang.github.io/jq/. You probably want to strip out the if, else and fi and the not-applicable part.

The error handling is rather crude. The most likely error ought to be that the a connection to the price source fails, and an error from wget terminates the entire script due to the set -e. If the server delivers malformed or invalid data, the computation of delay could fail due to invalid date -d "$bestdate" parameter. Also the connection to $TASMOTA could fail or the electricity supply of the house could be interrupted during the sleep. I am willing to take the risk; there hopefully should be warm water on the next attempt (within in 24 hours), or someone could go and push the Reset button on the Shelly Pro 2 to start the water boiler for 1 hour. For any troubleshooting, the file /tmp/prices.txt and its latest modification timestamp would be available.

Instead of defining a static IPv4 address for the Tasmota node, I guess I could have enabled the mDNS server and used a .wlan or .local address.

If the Tasmota WebQuery command returned the result in the default firmware build, it might be possible to fetch and parse the JSON on the Tasmota itself.

Initially, I had implemented some more complex logic in Tasmota, starting the boiler at 3:00 am and turning it off at the end of the night time transfer tariff (7:00 am). I know, I would not really need any var1 there, but I wanted to learn how to write some more complex rules:

# Europe/Helsinki in https://tasmota.github.io/docs/Timezone-Table/
Backlog0 Timezone 99; TimeStd 0,0,10,1,4,120; TimeDst 0,0,3,1,3,180
Backlog0 Latitude 60.3; Longitude 25.1
# var1 is empty when night electricity is active
# Turn off water boiler at the end of night electricity.
Rule1 ON Switch1#State=0 DO Backlog Power OFF; var1 0 ENDON
Rule2 ON Switch1#State=1 DO var1 " ENDON
# On timer, turn on the water boiler if we are on night electricity
Rule3
  ON Clock#Timer DO event power=%var1% ENDON
  ON event#power= DO Power ON ENDON
Timer {"Enable":1,"Mode":0,"Time":"03:00","Window":0,"Days":"1111111","Repeat":1,"Output":1,"Action":3}
# Enable all rules
Backlog0 Rule1 1; Rule2 1; Rule3 1

Something like this might be used as a fallback in case the /bin/sh script failed. Currently the timer and the rules are disabled on my system.

The reason why I did not go for something like HomeAssistant is that I want to minimize the number of always-on systems in my home.

[sfromis]

While I'm not trying to comment on your project (it is of course great that you got it to work for you), I wondered if you considered using the Berry language instead of rules. As the Shelly Pro 2 is ESP32-based, this "full" programming language is available in Tasmota, and allows much better local control than feasible within the restrictions of using rules, as you can create more than "minor programs".

This includes a stronger http implementation than available with the WebQuery command, and also has straightforward JSON parsing. No custom builds needed, as this is standard across ESP32 builds. Rules can be fine for the simplest things, but I've found that using Berry, there is much less need for having some of the processing handled on some Linux box, or whatever.

[dr-m]

This project is my first exposure to Tasmota. Implementing this in Berry would seem to be the next natural step and a useful learning experience. For my installation with only one device, it indeed would make sense to make that device self-contained. As long as running the program will not cause any flash write cycles, it should be fine. Could you point me to an example that would be run on a schedule and fetch JSON data over HTTP or HTTPS and parse it?

My implementation will have to be revised anyway when the Nord Pool market moves from 60-minute slots to 15-minute or shorter slots. In such a case, I would want to choose the N cheapest (not necessarily consecutive) slots of each day for running the load.

For any installation where there are several devices that need to be controlled by dynamic pricing, I think that it is better to have a central management that caches the price information and sends commands to individual nodes. This could still be feasible to implement in the Berry language.

[sfromis]

The steps (or lack of same) around "had done the last code changes" are significant. Just running the code again would typically mean that any setup done by the prior iteration of the program is still in operation, like being as a driver, cron timers, being a web server, and so on. And the footprint of your driver can effectively be a memory leak, leading to low memory, in addition to unneeded activity continuing with both version active.

With code meant to automate stuff in the background, where I want to be able to update it on the fly, I make sure that it can detect that it was already started, and stop the old iteration, before the new iteration integrates itself. Here's an example of such code:
http://sfromis.strangled.net/tasmota/berry/examples/slider.be
Look for where globalname name is used. It could also be done a bit simpler with a constant name instead of having it in a variable, and then something like global.slider_instance=self and global.slider_instance.stop()

Note that while some types registration for integration has the opposite like tasmota.remove_driver, that's not the case for all possible ways of integrating code with Tasmota. Then you can try a dev build with a big red "Restart Berry VM" in the Berry REPL console (or the corresponding command), but that's not "guaranteed" to be "totally clean", compared to a total restart.

[dr-m]

Each time, I did something like the following:

1. Checked the Berry syntax by defining the class with another name, and without the Berry module preamble and postamble.
2. In the Tasmota file manager, replaced the .tapp file with new code.
3. In the Tasmota console, executed BrRestart to reload the .tapp file.
4. In the Tasmota console, executed a command that is provided by the module, to start the web UI.
5. Used the web UI a little bit, then some time later observed that it has hung.
6. Restored connection by repeatedly pressing the button on the device and connecting to the stand-alone WLAN.

The last such session on Friday also involved uploading the Berry code to a .be file and executing tasmota.compile() in the Berry console, as well as downloading the .bec file and uploading the updated .tapp file.

I don’t think I ever ran multiple copies of the implementation; I always ensured with BrRestart that a previous copy was not running, possibly after removing the .tapp file via the file manager.

Could it be that the BrRestart command was not resetting everything? In any case, I am happy that the application and the WLAN connection seem to be reliable and the instability is only related to this development workflow.

[sfromis]

No, you did not ensure anything about the risk of lingering effects of prior iteration

As I already wrote:

but that's not "guaranteed" to be "totally clean", compared to a total restart.

The docs about restarting the Berry VM includes:

may generate negative side effects

It is not really meant for normal (production) operation, only as a blunt tool to help during development with multiple cycles to improve the code. As such it is useful to speed up development a bit. If you can demonstrate a reproducible case example of how to get into trouble after using the VM restart, that could be a basis for looking into if something can be fixed in a feasible way.

When it comes to using tasmota.compile and .bec files, that's something I'd skip unless having demonstrated benefits.....

[dr-m]

Right, using a .bec file instead of .be did not seem to affect the heap memory usage reported by State in any way. The biggest impact (up to 10 kilobytes or 100 objects) was achieved by copying the data from the parsed JSON structure to two separate arrays (or linked lists). With the parsed structure, there would be a linked list (or a map) of maps.

[dr-m]

With the development firmware b3b9699 the handling of these fatal error situations seems to be more robust: Tasmota is apparently rebooting itself, and I don’t have to physically go and long-press or repeatedly press the button on the device to regain control. The main reason for installing that firmware was to get ECDSA support for HTTPS.

[dr-m]

I filed #22529 for this.