I have a QS-WIFI-S04-2C and integrated it as already documented here:
However, on power on the device sets the outputs to ON which I do not like. I want to use it for a cover and don’t want the cover to open / close on a power loss.
So I investigated, the device is able to beep and I also added some logs:
sensor:
# Duty cycle sensors for switch inputs "S1"
- platform: duty_cycle
pin: GPIO13
internal: true
id: ${short_name}_in_switch1_sensor
name: "${short_name} Switch 1 Sensor"
update_interval: 20ms
binary_sensor:
# Template binary switch sensors monitor duty cycle sensors on GPIO pins.
- platform: template
id: ${short_name}_switch_1
name: "${friendly_name} Switch 1"
internal: true
lambda: |-
if (id(${short_name}_in_switch1_sensor).state < 95.0) {
ESP_LOGD("cover", "1: True");
return true;
} else {
ESP_LOGD("cover", "1: false");
return false;
}
on_click:
then:
- output.turn_on: buzzer
- delay: 250ms
- output.turn_off: buzzer
- light.toggle: ${short_name}_1
I expected the duty cycle sensor to produce a wrong state at startup, but the logging shows that this is not the case. Instead I get a beep on every boot which shows that on_click is triggered on boot even if the lambda is false.
To solve this I implemented a wait time of 1s until the device accepts input (a hack ?):
- defined a global variable wait_on_init, initialised with false
- set it to true 1s after boot
- do not accept on_click or duty_cylce changes when wait_on_init is false
esphome:
...
on_boot:
priority: -100
then:
- delay: 1s
- lambda: 'id(wait_on_init) = true;'
globals:
- id: wait_on_init
type: bool
restore_value: no
binary_sensor:
- platform: template
id: ${short_name}_switch_1
name: "${friendly_name} Switch 1"
internal: true
lambda: |-
if (id(wait_on_init) == false) {
return false;
} else {
if (id(${short_name}_in_switch1_sensor).state < 95.0) {
return true;
} else {
return false;
}
}
on_click:
then:
- if:
condition:
lambda: 'return id(wait_on_init) == true;'
then:
- light.toggle: ${short_name}_1
The first if in the lambda is not needed, the if in the on_click handler solves the problem. So now my question: why is the on_click handler triggered on power up and how would you avoid this? Is my solution ok? I would like to understand what is going on here.