PURPOSES OF PROJET:
SOFTWARE COMPONENTS USED:
INTERESTED PHYSICAL DEVICES:
PROJET MOST INDICATED FOR:
Notes and disclaimer
|revision projet: 4.2|
As explained also in our training course on the occasion of the "devices" theme, a thermostat is a domestic element that broadly contains in itself a thermometer, a relay and an electronics - more or less complex based on the models - in which lies the (primitive) intelligence that allows it to be proset by the user in order to provvedere, based on the calendar and the ambient temperature when the heater is switched on and off automatically.
Heat emission in radiators (or in floor coils, or other technologies) is prodotta from an element such as a gas boiler, pellet boiler or other technologies that we will call, starting from here, thermal unit and that we will take for granted, for this projet, in the home environment.
Thermal units are usually activated at proheat production by closing by a thermostat of a clean contact of type NC or NO (normally closed o normally open), or two poles not powered by electricity and that, if open (in the case of NC contact) or closed (in the case of NO contact) they start for theappunto the proheat production.
There are also other methodologies, such as powered contacts, but they are not object of the present projet.
This projet will illustrate how, thanks only to a clean contact (in this projet we will use a Sonoff Basic modified for this purpose, but any actuator a is fine clean contact) is a thermal sensor will we succeed in to shift the intelligence of a traditional thermostat at Home Assistant, domotizzando so any thermal unit activated via clean contact NC or NO.
Sonoff Basic Sara our actuator, the thermal sensor our thermometer, then finally Home Assistant become our thermostat - which will allow us to automate heating, control it remotely and much more.
Obviously, the traditional thermostat can be later removed, as no longer necessary.
In case no longer works the internet connection, the thing is not rappwill resent a proproblem (except for the possible remote control): Home Assistant still works on the LAN / Wi-Fi local, therefore it will be possible to continue to control the heating although with the internet connection not working.
Obviously, alternatives exist. Replace a traditional thermostat with a home automation (eg. NEST, or tado°) allows to obtain the same results as the present procasting without excessive complications.
This projet ha PURE EDUCATIONAL PURPOSE. We are not liable for any damages (of any kind) prosuited by the user.
We have also dedicated two episodes to this of our podcast.
- Logic of projet
- Wiring diagram
- Configuration of Home Assistant
- Ordinary use
- Automation and remote control
The logic proplaced in this projet is as trivial as, we believe, functional.
"Climate"Of Home Assistant is a generic native component that provides this personale HUB the possibility of implementing additional platforms for home climate management. Among the many, "Generic Thermostat"Is a platform that allows you to create one or more entity of climate control (heating or cooling) starting from the control of an actuator and from reading a thermal sensor.
Given that the Sonoff Basic, by modification, can have an exit a clean contact, it goes without saying that it is a ideal candidate to activate / deactivate a thermal unit of that type (activated a NC o DO NOT), and this is why we will use it for this projet. Always by modification, you can use the Sonoff Mini.
The alternative (more expensive, but without any changes) is to use a Sonoff 4ch PRO, which has a well factory four outputs a clean contact (for this prowe will use only one jet).
Whatever the sensor (a Broadlink A1 e-Air, rather than a Sonoff TH-16 / 10-TH or any other sensor that can be integrated with Home Assistant), the important thing to profollow with the present projet is that it is already inserted in the configuration of Home Assistant.
First di profollow, we remember again that:
Notes and disclaimer
What we're going to do it is disconnecting the two poles connected to the thermostat (it is assumed that it is appurate before profollow that the model of thermal unit in use is activated via clean contacts NC o DO NOT, as explained in the abstract) to connect them to the output of Sonoff Basic previously modified to clean contact (modified compulsory!) or to one of those of the Sonoff 4ch PRO (no change to be made).
|ATTENZIONE: Connecting wrongly the exit of a Sonoff Basic NOT modified, when activated, they will be sent 220v to the thermal unit, sending it completely faulty (prodefinitely irreversible) !!!|
This guide has educational purposes only, remember once again that:
The fact that the thermal unit be activated via NC or NO and instead indifferent, since the type of activation of the actuator (the fact that the activation corresponds to the closing or opening of the clean contact) will be set through the configuration of Home Assistant which we will see below.
Given that the Sonoff Basic (mo-di-fi-ca-to!) requires power supply to 220v, the idea could be that to place it in the compartment of the thermal unit (obviously protected from atmospheric agents and any emissions - thermal or otherwise - by the unit itself) and connect the same 220v power supply that the thermal unit receives at the input of the Sonoff Basic to allow the supply also of the latter.
Obviously, the Sonoff Basic and the thermal sensor must be located "On sight" of the Wi-Fi on which it is also attested Home Assistant.
Appthe change to the plant has been added, it's time to configure the elements which will define theentity thermostat at the configuration of Home Assistant.
Nb In order for the configuration to do that appwe remain to carry out functions, it is necessary that the Sonoff Basic modified to clean contact already have on board Sonoff-Tasmota and present the proMQTT tocollo already configured.
RECRUITMENT ON NAMES
We assume for the procast that:
- the name MQTT of Sonoff Basic be itThermoSonoff";
- the name of theentity Home Assistant concerning the temperature sensor both "sensor.temperatura"
Obviously these names can be customized according to profirst configuration.
First of all it is necessary to define in the configuration a switch associated with Sonoff a clean contact which, if activated / deactivated, consequently turn on / off la proheat production.
The entity will take the name of "switch.unita_termica"
switch: - platform: mqtt name: unita_termica state_topic: "stat/ThermoSonoff/POWER" command_topic: "cmnd/ThermoSonoff/POWER" availability_topic: "tele/ThermoSonoff/LWT" qos: 1 payload_on: "ON" payload_off: "OFF" payload_available: "Online" payload_not_available: "Offline" retain: false
È necessario linger on the configuration of two fields, “payload_on" and "payload_off", Or the two payloads associated with the"command_topic“, In fact they act on the activation / deactivation of the physical switch.
As it is configured in the example above, the MQTT commands sent when the switch is activated / deactivated will be:
|Activation (proheat production)||Deactivation|
|cmnd/ThermoSonoff/POWER ON||cmnd/ThermoSonoff/POWER OFF|
This means that upon activation the output contact will be closed (short-circuited) - and maintained that - while in deactivation will be opened – and maintained that, equally. This is the behavior suitable for a thermal unit that is activated by clean contact normally open (DO NOT).
If the thermal unit is activated via clean contact normally closed (NC), the switch configuration must be configured on the contrary:
switch: - platform: mqtt name: unita_termica state_topic: "stat/ThermoSonoff/POWER" command_topic: "cmnd/ThermoSonoff/POWER" availability_topic: "tele/ThermoSonoff/LWT" qos: 1 payload_on: "OFF" payload_off: "ON" payload_available: "Online" payload_not_available: "Offline" retain: false
Which will generate an output command of this type:
|Activation (proheat production)||Deactivation|
|cmnd/ThermoSonoff/POWER OFF||cmnd/ThermoSonoff/POWER ON|
therefore suited to the expected behavior for clean contacts NC, or on activation on clean contact will be opened and deactivation, closed (Shorted).
Nb This behavior (ie theinverted toggle) can also be realized using the first configuration block mentioned above and then apptendering a configuration Sonoff-Tasmota ad hoc through the command SWITCHMODE. The disadvantage is that of having to remember to have implemented this double configuration.
|Nb For more information on configuring MQTT switches on Home Assistant, please refer to this specific page.|
DEFINITION OF THE DOMOTIC THERMOSTAT
Now let's create the type entity "Climate"Based on the" Generic Thermostat "platform.
Tale entity is set for heating functions:
climate: - platform: generic_thermostat name: Riscaldamento heater: switch.unita_termica target_sensor: sensor.temperatura_sala min_temp: 10 max_temp: 25 ac_mode: false target_temp: 17 min_cycle_duration: seconds: 30 initial_hvac_mode: "off" away_temp: 10
This configuration generates an entity of this type:
This configuration it can be widely customized. Please refer to to the platform details sheet to view all the configurable parameters.
At this point the configuration is complete: our generic thermostat è proto operate.
The operating procedures of the thermostat are:
- off (off - intended as non-operating thermostat, no How proheat production extinguished);
- Heat (heating - intended as operating thermostat in heating mode, no How proheat production access).
Once the "Heat", The thermostat will be piousnameoperational e provvederà to switch the heating system on / off (using the switch indicated in the configuration) based on the room temperature (detected by the sensor indicated in the configuration) and the target temperature set by the user.
THE'"Away Mode"Is operational only in abbinameup to the operational state "Heat"
The use of this entity Home Assistant is described in our video:
Once the heating system has been made domotic, in addition to the functions described so far, it will finally be possible:
- activate it and deactivate it Manually means remote control;
- automate behavior through Home Assistanat automations.
For manual remote control it will be enough that Home Assistant is configured in order to be reachable from outside the home and use theappMobile location of Home Assistant and / or a common web browser.
For 'sautomation it will be possible to set various automatic scenarios, including:
- activate "Away Mode" when all the tenants leave the home automation environment;
- activate the "Heat" mode when a specific person enters a specific radius in the vicinity of the domotic environment, so as to pre-heat (in case there is a need based on the temperature);
- set the thermostat to "off" exceeding a certain number of kilometers away from the environment (for example for holiday periods)
- dynamically adjust the target temperature based on the times of day of the night
and many others, according to proneeds and imagination.
Let's look at some examples.
One of the most peculiar characteristics of a thermostat is - in addition to the temperature evaluation - the possibility of timing ignitions.
Given that the present procast allows the creation of an entity "Climate”, this entity lends itself very well toappindication of a timer as explained in this other projet.
SET THE AWAY MODE when TENANTS move away
First of all, we take it for granted that in probefore configuration there is a grouping of device tracker, as explained in this guide, entity we will assume has name "group.famiglia"
Our generic thermostat we will assume is called "climate.riscaldamento"
We want the thermostat to set itself in "Away Mode" if the tenants (all) leave the home automation environment. Obviously, only if the thermostat is in "Heat" mode.
Theautomation will be the following:
automation: - alias: 'Away Mode automatico' trigger: platform: state entity_id: group.famiglia from: 'home' to: 'not_home' condition: condition: state entity_id: climate.riscaldamento state: 'Heat' action: - service: climate.set_preset_mode data: entity_id: climate.living_room_thermostat set_preset_mode: 'away'
Pre-heating activation upon return
Let us assume that a configuration has defined a geographical area with a radius of 10 km called "location”And center of the domotic environment. We want activate the thermostat (therefore indirectly heating, if the temperature is lower than the target one) appena theDevice Tracker" called "Marco"Enter the perimeter of the"location"
automation: - alias: 'Pre-riscaldamento al rientro' trigger: platform: state entity_id: tracker.marco to: 'location' condition: condition: state entity_id: climate.riscaldamento state: 'off' action: - service: climate.set_hvac_mode data: entity_id: climate.riscaldamento hvac_mode: "Heat" - service: climate.set_temperature data: entity_id: climate.riscaldamento temperature: 20
Another interesting example is available on this external page, where the user has created a small control panel at the frontend that is useful for adjusting heating functions linked to automation.
It can of course be useful to also implement chrono functions (for planning ignitions) related to the entity "Climate"Defined by the adoption of the present projet.
Since Home Assistant does not integrate components for the definition of "timer-thermostats, on inDomus we made a further one projet that, starting from an entity “Climate”, Allows you to define switch-on schedules.
The link is the followinge:
ATTENZIONE: remember that there is on our FORUM community an ad hoc section dedicated to Home Assistant, for any doubt, question, information on the specific merit of these components.