[feat] - Add support for more entities

[netsoft-ruidias]

Scenario:

I have several thermostats whose integration is faulty (missing features) and I want to create a custom climate entity to replace the faulty integrations.

In this case, the faulty integration is done by the official "tuya" integration.
So I want to get the values ​​using the "LocalTuya" integration, but not creating a climate (which also works poorly), but by creating sensors, switches and others...

The Problem

Reading values from the device and getting the "ha-dual-smart-thermostat" climate in sync is simple.

Having the "ha-dual-smart-thermostat" climate setting the device values ​​is not possible out-of-the-box, I have to use automations to be able to achieve this, and that's what I wanted to avoid, as the whole process tends to get dirty quickly as we add new features.

The solution

I think the solution would be to support two new properties, an on/off switch to turn the device on or off and a "number" to set the target temperature:

power: switch.XXX_thermostat_power
temperature_set: number.XXX_thermostat_power

Operating mode

1. When the climate is turned on or off, it triggers the action: switch.turn_on or action: switch.turn_off action depending on its state
2. When a user sets a target temperature (e.g. using type: thermostat card), then the action action: number.set_value is triggered to set the value of the entity defined in temperature_set
3. The mode can already be controlled today, through the heater and cooler properties associated with a switch, although this only allows defining these two states

Future implementation suggestions (nice-to-have)

1. Allow defining a mode property associated with a select entity, which would allow several working modes to be supported
2. If the temperature_set is set, you can read the properties max_temp, min_temp and precision from that number entity (ie: max, min and step attributes).

[swingerman]

What if we were able to control other thermostats directly. I have something in my mind for some time

[netsoft-ruidias]

@swingerman Please share with us what your ideas are, and together we can brainstorm on them.

[swingerman]

My idea is to use other thermostats (those that lack features) as heaters or cooler entities. Like this this component could use those thermostats to turn on/off the underlying switches.

[netsoft-ruidias]

This is a great idea and I think the more features are supported, the more usability scenarios can be created, and that's great.

In my case, there is no need to control other thermostats, as I said, the integration is faulty, and with LocalTuya inetgration I can get switches and sensors that allow me to do what I want, however I have to use automations for to sync with "ha-dual-smart-thermostat".
If instead of using automations you could use the build-in features from "ha-dual-smart-thermostat", even better.

[jeangot]

How far away are you from potentially being able to control other climate devices? My situation is that I am trying to add a second setpoint (to have one setpoint for heating and one for cooling, critical for swing season) to a number of mini splits that only take one setpoint, and are currently exposed in my HA as climate devices.
So I am trying to create a virtual thermostat that takes 2 setpoint, and that in the back will switch the existing climate device between heating and cooling, and then I will hide the existing climate devices in the UI.
Most of the virtual thermostat implementations I am finding can control only switches, but not other climate devices, so it would be great to know if this capability is coming soon or not, so I can decide which implementation to use. Thank you.