and while it gets the job done, I would rather breaking out Target Temperature, Operation, and Fan Mode to the main page, instead of having to click on Settings and using the popup. Can someone help point me in the right direction to achieve this?

I may not have been super clean in my question, as I have a couple groups already created with success. Here is a screen shot from @jbardi that I found this morning. He has setup exactly what I’m looking to do:

See how he has Operating Mode, Fan Mode, and Set Target Temp? That’s what I’m wanting.

It looks like he posted his group settings, and here are the relevant parts:

The first automation rule is to set operation_mode of climate.thermostat_downstairs_cooling_1_2 based on what was selected in input_select.hvac_operation_mode.

The second automation rule is to set option of input_select.hvac_operation_mode based on what the current status of states.climate.thermostat_downstairs_cooling_1_2.attributes.operation_mode is, in an attempt to keep the two synced up (in case I was to adjust the thermostat manually).

When watching the log files, it doesn’t appear that my automation rules are triggering. In fact, I see nothing in my logs to make me think automation is working (no errors, just no mention of automation). Maybe my triggers are wrong? Are there any package pre-reqs required for automation to work that I may have missed?

@tycoonbob Interested in what you’re trying to accomplish, I will try it myself. Are you trying to display the actual mode the Thermostat is operating at the time? or to show the mode that is set to?
Those are two different parameters. I’m interested in tracking if the Thermostats is actually running or not, this is the zwave Id: CommandClass id=“66” name=“COMMAND_CLASS_THERMOSTAT_OPERATING_STATE”

So basically, here is what I’m trying to accomplish. Currently, I have to click on my thermostat widget which has an additional popup window, which is where I’m able to set my Target Temperature, Operation (mode) and Fan Mode. While this works just fine, I don’t like having to click on the widget and bring that up to make changes.

So, I’ve created a group called HVAC where I want to have an input_select which will set my thermostats operation mode (Cool, Heat, Off), another input_select that will let me set the fan mode (auto, on), and an input_slider that will let me set my Target Temperature.

In trying to figure this out, my currently config (shown in post #6) has an input_select entity that lists 3 options; Cool, Heat, and Off. Basically, I want to be able to select Cool, and make my thermostat switch it’s operation mode to Cool. If I select Heat in my input_select, I want the thermostat operation mode to be set to Heat.

The reason for my second automation rule is to set the input_select field to whatever the thermostat is set to, in the even that the thermostat was change. While the first automation rule will set the thermostat operation mode based on what the input_select is set to, I want to make sure that I can change the thermostat manually (from the thermostat), while having the input_select update (because it detected a change in the thermostat’s operating mode), so it doesn’t override my manual change.

Does that make sense? Post #3 shows a screenshot that @jbardi shared in another post, which basically shows EXACTLY what I’m trying to accomplish. The picture in my first post (click on it to see the full picture) shows the popup widget, or whatever it’s called, that works but I don’t like.

Hey, sorry for not getting back with you on this issue. I’ve been out of town and tied up with some things. Glad you got it figured out. Would love to take a look at your configs. There is more than 1 way to skin a cat, and you may have a more robust setup than me that could make it more efficient

So as you can see, there are 5 automation rules. The first two are for setting the Operating Mode based on the first input_select, the second two rules are for setting the Fan Mode based on the second input_select, and the fifth rule is for setting the target temperature with the input_slider.

The first rule sets the thermostat operating mode based on the input of the input_select.

The second rule sets the input_select based on the setting of the thermostat, in the event the operating mode was changed manually from the thermostat.

The third rule sets the thermostat fan mode based on the input of the input_select (similar to rule #1).

The fourth rule sets the input_select based on the setting of the thermostat, in the event the fan mode was changed manually from the thermostat (similar to rule #2).

The fifth rule sets the thermostat target temperature based on the input of the input_slider.

I originally had a sixth rule that would set the slider if the temp was manually set, but I found that this caused a loop. Since the slider doesn’t display a value unless you tap on it, I figured there was no point in this rule, and instead added the “Target Temperature” sensor below the slider to show was it was currently set to. In fact, my group looks exactly like yours.

Mine is exactly like yours in fact… guess there aren’t too many ways to do this setup in the long run lol

I do however have the rule to change the slider when the temperature is changed manually on the thermostat. I also had the loop issue going on, because when I had it change the slider to match the temperature I manually set, it would trigger the slider to set the temperature which was already set in the first place, and on and on, but this was resolved by simply adding a condition to the automation for the slider so that the slider will only call climate.set_temperature if the slider’s new value is not already equal to the temperature attribute on the thermostat.

I don’t know why I didn’t think about adding a condition on that rule to stop the loop. Even though I don’t really need it, I’ll likely go back and add that rule back with a condition. Otherwise my OCD won’t be happy, haha.

Yeah, like you said, it is not necessary, but it is a little jarring when I go to change the slider and the number that pops up in the bubble is like 5 degrees different than the actual temperature is, also, I like to think of the slider as a direct link to the hardware, so without it being tied directly to the change, it just feels broken. I just like everything to be tied on all sides to all changes so there is never a question as to what the temperature is.

Also, in future, who knows if they may change the slider so that it always shows the temperature instead of only when you tap on it, so this way you are future proofing your layout

One more thing, I’m not sure if you noticed this or not with the CT100 (but from what I gather this applies to all Z-Wave Thermostats), you can change the temperature manually on the thermostat even if the Operating Mode is set to Auto, but Z-Wave can not, and therefore Home Assistant can’t either, so if you have your Operating Mode set to Auto and you move the slider to change the temperature, the slider will reflect the new temperature, but the thermostat will not actually change temperature, so the Target Temperature will still show the old value.

Currently in my slider automation, not only am I making sure the new value is not the same as the thermostats temperature attribute, but I am also checking if the Operating Mode is set to Auto, and if it is, I set the slider back to the old value. So visually, you will move the slider, and it will just snap back to the where it was before. This lets me know that I have to change the operating mode to either Heat or Cool before I can use the slider to change the temperature. It is a little annoying though, because if it is in Auto mode, I have to change it to Heat or Cool, then change the temperature, and finally change it back to Auto.

A better workaround for me to avoid having to do 3 steps in order to change the temperature in Auto mode, is that I am going to remove the “Auto” option from the Operating Mode input_select and then programmatically create my own auto mode instead of using the Auto mode of the thermostat. I will do this by checking the current temperature, and if the target temperature I am setting it to is higher than the current temperature, I am going to make it first set the Operating Mode to Heat, and then change the temperature. And if the target temperature I am setting is lower than the current temperature, i am going to make it change the Operating Mode to Cool and then change the temperature.

Then I will have an additional automation monitoring the actual temperature, and if it goes above the target temperature and the current Operating Mode is Heat, it will change it to Cool, and if the actual temperature drops below the target temperature and the current Operating Mode is Cool, I will have it change to Heat.

It is a bit more work, basically recreating an entire Auto mode, but again, I like to be thorough and make everything work completely with each other in all scenarios

I noticed that you were having trouble with the input_slider (target temp. has issues as well) updating when the temperature is changed on the HVAC unit.

I do not know if this is your case, but in my case I noted several entity_id’s for the HVAC system; i.e.: “/_thermostat_cooling_1_2_2…”, “/_thermostat_heating_1_2_1”. Since I used the ‘cooling’ entity as my main entity for the automation it was not updating when change was made on the HVAC unit, yet did notice that the target temperature on the ‘heating’ entity did update.

What I did was create a template to get the target temp., then triggered the automation for the slider based on the value of the template’s state.

@jfontestad Thanks for sharing your Thermostat automation, I finally used in my config, instead of using an input_slider, I used a input_select, it works as advertised!
Only problem I have is restarting home-assistant, the initial values on the input_select are not the same as the sensors. I guess because the automation has not trigger yet. Any ideas how to update the values after hass is reinitialized?
of course, if later on the sensors are updated, the change is reflected properly on the input_select
thanks again!