Yes, I appreciate that (as that’s how I’m currently doing it), it’s just how to also change that via another ‘device’? Like an ESP32 with Up/Down buttons or for testing, an existing Ikea / Hue ZigBee remote?
With ESPHome.
With an automation.
I ‘get’ the ESPHome thing (conceptually, I don’t have the skills myself) but I tried creating an automation and was able to select the trigger (Ikea / Hue Up / down button presses as triggers) but then not what to select in the Action to make anything happen to the generic_thermostat?
So do I look for the state you suggested ( climate.lounge) or do I have to create some form of intermediate code?
FWIW I’ve just set a Ikea Up/Down where the Up press sets the target temp to 1 DegC (as confirmed on my generic_thermostat Card) and that works but not what I really need, and that is to increment it by say 1 DegC?
You select a desired service call, like climate.set_temperature.
It’s documented in the link I posted above.
If you want to increment/decrement the existing target temperature, use a template to compute it.
Post the automation you created and I can show you how to employ a template.
alias: New Ikea Up target temp
description: ""
trigger:
- device_id: d7801919c3628a93bbb9bb67b76594eb
domain: zha
platform: device
type: remote_button_long_press
subtype: dim_up
condition: []
action:
- service: climate.set_temperature
metadata: {}
data:
temperature: 1
target:
entity_id: climate.lounge
mode: single
alias: New Ikea Up target temp
description: ""
trigger:
- device_id: d7801919c3628a93bbb9bb67b76594eb
domain: zha
platform: device
type: remote_button_long_press
subtype: dim_up
condition: []
action:
- service: climate.set_temperature
metadata: {}
data:
temperature: "{{ state_attr('climate.lounge', 'temperature') + 1 }}"
target:
entity_id: climate.lounge
mode: single
Wahey! It worked, first time, thanks! (Very much).
So I would create a second automation that would allow me to set the target temperature so that bit is covered. The next bit would be reading the lounge temperature sensor and reporting that on a repeater display and also somehow displaying the target temperature for a few seconds as I change it.
That will have to be for another day, got to go visit my Mum in hospital as she had a stroke before xmas … ;-(
Thanks again. 
You can put more than one trigger into a single automation.
I’m guessing that when you press the “down” part of the button it produces a dim_down subtype instead of dim_up. If my guess is correct then the following version should work (otherwise not).
alias: New Ikea Up Down target temp
description: ""
trigger:
- id: '1'
device_id: d7801919c3628a93bbb9bb67b76594eb
domain: zha
platform: device
type: remote_button_long_press
subtype: dim_up
- id: '-1'
device_id: d7801919c3628a93bbb9bb67b76594eb
domain: zha
platform: device
type: remote_button_long_press
subtype: dim_down
condition: []
action:
- service: climate.set_temperature
metadata: {}
data:
temperature: "{{ state_attr('climate.lounge', 'temperature') + trigger.id | int(0) }}"
target:
entity_id: climate.lounge
mode: single
You may also consider using an existing automation blueprint designed for your particular model of IKEA button. The blueprint understands all of the button’s events and makes it easier for you to compose the automation. I don’t know the model you have so here’s a list of blueprints containing the word “Ikea”.
https://community.home-assistant.io/search?q=Ikea%20%23blueprints-exchange
Very sorry about your mother’s health. I hope she will be able to recover from the stroke.
Thanks once again, that works perfectly and is sufficient as the proof_of_concept for me and this project.
It’s also fairly usable ITRW as I know a single up / down button press will increment the temperature one degree.
Now it’s just a matter of seeing if I can Frankenstein the CO2 monitor code to handle the display bit.
esphome:
name: co2-sensor-2
platform: ESP32
board: "featheresp32"
# Enable Home Assistant API
api:
ota:
wifi:
ssid: !secret wifi_k_ssid
password: !secret wifi_k_password
# use_address: 192.168.0.207
manual_ip:
static_ip: 192.168.0.198
gateway: 192.168.0.100
subnet: 255.255.255.0
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Co2-Sensor-2 Fallback Hotspot"
password: "secret"
captive_portal:
logger:
level: DEBUG
logs:
component: ERROR
# CO2 sensor
uart:
rx_pin: 27
tx_pin: 26
baud_rate: 9600
# Dipslay driver: ST7789
spi:
clk_pin: GPIO18
mosi_pin: GPIO19
font:
- file: "Oswald-Light.ttf"
id: font_70
size: 70
glyphs: 0123456789 # Only used for CO2 level
- file: "Oswald-Light.ttf"
id: font_30
size: 30
color:
- id: color_black
red: 0%
green: 0%
blue: 0%
white: 0%
- id: color_green
red: 0%
green: 100%
blue: 0%
- id: color_yellow
red: 100%
green: 100%
blue: 0%
- id: color_orange
red: 100%
green: 55%
blue: 0%
- id: color_red
red: 100%
green: 0%
blue: 0%
- id: color_white
red: 100%
green: 100%
blue: 100%
display:
- platform: st7789v
model: TTGO TDisplay 135x240 # added bit
id: my_display
backlight_pin: GPIO4
# allow_other_uses: true
cs_pin: GPIO5
dc_pin: GPIO16
reset_pin: GPIO23
# brightness: 100%
rotation: 270
pages:
# Page 1: Current CO2 levels
# 0 - 1000 -> Green
# 1000 - 1600 -> Yellow
# 1600 - 2000 -> Orange
# >2000 -> Red
- id: page1
lambda: |-
if(!id(co2_sensor_2).has_state() ){
it.print(
it.get_width()/2,
it.get_height()/2,
id(font_70),
color_white,
TextAlign::CENTER,
"Starting..."
);
return;
}
auto bg_color = id(color_black);
auto text_color = id(color_green);
auto co2 = id(co2_sensor_2).state;
if(co2 > 1000) text_color = id(color_yellow);
if(co2 > 1600) text_color = id(color_orange);
if(co2 > 2000){
text_color = id(color_white);
bg_color = id(color_red);
}
it.filled_rectangle(0, 0, it.get_width(), it.get_height(), bg_color);
it.printf(
it.get_width()/2,
it.get_height()/2,
id(font_70),
text_color,
TextAlign::CENTER,
"%.0f",
co2
);
# Page 2: WiFi information
- id: page2
lambda: |-
it.print(
0, 0,
id(font_30),
id(color_white),
"WiFi details"
);
it.printf(
0, 30,
id(font_30),
id(color_white),
"%s",
id(wifi_ssid).state.c_str()
);
it.printf(
0, 60,
id(font_30),
id(color_white),
"%s",
id(wifi_ip_addr).state.c_str()
);
#switch:
# - platform: gpio
# pin: GPIO4
# allow_other_uses: true
# id: backlight
# internal: true
sensor:
- platform: mhz19
co2:
name: "CO2 Sensor 2"
id: "co2_sensor_2"
temperature:
name: "CO2 sensor 2 temperature"
internal: true
update_interval: 60s
automatic_baseline_calibration: false
- platform: wifi_signal
name: "CO2 sensor 2 WiFi"
update_interval: 60s
text_sensor:
- platform: wifi_info
ip_address:
internal: true
id: wifi_ip_addr
ssid:
internal: true
id: wifi_ssid
binary_sensor:
# Button to cycle through pages on the display
- platform: gpio
pin:
number: GPIO35
inverted: true
id: button_1
on_click:
then:
- display.page.show_next: my_display
- component.update: my_display
# Button to toggle the backlight (for use at night)
#- platform: gpio
# pin:
# number: GPIO0
# inverted: true
# id: button_2
# on_click:
# then:
# - switch.toggle: backlight
button:
- platform: restart
name: "CO2 sensor 2 restart"
You’re welcome!
Please consider marking my post above with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has been resolved. This helps users find answers to similar questions.
For more information about the Solution tag, refer to guideline 21 in the FAQ.
I forgot to thanks you for your kind thoughts re my mum (93).
Whilst this stroke seems to have hit her quite hard, she has always been strong and I’ve noticed the improvement in her left leg, since we started helping with the physio.
It’s all just more things to have to deal with, my Mrs was diagnosed with dementia at the beginning of last year and me with prostate cancer soon after.
But at least we have all lived a reasonable and happy lives so far and are thankful we aren’t being bombed in our beds.
1 Like
HI,
I now have the current lounge temperature value being displayed on the Switchbot Meter temperature and humidity sensor (with inbuilt LCD display), on HA on the generic_thermostat card and now (with some help), on a TTGO ESP32 with integrated TFT display.
What I would like to do now is to also display the target temperature as set on the generic_thermostat but don’t really know where / how to approach that one?
This is the code I used to get the current temp on the display:
- id: page1
lambda: |-
it.printf(
it.get_width()/2,
it.get_height()/2,
id(font_40),
color_red,
TextAlign::CENTER,
"%s °C",
id(temp).state.c_str());
Along with:
text_sensor:
- platform: homeassistant
name: "Lounge temperature test"
id: temp
entity_id: sensor.meter_1676_temperature
This is the (your) automation I am currently using to adjust the generic_thermostat from an Ikea remote. I should be able to transfer that function to the same ESP32/display as mentioned above.
alias: New Ikea Up Down target temp
description: ""
trigger:
- device_id: d7801919c3628a93bbb9bb67b76594eb
domain: zha
platform: device
type: remote_button_short_press
subtype: turn_on
id: "1"
- device_id: d7801919c3628a93bbb9bb67b76594eb
domain: zha
platform: device
type: remote_button_short_press
subtype: turn_off
id: "-1"
condition: []
action:
- service: climate.set_temperature
metadata: {}
data:
temperature: "{{ state_attr('climate.lounge', 'temperature') + trigger.id | int(0) }}"
target:
entity_id: climate.lounge
mode: single
The last thing will be to see if I can change the colour of the thermostat text, depending on what’s going on. Like with the generic_thermostat turned off it could just display the current temperature in white. If it’s on then the target temperature could be also there but in green if met and red when heating?
All just a pipe dream as far as my coding and understanding of it all is concerned …
Maybe I have misunderstood your request but it seems like it’s related to ESPHome. If it is then I don’t have the expertise to help you with that.
Ah, thanks for the prompt reply anyway.
In answer to my own question and in case it helps anyone else, to ‘expose’ the target temperature of the thermostat I added some code to configuration.yaml
sensor:
- platform: template
sensors:
lounge_thermostat_target:
friendly_name: "Lounge thermostat target temp"
unit_of_measurement: 'degrees'
value_template: "{{ state_attr('climate.lounge', 'temperature') }}"
And then in my ESP32/TTGO display:
sensor:
- platform: homeassistant
name: "Lounge temperature actual"
id: temp
entity_id: sensor.meter_1676_temperature
- platform: homeassistant
name: "Lounge temperature target"
id: target
entity_id: sensor.lounge_thermostat_target
And to display it on the TTGO/ESP/TFT:
display:
- platform: st7789v
model: TTGO TDisplay 135x240
id: my_display
cs_pin: GPIO5
dc_pin: GPIO16
reset_pin: GPIO23
rotation: 270
pages:
- id: page1
lambda: |-
it.printf(
110, 0,
id(font_50),
color_white,
"%.1f °C",
id(target).state);
it.printf(
110, 60,
id(font_50),
color_white,
"%.1f °C",
id(actual).state);
I’m not suggesting that this is a good solution or coding, just that it seems to work and is still a ‘work in progress’.
Thanks to all who helped me get this far.
Hi Taras,
I have been using the Ikea rocker switch to manually adjust the generic_thermostat temperature with great success (using the code you offered above) and also have the actual and target thermostat temperature being displayed on an ESP32 TTGO T-Display.
I have also just added a couple of additional automations to allow the same rocker switch to turn the general_thermostat on/off, but wondered if it could all be combined in one, as per your fist solution?
This is the .yaml for the on automation:
alias: New ikea long hold heater on
description: ""
trigger:
- device_id: d7801919c3628a93bbb9bb67b76594eb
domain: zha
platform: device
type: remote_button_long_press
subtype: dim_up
condition: []
action:
- service: climate.turn_on
metadata: {}
data: {}
target:
entity_id: climate.lounge
mode: single
Or should it all be dooable easier using the blueprint?
Yes, you can combine it, using a choose ot if then in the automation’s action section to determine which trigger occurred via its trigger.id. Or just leave it as a separate automation.
Thanks for the reply. Whilst leaving it as one (or more) additional automations makes it easier for me, it always feels ‘inefficient’? Is it do you know please?
Also, I was hoping to be able to toggle the general_thermostat on/off using one button but I don’t think ‘toggle’ is an available option?
I think it’s just a choice of how to organize all the parts involved in a given application (one automation or more).
Correct. There’s no climate.toggle service call.
1 Like