Periodic shutdowns for 21 minutes (Wemos D1)

SultanRR · February 12, 2025, 10:57am

The problem is a spontaneous shutdown with an arbitrary frequency and each shutdown lasts 21 minutes.

esphome:
  name: "office_v2"
  friendly_name: Wemos Office

esp8266:
  board: d1_mini

logger:
  level: VERBOSE
  logs:
    switch: ERROR

api:

ota:
- platform: esphome

wifi:
  networks:
  - ssid: Pro4
    password: Milk33kg
  power_save_mode: NONE
    
  ap: 
    ssid: ProE
    password: Milk33kg

binary_sensor:
  - platform: gpio
    pin: GPIO16
    #званок двор пин D0
    name: "Alarm_dvor_D0"
    filters:
      - delayed_on: 50ms # Фильтр дребезга (задержка 50 мс)
  - platform: gpio
    pin: GPIO12
    #геркон двери пин D6
    name: "Sens_door_D6"
    filters:
      - delayed_on: 50ms # Фильтр дребезга (задержка 50 мс)
    on_press:
      then:
        - switch.turn_on: output_alarm
        - delay: 0.1s
        - switch.turn_off: output_alarm
  - platform: gpio
    pin:  
      number: GPIO14  # номер GPIO пина, к которому подключена кнопка
      #звонок офис пин D5
      mode: INPUT_PULLUP # Включаем внутренний подтягивающий резистор (обычно используется с кнопками, замыкающими на GND)
      inverted: true # Инвертируем логику
    name: "Alarm_office_D5"
    filters:
      - delayed_on: 50ms # Фильтр дребезга (задержка 50 мс)
    on_press:
      then:
        - switch.turn_on: output_alarm
        - delay: 1s
        - switch.turn_off: output_alarm
  - platform: gpio
    pin: 
      number:  GPIO01
      inverted: False
    name: "PIR Sensor Office"
    device_class: motion
    filters:
      - delayed_on: 3s

switch:
  - platform: gpio
    pin: GPIO04
    #выход(звонок) пин D2
    id: output_alarm
    name: "Alarm_D2"
  - platform: gpio
    pin: GPIO05
    #выход(звонок) пин D1
    id: output_pinD1
    name: "Pin_D1"
  - platform: template
    name: "Virt_1_Bell"
    id: output_1_bell
    optimistic: true
  - platform: template
    name: "Virt_2_Bell"
    id: output_2_bell
    optimistic: true
  - platform: gpio
    pin: GPIO2  # D4 (или другой свободный пин)
    id: my_led
    name: "info"
    inverted: True

I don 't know what to do anymore . only when working from a powerbank does it seem to work stably, when working from a usb charger (different), it turns off at random for almost always 21 minutes, it can turn off after 4 hours, or maybe after 26 hours. I tried different wires, the blocks were also different , I put ferrite rings on both the supply wire and the input wires, all the pins on the input and output are tightened to ± or cons in accordance with the operating mode of the nominal value of 2+ kOhms. Moving the access point has no effect , I also changed the vemos d1 itself to a board from another manufacturer (soldered slightly differently ) , the same effect , other vem controllers and others working in this room with the same wifi do not experience such problems with disconnection . At the same time , when hanging for this 21 minutes , if you measure the board , then the 5v before the stabilizer and after 3.3V are stable . The board starts automatically after 21 minutes ± 30 seconds. The logs are empty before this glitch.
Given such a stable shutdown for exactly 21 minutes, I think maybe this is some kind of process that can work like that , or something else … otherwise, there would have been a quick reconnect after the failure . Maybe I touched (used) a sensitive pin…

Рус:
уже не знаю что и делать . только при работе от повербанка вроде работает стабильно , при работе от usb зарядного (разных) с рандомной периодичностью отключается на почти всегда 21 минуту , может отключиться через 4 часа, а может через 26 ч . Провода пробовал разные , блоки так же разные , кольца ферритовые ставил и на питания провод и на провода входы , все пины по входу и выходу подтянуты к ± или минусы в соответствии с режимом работы номинала 2+ кОм . Перемещение точки доступа не влияет , так же менял сам вемос д1 на плату другого производителя (распаяна чуть иначе ) , тот же эффект , другие контролеры вемом и прочие работающие в этм помещении с этим же вифи не испытывают таких проблем , с отключением . При этом при зависании на эту 21 минуту , если промерить плату то 5в до стабилизатора и после 3,3в стабильны . Плата сама запускается через 21 минуту ± 30 сек . Логи пустые перед этим глюком .
Учитывая такую стабильную отключаемость именно на 21 минуту , я думаю может это какой то процесс может так работать , или еще что то … иначе после сбоя был бы быстрый реконнект . Может я какой то пин тронул(использовал) чувствительный …

Karosm · February 12, 2025, 12:08pm

Nothing comes to my mind that could cause Esp to shut down for 21min and suddenly restart by it’s own.
So your board is probably running but it just get’s disconnected from your router.
Try to reboot you router next time it happens to see if it reconnects right after.

Nick4 · February 12, 2025, 12:29pm

Power unit that is under the limit?

SultanRR · February 12, 2025, 12:34pm

this happens only when powered from the mains, it seems to work stably with the powerbank , many similar boards are connected to this access point and everything is working , but the problem is only with the board inserted into this project , and I tried to change the boards in this project , the problem does not go away. I think this is the effect of my strapping, but the strapping consists only of binary sensors and pull-up resistors.

SultanRR · February 12, 2025, 12:39pm

The 5V 3A power supply unit is claimed to produce more than 5 V

WallyR · February 12, 2025, 12:53pm

I am no electrician or real tinker with this, but it the powerbank vs the mains sounds like a common ground issue.

Karosm · February 12, 2025, 2:36pm

Might be noisy/not stabile usb charger, but it really doesn’t explain 21 minutes unknown state and recovery. If you have Samsung charger, try with that. They are quite good quality.
Neither strapping pins care about mains vs power bank.

You could use interval component to blink onboard led every x seconds to get confirmation if the board is running or not during that 21min.

SultanRR · February 12, 2025, 3:12pm

These power supplies do not share common contacts and ground contacts.

SultanRR · February 12, 2025, 3:32pm

I have tried several different power supply devices , I will also try to connect a couple of others , there is no Samsung , but there is from xiaomi , and I will also try to install a galvanic isolation unit powered by b0505s . Flashing LED built-in (gpio02) I wanted to, but I couldn’t write a working code

Karosm · February 12, 2025, 3:39pm

interval:
  - interval: 10s
    then:
      - switch.turn_on: my_led
      - delay: 300ms
      - switch.turn_off: my_led

stevemann · February 12, 2025, 3:59pm

I agree with @WallyR and @SultanRR that the only difference from the power bank and the mains would be the ground path. The voltage regulator on the Wemos D1 Mini is a ME6211, and it’s specs say that the minimum input voltage to get a stable 3.3V output is 3.4Volts. I have a couple of projects that run just fine when the input power from a crappy USB charger drops to 4V.

Like others, though, the 21 minutes is a weird one.
Write a blink configuration like @Karosm suggested.
Here is my blink:

# Blink the LED on D4 (GPIO2, LED_BUILTIN)
switch:
  - platform: gpio
    pin:
      number: D4 
      mode: output
    id: builtinLED

interval:
  - interval: 1000ms
    then:
      - switch.toggle: builtinLED

Try to narrow down the location of the fault. If the LED on your Wemos stops at 21 minutes, then you have eliminated your board and anything downstream of it. Switch Wemos D1’s and repeat.

Also, show the board schematic that you are plugging the Wemos D1 into.

nickrout · February 12, 2025, 6:57pm

Post logs.

WallyR · February 12, 2025, 7:10pm

Exactly my point.
A power supply might deliver a voltage, like 5V, but it is 5V relative to its 0V.
If you have two power supplies, delivering 5V relative to their 0V, and then look at them from a common voltage level, like the ground in the mains wire, then they might not be the same voltage at all.
One might be 20V on the positive and 15V on the negative and the other might be 30V on the positive and 25V on the negative.

If you connect these without a common ground, then when the first one goes high on a pin connected to the other, then it is not seen as high on the other.

And the relative 5V can slide, so it is not always 20V over 15V on the first one. It is just 5V relative always.

SultanRR · February 13, 2025, 8:17pm

after working for 26 hours , this glitch happened again . I added the code so that the diode would blink, and on time when in the Home ass… there was no connection , the diode kept blinking , that is, the program was running , but there was no connection . But yesterday I also connected the wemos d1 board next to the same power supply that was previously in my device , it has the same code and works with the same access point , and it works stably and does not lose connection. At the same time, the board , which in the circuit continued to flash the diode for 21 minutes when communication with the assistants was lost , but within a couple of seconds of appearing in the assistant , it was clear on the board that the diode 's blinking rhythm had lost , that is , it restarted after 21 minutes and immediately appeared in the assistant . There is no circuit on my device , I will try to draw it , but this, as for me, is a clear influence of the circuit in which the esp is located .
and this is the last thing that was in the logs :

SultanRR · February 13, 2025, 8:22pm

so two boards were connected , both installed in the device earlier were equally buggy . :

stevemann · February 13, 2025, 9:56pm

If you don’t speak in complete sentences, I can’t help you.
In troubleshooting you eliminate ONE and only one thing at a time.

Two boards is the definition of ambiguous. Say Wemos1 and Wemos2. Unless you mean the board that the Wemos is plugged into.

Here’s what your shotgun approach has revealed- the configuration is not the problem because a Wemos running blink loses API connection at 21 minutes. What about the other Wemos? Does it also fail the same way at 21 minutes?

So let’s focus on the power supply.
When you say powerbank, do you mean a battery?

By the way, I am confused about your specific issue:

I read that the failure presents at 21 minutes, or does it run for 4 hours then prsent the failure?

Turn off ?? The Wemos is not turning off because as you said the LED keeps on blinking. Be specific. Exactly how does the problem present?

SultanRR · February 13, 2025, 10:42pm

I write through a translator and try to write briefly so that there is less chance of translation errors))
Wemos is installed in the board (this board has three inputs that are binary, two of which (the bell button, the reed switch of the door opening sensor, are controlled by 0(gnd), that is, when the button is pressed or the reed switch gnd is triggered, both gpio12 and gpio14 are flushed when the button is not pressed in order to tighten these pins are tightened by resistors to 3.3V ) there is also a third button , when pressed , 3.3v and gpio16 are connected , and when it is not pressed , so that there are no false alarms , it is pulled up by a resistor to gnd ) .There are also two outputs (gpio04 and gpio05), two moc3052s are connected to them via current-limiting resistors. (a 220 volt siren is connected here) .
How the problem manifests itself: the board works stably, it can work stably for more than a day, but at some point it disappears from the home assistant, and after about 20 minutes and 30 seconds it reconnects to the assistant (the status of buttons, switches appears… ). About a week ago , I conducted an experiment and connected power to a powerbank (portable battery ) , and the board worked for at least 3 days without failures .
I’ve had this device running for about three weeks, and it’s been buggy all this time , almost all this time wemos 2 was installed (the photo above is signed), and a little over two days ago I thought maybe it was a marriage, and I changed it to wemos 1 (I wrote the same code as on wemos2).
so yesterday, on the advice of me, I added the code so that the board would blink with the built-in diode, and also decided to connect wemos2 nearby at the same time. ( I did this as an indicator if there is a problem with the access point and both boards disconnect from the assistant because of it , but wemos 2, which is not connected to my board , is working stably )
in the photo, these 3 empty spaces (marked ) this is a loss of connection, and all of these connection losses last approximately 21 minutes. (for example, the last shutdown lasted 21 minutes and 57 seconds):

stevemann · February 13, 2025, 11:28pm

That is a bit more clear. We were looking for a reason the Wemos would stop. (From your original description). Since the same issue presents itself with the blink configuration, that rules out the device configuration. Since the LED kept blinking, the Wemos was still running. It did not stop.

What are we looking at in your screenshot?

SultanRR · February 13, 2025, 11:43pm

the last screenshot shows the status history of the switch ( gpio05 ) . The screenshot shows that information about the status of the switch was lost three times from the home assistant, but here is a more relevant screenshot for the last hour there was another failure (now there are four visible ) :

stevemann · February 14, 2025, 3:29am

Lets look at something else. Ping the device using the ping integration. Does it continue pinging when the other sensor stops responding?