I have a running configuration on a ESP01S board compiled with ESPhome 1.16.2
Now I have updated ESPHome to 1.18.2. Compiled project without changing the YAML. But my GPIO binary sensor doesn’t work anymore.
# esphome configuration Raumfeld Speaker common definition
packages:
wifi: !include wifi.yaml
web_server: !include web_server.yaml
mqtt: !include mqtt.yaml
time: !include time.yaml
sensor: !include def_sensor.yaml
text_sensor: !include def_text_sensor.yaml
esphome:
name: ${node_name}
platform: ESP8266
board: esp01_1m
captive_portal:
logger:
api:
password: !secret api_passwd
ota:
password: !secret ota_passwd
binary_sensor:
- platform: gpio
name: ${verbose_name}_is_online
id: ${node_name}_is_online
pin:
number: GPIO0
mode: INPUT_PULLUP
inverted: true
switch:
- platform: gpio
name: ${verbose_name}_relay_0
id: ${node_name}_relay_0
restore_mode: ALWAYS_OFF
pin: GPIO3
icon: "mdi:speaker-wireless"
on_turn_on:
- switch.turn_on: led
- delay: 500ms
- switch.turn_off: ${node_name}_relay_0
- switch.turn_off: led
- platform: gpio
# Verwenden wir nur zur Kontrolle. Ist per 10k Pullup auf High
pin: GPIO2
id: led
inverted: true
internal: true
The binary sensor for GPIO0 (id ${node_name}_is_online) never gets state ON.
I have tried to compile the project with ESPHome 1.17.0. And found that this behavior started with the 1.17.0 release. As soon as I upload my project compiled with 1.16.2. everything worked as excpected and I get state ON.
Am I missing an important change in GPIO definition? Has checked release notes but didn’t found a reason for the change/failure?
maybe someone could give me some help where I could start with my search?
I do not see anything wrong with your configuration as presented. But without the package includes I can not be 100% sure.
You might have a situation of more memory usage or a failing device. I would enabled debug/verbose logging and monitor the device via serial or API log (serial is probably best) and toggle that input if you can to monitor the additional logs.
Verbose (or very verbose) logging is the next step. Seriell logging is not so easy. ESP01 and the module is mounted inside a speaker.
What makes me thinking it has to be something changed since 1.17.0:
I upload a binary compiled with 1.16.2 OTA. Everythings fine. Binary input is ON.
I upload a binary compiled with 1.17.0 (or newer) without changing a single line of code: Binary input is OFF after reboot of ESP.
Nothing else changed. Input GPIO0 hardware signal is low all the time.
Upload binary from version 1.16.2 OTA: After reboot the binary sensor is ON as it should.
I have activated web GUI, MQTT and HA integration. All three show the same state for GPIO0. So it has to be a problem with binary sensor GPIO.
In the debug log I didn’t see any state change for the binary input, if I change the hardware state (low to high and vice versa) for that GPIO.
If needed, I could also post the package includes.
I have quite a number of binary sensors and all work fine. But, maybe you can try to upload FW without that ${… names. I don’t have them, so it’s another thing to try…
Unfortunately, I could not try it out today. A little bit busy today. In Germany tomorrow starts a long weekend.
So I will build a test system next week. And try if it is because of the naming.
As soon as I know more, I’ll let you know. I thought it might be a general problem with the update. But as it looks, the error occurs probably only with me. Maybe its related to the limited resources in ESP01?
But I am happy if someone could give some tips in debugging/logging the GPIO pins inside ESPHome. As I could see in the source there is no logging enabled. And I don’t know if it is possible to use logger in ISR code?
I had a little time to do further testing.
After building a test environment, I see everything is working with 1.18.0.
Then I updated all (I have four identical modules) modules to a new firmware compiled with ESPHome 1.18.0. They share all the same code (using packages. Only changing the node name using substitution).
Two of the four modules are working. GPIO 0 is correctly signaled as with ESPHome 1.16.2
Now I have to find the reason why 2 out of the 4 didn’t work with ESPHome 1.18.0. Very strange.
Maybe someone has tips what I could look for why GPIO0 isn’t working in 2 modules?
Next I would change the ESP01 module. But that’s not so easy because I have to disassemble the speaker.
Yesterday I found time to test a little bit and maybe found the reason.
It seems from ESPHome 1.17.0 and later the Espressif Framework/Firmware changed the thresholds when the ESP module detects HIGH/LOW level on GPIOs.
Problem with my modules and implementation was, that LOW level wasn’t detected after update of ESPHome. I changed the circuit a little bit. And after lowering the LOW voltage a little bit on input GPIO0 a little bit everything worked with the new version.
I thought also that this wasn’t possible. So I do some tests around with my circuit.
ESPHome 1.16.2 everything is fine. Update to ESPHome 1.17.0 and later: GPIO0 low wasn’t detected (its inverted). GPIO0 HIGH Voltage was 3.x V and LOW Voltage was around 1.x V (I know. Not perfect but it worked through different ESPHome versions until 1.16.2).
Now I changed circuit so LOW voltage was lower by around 0.2 V. And after this it also worked with ESPHome > 1.17.0
Only thing changed is ESPHome version and the changed circuit (changed one resistor value to get LOW voltage a little bit lower). Nothing changed in the YAML file.
@tom_l Maybe you have another explanation for this behaviour? Or maybe is there some change with ESP internal pullups (is there one on GPIO0?)? Checked also with different ESP modules.
The input low voltage max was always 0.25*VDD, which is 0.825V max for a low logic.
So you were operating outside the guaranteed levels with this:
You were just lucky it worked on that particular device but it would not ever be guaranteed to work for other devices, or continue to work on that device.
There’s no way that any firmware or software could change value of internal resistors - they are either on or off. Voltage of around 1V is absolutely too high for low level, especially when power supply is only 3.3V. I don’t dare to assemble such a device even at 5V supply. I think that you were very luck when it worked. I’d go and buy a lottery ticket with such luck
My guess: changed fw somehow changed module consumption in various stages, so internal levels changed a bit, but enough not to work anymore.
BTW… if i remember, GPIO0 doesn’t have internal resistor, you must have external one (or module won’t start normally).
I know this . But it worked until 1.17.0. And as stated: the only thing changed is the ESPHome version.
Maybe that could be the reason. As @tom_l has correctly stated, I operate the ESP somewhat out of specification. And I am wondering why it stopped working after compiling the code with a different ESPHome version.
So I am encountering a similar issue with a esp8266 hooked up to an endstop. I updated and compiled software on the board yesterday and ever since the end stop sensor has just refused to detect changes in state. I have two attached to the board, one is on a 15cm length of wire, and the other is on +2m wire length. It all worked flawlessly for 9months and I finally took the plunge and updated (it was the only one that wasnt updated at the time) and now it just wont work. I am measuring about 2.56V across the pins on the end stop switch but the board is not reacting to the outputs.
No parts of the code have changed, the only thing that is different is compiling it against the new version.
I guess the 2.56V is now to low for it to trigger an on state?
Hi. So there are no errors in the ESP log on the board read out. When I press the end stop contact nothing happens. I basically have it set up to stop a 12v motor from moving beyond a set point. It worked flawlessly before I updated (with some debouncing removal using the delayed_on_off, as it would ping between off and on quite rapidly.
Stupid question but how would I measure the logic low voltage. All I did so far was measure across the pins connected to the endpoint sensor which read 2.56V. I have had to order a new multimeter as I broke the flying lead trying to debug.