Okay let's get your updated on the latest solution.

Hardware

What I had before in terms of hardware (shelly uni) worked pretty good. Really nothing to complain about the solution, but I discovered how to enable MODBUS TCP in the heater and started looking into this more. 
A few days later I was able to remove the external hardware I built controlling the heater and now running the control program completely from software using purely modbus communication.
The software communication is utilizing Home Assistant Modbus integration and only requiered me to figure out which address each parameter in the heater had. This was a pretty touch job.
Mainly what I did was
•    installing CAS Modubus Scanner on my PC
•    ran remote desktop from my Chrome-book to the PC with the modbus scanner
•    and was then able to look at all modbus parameters live while comparing the numbers on the heater display. And then wrote down all the addresses I was interesting in.

Basically, below you'll see the sensors I was able to locate modbus addresses for

First line is an internal home-assistant switch which will allow me to disable/enable the control program if anything starts to malfunction. But the other signals are pulled directly from the heater.
The last two signals indicates if the heater is in running state or not. One of them could be removed, they are always showing the same state.
The signals are then pulled from Home Assistant into my node-red software using the Home-Assistant plugin for node-red. This is then where the logic is applied.

Control program

I have also added some more math into the control program to make it more dynamic.

There are a few questions that will need to be answered to make all the right decisions in the control program.

• What will be the out door temperature for the next hours?
  I am currently using the SMHI web api to fetch this information.

• How many hours will my heater need to run based on the temperature forecast fetched above?
  I use run history from my house to fetch this information.
  As seen in the graph the number of run hours on my heater is forming a pretty linear function.
  Using what we learned in school back in the days about linear functions I was able to figure out a function describing the run hours based on the out-door temperature.
  

Now with knowledge about the required run hours on my heater each day I can schedule the downtime based on the coming price tops.

In the image above you'll see red bars indicating total downtime on the heater.
And as you may also see there are always one hour indicated with green color infront of each red bar. This will ask the heater to run the hour before the scheduled downtime ans avoid too low temperature in the radiator tanks.
The yellow line indicates the price limit that will need to be accepted this specific period to avoid the heater from getting less run hours than needed. So based on the out-door temperature the heater could be running all hours where price is less than the yellow line and then is not needed the other hours.
The problem with this is that the radiator tank cannot store this amount of heat and so will still require the heater to start during the time when price to above line.

What I did instead is that I scheduled the downtime around all the tops instead and have set limit on how many hours each downtime can go on in percentage of the total downtime. And from what I can see now the solution works well.
Only problem I sometimes can see is that when the temperature is very low (below -20C) the temperature in the garage is hard to maintain and I cannot afford scheduling any downtime at all without getting affected by low inside temperature.

When looking back at the history I can clearly see that the control program is doing what it is supposed to but I can also see that there is a very little earning that can be made on the heater because it cannot be scheduled on downtime for a very long time and only the biggest price tops during each days is what you can earn from.

We can see that most of the days we have roughly 2-5% earning from the heater running this way. It's not very much but having a program doing this won't cost me anything more than the spent hours so far.

Just recently completed the control program for the Accelev v2 2 phase EV charger.

The charger can transform 400V 2 phase down to 250V 1 phase which comes handy for cars that are equiped with only 1 phase on-board charger.
The technique utilized are an IoT platform running on a raspberry pi 4, running ubuntu 20.04 LTS.
Influxdb v2 as database, recording everything passing the mqtt broker on localhost.
Grafana for graphs.
Node-RED for flow control (this is currently where the program is running).

And as you can see in the image below, the current in main central i pretty close to the fuse limit throughout the charging time. 
The three graphs in the top represents the current in the main central.
The three graphs in the bottom represents the current in the garage (where the charger is located).

The charger does not yet allow to communicate directly with the control program, it requiers connection with the server over internet and therefore won't work without internet connection.
From what I've heard, the vendor are working on implmentation of the apis directly in the local charger.