Thanks, this works exactly as wanted…
# Blink the green LED
switch:
- platform: gpio
pin:
number: D3
mode: output
id: greenLED
interval:
- interval: 500ms
then:
- switch.toggle: greenLED
esphome:
on_boot:
priority: -100
then:
- output.turn_on: my_slow_pwm
This will probably use less CPU cycles than the other method, but either willl work.
Still not working…
esphome:
name: wemosswitch
platform: ESP8266
board: d1_mini
on_boot:
priority: -100
then:
- output.turn_on: my_slow_pwm
All it does it turn on the LED. I am using the Wemos D1 Mini, and I am pretty sure that all sixteen GPIO pins can be PWM.
Any other thoughts?
This is Slow PWM so it is software PWM not hardware based. That means it doesn’t matter what pin as long as it supports digital out.
I have used this method before but it’s been a while - if I get a chance later I’ll breadboard it and see if I can get it to work myself.
Thanks. I appreciate the help as I am still struggling with learning ESPHome. (I barely grok Home Assistant and YAML).
Using PWM is definitely interesting as a concept. But I don’t see a reason why the processor load of a software PWM should be lower than that of the interval code of ESPHome. Both will work using timer interrupts.
True @Jpsy - the only way of knowing would be to dig into the source which I am not interested in doing.
The only reason I suggested it is that I have used it before - but it’s behaving differently I think - from memory as that project is long gone.
This works as I expect:
esphome:
name: wemosswitch
platform: ESP8266
board: d1_mini
on_boot:
priority: -100
then:
output.turn_on: my_slow_pwm
output:
platform: slow_pwm
pin: GPIO5
id: my_slow_pwm
period: 1000ms
inverted: true
min_power: 0.01
max_power: 1.00
Which is longer to type than your method. 
1 Like
This does work- sort of. “Duty” does not show in the docs for slow_pwm or output, but I discovered through googling that the output.set_level action is what I was looking for.
I did not need:
min_power: 0.00
max_power: 1.00
because 0 and 1 are the default values.
Also inverted: true is redundant with a 50% duty cycle.
Here is my working code, in case someone wants to simply blink an LED. (AKA, “Hello World”). [I could not get here without the help of everyone who replied to my query.]
esphome:
name: wemosswitch
platform: ESP8266
board: d1_mini
#For blinking the greenLED
on_boot:
priority: -100
then:
- output.turn_on:
my_slow_pwm
- output.set_level:
id: my_slow_pwm
level: "50%"
output:
platform: slow_pwm
pin: D3
id: my_slow_pwm
period: 100ms
ALSO:
This also works and is easier to write. The only downside is that the log posts every time the LED blinks.
2 Likes
The logger component can be deactivated, but I guess this does not drain any major resources as long as the ESPHome add-on is not connected and listening to the log, which it normally is not.
I have to correct myself:
Just days after your questions I needed a “blink” in one of my own projects. And I realized that the switch component does not only write to the log but also creates a HA entity that will generate a lot of history data when changing every second or so.
The better solution to blink a LED without creating a HA entity is the output component. As this component does not have a toggle action, you must use a turn_on / delay / turn_off automation.
Here is the code:
# Blink the green LED
output:
- platform: gpio
pin:
number: D3
mode: output
id: greenLED
interval:
- interval: 500ms
then:
- output.turn_on: greenLED
- delay: 250ms
- output.turn_off: greenLED
By varying the delay you can even change the pulse width of this solution.
2 Likes
Thanks for the tip. I hadn’t thought of the log since I am running on an Intel NUC with 250gb of SSD, so the size of the log file won’t be an issue for years.
Out of curiosity, and for my education, what in my code above creates an HA entity? (Remember, I am a total novice in HA, let along ESPHome).
The switch component automatically creates corresponding HA entities for each ESP entity and it syncs all changes back and forth with the associated GPIOs.
The output component does not create any corresponding HA entities. So with output you create access to the GPIOs that is only meant to be used internally by ESP logic but not mirrored to HA.
The relevant change was simply to replace “switch” by “output”.
1 Like
Thanks. That is good to know and it goes into my notebook.
What else will create an entity?
Most components do. But you will have to read the docs.
If a component always creates a HA entity, you often find a Lovelace screenshot of the resulting entity.
Example: GPIO Switch — ESPHome
For other components the creation of a HA entity can be suppressed by configuration.
Example: Sensor Component — ESPHome (with config param internal)
1 Like
Thanks for the tip.
Sorry to necro, but has anyone got this working with a Binary light? Specifically I want a light that blinks while it is turned on, but I can turn it off. I can see that
- Pulse doesnt work with binary light
- Strobe effect seems broken on binary light
- The slow_pwm approach doesnt work for me at all, it is just on.
- The interval approach doesnt seem to have a way to turn it on or off…
Hi,
Anyone can help me to traslate this
irsend.mark(1000);
Irsend.space(1000);
To
esphome:
name: wemosswitch
platform: ESP8266
board: d1_mini
#For blinking the greenLED
on_boot:
priority: -100
then:
- output.turn_on:
my_slow_pwm
- output.set_level:
id: my_slow_pwm
level: "50%"
output:
platform: slow_pwm
pin: D3
id: my_slow_pwm
period: 1000ms
Regards
esphome:
name: capteur-lumiere
friendly_name: Capteur Lumière
platform: ESP8266
board: d1_mini
on_boot:
priority: -100
then:
- output.turn_on:
my_slow_pwm
- output.set_level:
id: my_slow_pwm
level: "50%"
output:
platform: slow_pwm
pin: GPIO2
id: my_slow_pwm
period: 1000ms
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "jb+VhPzw4jcnk39tggF1zs1saWQF1h2r0+J16Tla/mM="
ota:
password: "ba9ea2bb85379b7b4d61bec42747202e"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
manual_ip:
static_ip: 10.10.10.190
gateway: 10.10.10.1
subnet: 255.255.255.0
dns1: 10.10.10.1
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Capteur-Lumiere Fallback Hotspot"
password: "01234567"
captive_portal:
i2c:
sda: GPIO4
scl: GPIO5
scan: True
switch:
- platform: restart
name: Reboot Capteur de Lumière
sensor:
- platform: bh1750
name: "Capteur de lumière"
address : 0x23
update_interval : 20 s
- platform: uptime
name: En marche depuis
id: uptime_sensor_days
update_interval: 60s
on_raw_value:
then:
- text_sensor.template.publish:
id: uptime_human
state: !lambda |-
int seconds = round(id(uptime_sensor_days).raw_state);
int days = seconds / (24 * 3600);
seconds = seconds % (24 * 3600);
int hours = seconds / 3600;
seconds = seconds % 3600;
int minutes = seconds / 60;
seconds = seconds % 60;
return (
(days ? String(days) + "d " : "") +
(hours ? String(hours) + "h " : "") +
(minutes ? String(minutes) + "m " : "") +
(String(seconds) + "s")
).c_str();
time:
- platform: homeassistant
id: homeassistant_time
text_sensor:
- platform: version
name: Version
- platform: wifi_info
ip_address:
name: IP
bssid:
name: BSSID
ssid:
name: SSID
- platform: template
name: Dernier push
id: uptime_human
icon: mdi:clock-start