The Target or Preset temperature in a central heating system can be set in many ways:

1. The Schedule is set to change the preset temperature up to 7 times a day. A table is created so the user has a record of these, so the table needs to be available for display on the Dashboard, and available by request b y Telegram.
2. Using Telegram, you can simply type in the new temperature.
3. There are two buttons on the Dashboard so the user can increase or decrease the current tempeerature by one half of a degree.

The Preset temperature is processed as follows: 

1. It is compared with the actual room temperature. If preset is the greater then the oil burner is fired up, if less the burner is turned off.
2. It is compared with 24 degrees C, which is the ‘meltdown’ temperature i.e. the maximum permissable.
3. The user must be warned of a meltdown situation

The Preset Temperature is communicated to the user as follows:

1. Through Telegram, in response to the ‘T’ request.
2. On the Dashboard as follows: 

a. As one trace on of the chart

b. in text form

Restart Strategy

The schedule node is designed to provide data at a specific time, but it does not send out any temperature readings if the Pi is switched off and then turned back on, such as during a power outage. This means that there will be no preset temperature in the flows until the start of the next time schedule, which could be hours later. Therefore, it is necessary to have a strategy in place to handle this situation.

Each time the schedule advances to the next one or the user modifies the preset manually, the new preset temperature is stored in the global.preset variable. This variable is then saved to a file called preset.txt located in /home/pi/heating/preset.txt every two minutes, but only if there have been changes. The data stored in this file is relatively secure against power outages and computer restarts, although it is important to note that there are no guarantees as power outages can still disrupt computer systems.

Upon restarting node-RED, the previous preset temperature is retrieved from the file /home/pi/heating/preset.txt and stored in the global.preset variable. Additionally, a text message is sent to the user via Telegram, providing them with information about the current preset temperature and giving them the opportunity to modify it if desired.

In order to extend the life of the SD card in the Pi, I believed it was critical to minimize the number of writes to the ROM address.

To resend the current preset temperature, the schedule node requires the specific schedule that was active when the Pi shut down. Additionally, considering that the user can modify the scheduled temperature before the Pi powers down, it is advisable to retain the actual temperature instead of just the schedule name during the “off” period. 

The generation of a Heating Summary Table as part of the node-RED boot up sequence involved querying the schedule node. Initially, I considered reading the schedules into an array for easier manipulation. Additionally, I explored the idea of calculating the required temperature for the power-up state by comparing the elapsed minutes in the current day with the times in the Heating Summary Table Array. However, these approaches did not account for any changes made by the user after the last schedule ran and the switch-off occurred. Consequently, I opted to store the current preset temperature in ROM, as it appeared to be the most straightforward solution.

The temperature setting at shutdown is temporary and will be replaced with a new value during the next scheduled update.