On Template - Home Assistant various domains are covered (Light, Switch, Vacuum, Weather, …) but not Climate. I read that there is Generic Thermostat - Home Assistant but it has a slightly different usecase. I do not want a switch to be turned on depending on the temperature.
What I want to do is to create a nice Home Assistant representation for my modbus connected heating device, so I can use it in Google Assistant. It consists of the following modbus registers:
1 register for on/off
1 register for current temperature
1 register for setpoint temperature
I can not use the Modbus “climate” platform (Modbus - Home Assistant) unfortunately because I have to do some mathematics first (the sensor shows negative values as 254 for 0 degrees etc. and negative values are relevant for my use case) and also the turning on and off is not handled there.
The description states “When in heater mode, if the measured temperature is cooler than the target temperature, the heater will be turned on and turned off when the required temperature is reached.”
For my device (sauna oven with modbus control), turning it off when the required temperature is reached, must not be done. After reaching the temperature, it self-controls to stay at that level using the temperature sensor. I can’t see any possibility to override this feature in the generic thermostat. But maybe it works when setting the hot_tolerance to some large number. I’ll try that
You mean scale and offset? That’s not enough unfortunately.
Question: What kind of thermostat doesn’t turn off heating when the target temperature is reached?
Answer: A broken thermostat.
Jokes aside, “it self-controls to stay at that level using the temperature sensor” is what the Generic Thermostat does. It has options to control its deadband (the range the ambient temperature is allowed to deviate from the target temperature before heating/cooling is resumed).
@123: I understand that Generic Thermostat does this. It sends “off” to my device when the sensor has reached the target value (+offset). That is exactly what I do not want, because the temperature regulation is much smoother when the device does it by itself. It has a temperature sensor and can do better than on/off, e.g. “30 percent on” to stay at the correct level. Because of that I just want to tell my device the target temperature (+ the on command) and let it handle the rest itself.
Get the oven into Home Assistant as a switch with the modbus integration
“Raw current temperature” as a sensor with the modbus integration, then another
“Real current temperature” with the template sensor where I do the math based on the “Raw current temperature” sensor.
“Setpoint temperature” as sensor with the modbus integration
Generic thermostat using (1) and (3) of the above (see code above).
This has one problem:
The “Setpoint temperature” is of course completely ignored and can not be set by Home Assistant. So “Hey Google, set the Sauna temperature to 80°C” doesn’t work. It only sets the internal state in Home Assistant and does not communicate with the device.
The other approach would be to use the modbus integration’s climate section:
I can not do the neccessary math, so the climate device will display “256 °C” when the sauna is at 0 °C (which is common, it’s in the garden).
So “Hey google, turn on the sauna oven” will not work.
A third approach would be to just use different entities for everything:
The modbus > template sensor for the current temperature
The modbus switch for turning the oven on and off
An input number and an automation that sends that value to the corresponding register of the modbus binding
But this has other problems:
No neat UI representation as a climate device
No representation to Google Assistant as a climate device, so voice commands would be limited to switching on and off the oven
I’m running out of ideas here. What would work but does not seem to exist would be a Template Climate integration that works analogous to the other template integrations.
Of course I also could just keep using openHAB 3 for this particular use case, but I’d prefer not having to run two home automation systems. Writing a Template Climate integration for HA seems to be the next logical step, but since I’m neither familiar with python nor the HA codebase (yet) it would seem to take a while for me to do that.
I see; it already has thermostatic control built into it.
Use an input_number and automation to set the device’s target temperature.
Attempts to use a general-purpose climate integration (like Generic Thermostat or MQTT HVAC) will run into the problem that it wants to do more than you want it to do (and attempting to circumvent it causes other problems).
I used openHAB about 3 years ago and, at the time, it had no climate/thermostat item. Does it have one now? To create a thermostat in openHAB requires using several items, it would be similar to creating a thermostat in Home Assistant by combining several entities (input_number, sensor, input_boolean, etc).
I see that. This is the reason I initially discarded the idea of using Generic Thermostat and only tried it after reading the post from @tom_l here.
In OH3 it’s actually pretty “easy”:
// Modbus
// Alle Items auf autoupdate:false, da es sonst beim Schalten zu häufigen Statuswechseln kommt, siehe https://www.openhab.org/addons/bindings/modbus/
Group e_Sauna_Ofen "Ofen" <heating> (r_Sauna) ["RadiatorControl"] { ga="Thermostat" [ roomHint="Sauna", name="Sauna Ofen" ], alexa="Endpoint.Thermostat", homekit="Thermostat" }
Number:Temperature Sauna_Ofen_Temperatur_Aktuell "Aktuelle Temperatur [%.0f °C]" <heating> (e_Sauna_Ofen, u_Persist_Change) ["Measurement", "Temperature"] { channel="modbus:data:readonly:currenttemperature:number", ga="thermostatTemperatureAmbient", alexa="TemperatureSensor.temperature", homekit="Thermostat.CurrentTemperature" [minValue=0, maxValue=100] }
Number:Temperature Sauna_Ofen_Temperatur_Ziel "Eingestellte Temperatur [%.0f °C]" <heating> (e_Sauna_Ofen, u_Persist_Change) ["Setpoint", "Temperature"] { channel="modbus:data:write2:setpointtemperature:number", ga="thermostatTemperatureSetpoint", alexa="ThermostatController.targetSetpoint", homekit="Thermostat.TargetTemperature" [minValue=20, maxValue=100] }
String Sauna_Ofen_Modus "Betriebsmodus" <heating> (e_Sauna_Ofen, u_Persist_Restore) ["OpenState"] { channel="modbus:data:write1:oven:string", ga="thermostatMode" [ modes="heat" ], alexa="ThermostatController.thermostatMode" [HEAT="heat"], homekit="Thermostat.CurrentHeatingCoolingMode, Thermostat.TargetHeatingCoolingMode" }
This creates a perfect representation of the actual device (on/off/current temp/setpoint temp) for Google Assistant.
Back to Home Assistant:
Your solution leads to the device not being controllable by Google Assistant unfortunately (see “third approach” in my post above). Or can you export an input number as part of a climate control for Google Assistant?
That would be great, can multiple entities in HA be exposed to Google Assistant so that it sees it as “one device”?
input_text (or Template Sensor; depends on whether you want to edit the value in the UI or not)
According the documentation for the Google Assistant integration, you can selectively expose many entity domains to Google Assistant. I don’t see input_number in the list but a simple workaround would be to create a Template Sensor that derives its value from the input_number (and then expose the Template Sensor to Google Assistant).
Full Disclosure: I don’t use Google Assistant so there may be better ways to do it.
EDIT
Out of curiosity, how do you make those three items in openHAB appear as “one device” for Google Assistant?
I was in a similar situation as you. My electric inertia heaters have a built-in thermostat that is much more advanced than the generic HA thermostat integration (it uses PWM on the heating element for smooth control and multiple thermo probes inside and outside of the inertia fluid). I still wanted a ‘real’ climate control in HA, mostly for consistency and the UI. I didn’t really found anything that fit and ran into the same problem as you with the generic thermostat trying to do more than what I wanted it to do.
I ended up doing what @123 suggested above, use an input_number plus automation. It works rather well, but I had to write my own climate UI control for it. I’d still be interested if you find a more generic solution to your use case.
@123: As far as I can see there is no way to map multiple HA entities to one GA device, at least not on that page. That’s why I want a “Template Climate” device that I then can expose 1:1 to GA
@HeyImAlex: Good to hear that at least I’m not the only one with this problem! I’ll have a go at creating a new “Template Climate” integration if no better solutions come up here. But that will take some time, have to get used to the HA dev environment first
in order to make an item/entity fit a voice assistant’s model is not something I’m familiar with in Home Assistant (i.e. does not exist).
The one thing I recall from openHAB is its flexibility because you model everything with just a few foundational building blocks (items). On the flip side, it meant more work because you had to define every device using a collection of basic items.
In contrast, Home Assistant has a wider variety of more complex building blocks (entities) that more closely model real-world devices (fan, media_player, lock, climate, etc). For my purposes, trading away openHAB’s exceptional flexibility for Home Assistant’s higher-order entity model was worth the switch. As a matter of fact, I recall the moment when I decided to switch is when I had to model my MQTT-based thermostat and alarm system in openHAB.
Anyway, to each their own.
FWIW, the addition of a Template Climate platform would be very useful.
I have a similar topic. My heating system is integrated into HA via MQTT, currently I have all relevant informations in different sensors, and push changes back via MQTT (e.g. the heating mode with the four buttons on the top left).
Basically I am just looking for this circle thermostat control card to control my target value (currentl an input number helper) and also display the actual temperature (reported from the heater as a sensor), the two things marked in red.
No automatic turning on/off by the thermostat or similar, only using this round card instead of my straight and quite small slider I currently have, for a better look and feel.
But from what I so far understand and read here, the thermostat is “too intelligent” for my simple request and without several workarounds and dummy values (as for example the heater switch is a must value although I do not want a switch to be turned on/off) there is no way to use this card for much simpler purposes?
I was not even aware of that integration so far. But would it bring me any advantage, compared to the disadvantage of loosing flexibility with a limited number of parameters (even though the list is very long)?
From a functionality point of view I am happy.
The heater has internal logics with an own temperature sensor etc. It has thousands of parameters where I just publish the ones being ineresting for me to HA. And also some that are changeable and that via HA I can better automate, e.g. changing some stuff dependent on presence at home. So I add functionality on top of what the heater does very good by itself.
Overall it is also a combination of floor heating and drinking water heating, I guess with the MQTT integration this would then need to be handled also as separate devices, as there is for example only one temperature_command_topic.
Currently I have sensors like
sensor:
- platform: mqtt
state_topic: "BSB-LAN/8830"
name: BSB-LAN Trinkwassertemperatur
unit_of_measurement: °C
device_class: temperature
Temperatures I change via automations that send the MQTT command based on the chosen temperature.
So what would be the overall added value to use this integration instead? Is it “only” that this would be necessary for proper usage of the thermostat card? Then I would probably rather not touch the running system, as it took some time to build together what I currently have.
MQTT HVAC will get you that because it creates a climate entity and the Thermostat card works exclusively with climate entities.
It’s not an either/or proposition; you can continue to use the MQTT Sensor integration (or other MQTT entities) to represent anything that isn’t handled by MQTT HVAC.
Climate entity is one thing. But from my understanding the thermostat card also has the logic to turn on/off a heater by comparing actual and target value (with the switch being a must parameter), and like the thread opener I do not want any logic.
The card has no logic, it’s the climate entity that does it.
You want the appearance of the Thermostat card but not based on a climate entity; you want it to use discrete sensor and switch entities.
Maybe there’s a custom card that can do that but I don’t know of one. Most users employ a climate entity and use an automation to control its operation (based on schedule, presence, etc).
I’m looking for a similar thing - I have a portable air conditioner that I want to control with HA. It has its own thermostat and the only thing I want to do is control the target temperature and fan speed. This happens with infrared, I’ve got all the codes for it, I’m now just looking at the best way to represent this in HA, lovelace and google assistant.
I’ve done a similar thing with a Dyson AM6, using the fan template. In that implementation, nodered deals with most of the clunky stuff around infrared commands being sent. In summary, the fan object isn’t directly connected to the infrared commands, rather, nodered triggers the infrared commands based on things that happen in the fan. The commands happen to be switches in HA, which is just what ESPHome creates via the remote_transmitter.transmit_raw action turn_on_action.
Reading this thread, I can see why a climate template would be really useful - a dumb climate object which doesn’t do anything per se, but can be used to programmatically do things elsewhere.
But there might be a workaround - I’m thinking aloud here - if I somehow get something (say, an ESPHome device) to create a climate object with a boolean switch which does nothing, this could be used to satisfy HA’s requirement for a switch, and I might be able to use nodered to hook into the events being triggered by changing temperature, fan speed, mode, etc. and not care about whether HA wants the AC on or off.
Maybe someone has already tried this and run into problems?
I know this is an old thread, but there was no workable solution posted. If you are in the same situation, have a look at the smartir add on. It can be used to do what people are asking for.
