Thermostat Controller

[arijav]

Description:

New driver created for thermostat control. I have created initially this as a LUA script running in Domoticz on a Raspberry Pi to control floor heating valves using Qubino Z-wave relays. I have ported this to a Tasmota driver embedding the functionality in the relays. This driver has been successfully tested with a Shelly 1PM, a Shelly 2.5 and a Sonoff 4CH PRO R2. Summary of the features:

• Implementation of multi independent controllers in the same device (number selected by define to save memory, in-depth testing started with Sonoff 4CH PRO R2, optimizations pending).
• The controller offers three operation modes, Off, Automatic (controller active) and Manual (controller following the input from a serial connected wall thermostat). The transition to manual happens once the input switch is active, allowing seamless integration with existing wall thermostats.
• The controller offers 2 climate modes, heating as well as cooling (for cooling the testing is pending as well as further optimizations).
• The controller offers 3 controlling strategies (Hybrid, predictive rampup control and PI).
• The temperature can be received via MQTT or a local temperature sensor (name set by define, default DS18B20).
• The default input format for the temperature is degrees Celsius but it can be switched to Fahrenheit via MQTT command.
• The controller offers a diagnostic functionality based on inconsistent states between output, command and input (Diagnostic for maximum power at output already covered by the energy driver).

Future features (TODO´s):

• Configuration over the Web Timer's GUI (Selector for Thermostat and box for Setpoint).
• Rework of global_temperature concept in Tasmota for using several temp. sensors
• Humidity control (to be defined).

Related issue (if applicable): fixes #

Checklist:

• The pull request is done against the latest dev branch
• Only relevant files were touched
• Only one feature/fix was added per PR.
• The code change is tested and works on core Tasmota_core_stage
• The code change pass travis tests. Your PR cannot be merged unless tests pass
• I accept the CLA.

[device111]

issue, address not correct:
uint8_t free_f36[70];
check:
tasmota/tasmota.h

do you think, you can integrate like tasmota timers? i don't now if this works, but will be easier for set heating plan.
at the moment you are loose all settings from heating plan?

[s-hadinger]

From what I can see you are not using Flash Settings anymore, but only compile time options. Right?

[arijav]

Thanks for the comments:

1. I will correct Tasmota.h and recommit the change. Regarding the timers I can investigate, which ones do you mean that are existing in Tasmota?

2. Yes, I do no longer use the flash settings. The only small drawback is that for specific configurations not fitting the default values, after a reset the device should be reconfigured via MQTT (which is possible for each of the parameters).

[arendst]

There is no need to scan JSON messages to find a locally connected temperature sensor. Tasmota provides an internal variable called global_temperature which contains the temperature read by a locally attached temperature sensor. Could be any type of hardware.

So I suggest you rewrite your latest addition using the knowledge from xdrv_03_energy.ino lines 442-446 demonstrating the use of this local variable.

I suggest too to search for global_temperature to find more examples in the code.

And pls remember, keep the code as small as possible. I see a lot of logging which luckily can be disabled by a define which looks good.

[arijav]

There is no need to scan JSON messages to find a locally connected temperature sensor. Tasmota provides an internal variable called global_temperature which contains the temperature read by a locally attached temperature sensor. Could be any type of hardware.

So I suggest you rewrite your latest addition using the knowledge from xdrv_03_energy.ino lines 442-446 demonstrating the use of this local variable.

I suggest too to search for global_temperature to find more examples in the code.

And pls remember, keep the code as small as possible. I see a lot of logging which luckily can be disabled by a define which looks good.

Thanks for the tip, I have modified the code to use global_temperature but I have issues. In the shelly PM I have attached a DS18B20 and adapted the template according to your modifications (old issue from February I think) to read both temperatures the internal one of the module and the DS18B20. The issue is that the variable global_temperature is being update with both of them sequentially:

Example of my reads:
13:21:10 MQT: stat/tasmota_BA0DC9/RESULT = {"GlobalTemp":21.9}
13:21:13 MQT: stat/tasmota_BA0DC9/RESULT = {"GlobalTemp":33.5}
13:21:16 MQT: stat/tasmota_BA0DC9/RESULT = {"GlobalTemp":33.5}
13:21:17 MQT: stat/tasmota_BA0DC9/RESULT = {"GlobalTemp":33.5}
13:21:18 MQT: stat/tasmota_BA0DC9/RESULT = {"GlobalTemp":21.9}
Infos of the main Tasmota webpage of my Shelly:
Temperature: 33.5°
DS18B20 Temperature: 21.9°

I can have a look to solve the issue, but currently I foresee that all modules with an internal temperature sensor and an attached external one would face this problem. Maybe it would make sense to separate the global_temperature into two variables, one for internal and one for external, since you need to keep the overtemperature protection feature of the modules in xdrv_03_energy.ino.

Regarding Debug, yes, I will leave everything into the define and disable it by default, furthermore it is my intention to reduce it drastically soon, since I see that the controller reacts exactly as the one I have in Domoticz based on LUA.

[arendst]

You're right. I had hoped only one sensor was connected but if more are used it becomes "messy".

Adding and "external" global_temperature is indeed a fix as long as there is only one external sensor connected. It will need a kind of large rework task.

For now, let's leave your solution in place and only think about a possible global solution.

[kretu]

Would it be hard to implement control by humidity rather than temperature?

[arijav]

Would it be hard to implement control by humidity rather than temperature?

It means some rework but it is feasible. I can make it active via define to save some memory and will need to think about a better name for the driver. If you describe the system a little bit I can add it to the lists of TODO´s and evaluate

[yury-sannikov]

hi @arijav, awesome PR! Do you think it makes sense to add telemetry output enabling tasmota Rules tapping into the output value and do other things rather than MQTT and Relay control?

[arijav]

hi @arijav, awesome PR! Do you think it makes sense to add telemetry output enabling tasmota Rules tapping into the output value and do other things rather than MQTT and Relay control?

Thanks, what it is foreseen is to be able to configure the timers to arm the thermostat to reach a given set point and disarm them and therefore rules could be used. Do you mean this or something else (maybe an example can help)?

[3ricj]

First of all, I am really excited about this capability. I don't like the idea of thermostats running off external devices, so having it integrated on the controller is perfect. Thank you.

Some general feedback:

• there are lots of application specific control methods.

For example, compressor based heat pumps (AC/cooling/heating) need a minimum cycle time because you don't want to restart a compressor quickly; this can lead to stalling. Inversely, a sousvide cooker would want a fast cycle time. I feel this is pretty important.

There are also TECs that may need proportional control (not just on or off but on percentages) using PIDs. Its unlikely many will use this. Some really complicated systems use variable speed heat pumps. You see these marketed as "inverters".

It would be great if this code could also manage error states. For example, if the heater is "ON" but it's not getting warmer, it's an error. Same for AC on but not cooling. In some cases it should error on overrun: if it's set to cool down to 1c, but we are below that (say -3c) that could be worthy of an error flag. If this was used to control a fridge you don't want to go below freezing.

A related, but harder to compute is a flag for "stable temp". Eg: it's not oscillating, overrun, underrun, etc.

• it would likely be important to have a concept of deadband. Cold tolerance and hot tolerance.

Anyway, none of this needs to be implemented, this is not a feature request, but just some food for thought.

[yury-sannikov]

Thanks, what it is foreseen is to be able to configure the timers to arm the thermostat to reach a given set point and disarm them and therefore rules could be used. Do you mean this or something else (maybe an example can help)?

My point is pretty much the same as @3ricj

There are also TECs that may need proportional control (not just on or off but on percentages) using PIDs. Its unlikely many will use this. Some really complicated systems use variable speed heat pumps. You see these marketed as "inverters".

I can see 2 types of the telemetry output:

• Power, in a range of 0-100%
• The desired temperature in celsius.

For example, to control the duty cycle of some inverter one can use:

Rule
  on tele-pid#output#duty_cycle do event pwm=(%value%*1024) endon
  on event#pwm do  WebSend [...] Pwm %value% endon

For example, to control the boiler with PID:

Rule
  on tele-pid#output#temperature do ot_tboiler %value% endon

In those examples telemetry JSON might look like:

{...., "pid":{"output": {"duty_cycle": 0.85, "temperature": 78}}, ....}

[arijav]

Thanks, what it is foreseen is to be able to configure the timers to arm the thermostat to reach a given set point and disarm them and therefore rules could be used. Do you mean this or something else (maybe an example can help)?

My point is pretty much the same as @3ricj

There are also TECs that may need proportional control (not just on or off but on percentages) using PIDs. Its unlikely many will use this. Some really complicated systems use variable speed heat pumps. You see these marketed as "inverters".

I can see 2 types of the telemetry output:

• Power, in a range of 0-100%
• The desired temperature in celsius.

For example, to control the duty cycle of some inverter one can use:

Rule
  on tele-pid#output#duty_cycle do event pwm=(%value%*1024) endon
  on event#pwm do  WebSend [...] Pwm %value% endon

For example, to control the boiler with PID:

Rule
  on tele-pid#output#temperature do ot_tboiler %value% endon

In those examples telemetry JSON might look like:

{...., "pid":{"output": {"duty_cycle": 0.85, "temperature": 78}}, ....}

Understood, will evaluate for sure. Thanks for the input

[Bibinsa]

Hi ! I'm using Thermostat feature since a fex days now.

I wonder if there is any option to activate telemetry with cycle reset, max time, ... any reasons that trigger Power ON/OFF ?
If not, could it be possible to implement that ?

Thanks.