Power cycle-like ESP reset

[mackowiakp]

FW ESPEasy_ESP82xx_mega-20210503 custom compilation (Custom.h)

Is it possible to perform a reset of ESP in the way power cycle-like ?
The problem is that 3 devices are connected to one ESP via I2C. Very rarely - it happened probably 3-4 times a year - something "jammed" on the I2C bus and the devices connected there, although sending data, did not make sense.
For example, the BME280 showed a temperature of 2,000 C and a pressure of 2,000 HPa.
The reset from the power supply helped.
So my question. Is it possible to perform such a reset from rule, because the standard reboot command did not help to solve the situation.

[Ath]

There is an open PR #3678 that is intended to resolve such situation of a blocked I2C bus, that could use some real life testing, I presume. You could get a build from the Github Actions page, and see if that resolves your issue.

[mackowiakp]

OK. I will try. But as I wrote, it happens very rarely, so I don't know when I will be able to write something about the results.
But such a "reset" as from power cycle would be useful ....

[Ath]

The trick to get that working would be a relay with a short timer, that can be triggered to off by the ESP, and would restore power in a couple of seconds (10..20), after which the issue would be solved as well, but I'd prefer a software-controlled solution, and possibly a fix in the Arduino base libraries, as it seems that's where the root-cause possibly is.

[mackowiakp]

Yes, using for example 4541 based timer + relay or transistor resolve the problem. But it is additional hardware, soldering etc.
I just looking for simpler way that is via software (forcing hardware watchdog reset or so).

[TD-er]

You can temporarily swap the SDA and SCL pins (in the settings) and restore them after saving it.
This will also clear the blocked I2C bus.
Still not a very nice fix, but at least it helps for those units at unreachable places.

[ThomasB]

The trick to get that working would be a relay with a short timer, that can be triggered to off by the ESP, and would restore power in a couple of seconds (10..20), after which the issue would be solved as well

A Relay might not be needed for this solution. Perhaps it can be simplified by connecting the ESP device's reset pin to a spare GPIO pin (any GPIO that is not used for Boot mode or serial port). Leave the GPIO configured as default in hardware settings. Use a rule event to set the pin logic low (GPIO,<gpio>,0) whenever the hard reset is needed.

For example, connect GPIO14 (D5) to RST.
Use web browser to call the HardReset Event. Use this rule:

Code: Select all

on HardReset do
     gpio,14,0
endon

Or maybe a rule could be created that automatically checks for a hung I2C. For example, periodically read the state of the SCL pin. If it is stuck at a logic low then call the HardReset event.

Untested ideas, offered for your amusement only.

- Thomas

[mackowiakp]

Yep, good idea. Will test !

[mackowiakp]

After quick test on prototype ESP, I can say it works. But the problem is with desired device.
All GPIOs that do not change state during boot are busy and unfortunately must remain so.
But the D5 changes state for each minutes, resetting/force "sleep" the dust sensor. Dust sensor has a very limited LED lifetime (8,000 hours), so I turn it on every 10 minutes for 30 seconds, measure air quality and then it does to "sleep" again.
So I can only use this fact, modify the rule accordingly and connect a simple 4541 based timer to D5 + transistor. If there is no reset 4541 from D5 for 11 minutes, the transistor will reset the ESP.
I use a similar solution in RPi, where the hangs of the system as a whole is not a result of a software error or RPi itself, but a temporary malfunction of one of the peripheral devices. For example, due to a lightning strike.
So still power cycle-like reset would be much easier to do....

[ThomasB]

All GPIOs that do not change state during boot are busy and unfortunately must remain so.

That is unfortunate that a spare GPIO is unavailable.

However, do you have anything wired to the GPIO-2 (D3) boot pin? If it is free then I have an idea.

- Thomas

[mackowiakp]

Dont know at this moment. Probably no. I have to check during a day (at this moment is 3:30 AM in my country).
The unit is located 20 m from my house.
Your idea sounds good. Will test ASAP.

[ThomasB]

I just tried out my GPIO-2 workaround idea. It won't work. So for now I am out of easy-to-implement ideas.

Hopefully the firmware solution in PR #3678 solves this for you.

- Thomas

[mackowiakp]

So external hardware timer/watchdog seams to be solution for actual and future problems.
Lets solder 15 cents worth IC to external board.

[mackowiakp]

Wait, I have GPIO5 (D1) free ! Be so kind to test. Its totally independent input/output !

[ThomasB]

Wait, I have GPIO5 (D1) free ! Be so kind to test. Its totally independent input/output !

Are you sure GPIO-5 is free? Normally it is used for I2C SCL.

If this pin is indeed free then give it a try. Be sure to check the device's /hardware page and confirm that GPIO5's "GPIO boot states" is set to default. No other entries should specify GPIO-5.

- Thomas

[mackowiakp]

Yes, its free for sure. In my case I2C use GPIO2 (SCL) and GPIO4 (SDA). I made a lot of changes/tests during the lifetime of this particular unit and some things are in non-default place.

[ThomasB]

FWIW, I tried GPIO-5 and it works for me (remote reboot success). So hopefully this simple GPIO based hardware reset idea solves your problem.

- Thomas

[mackowiakp]

Yep, for me working too. Using additional transistor to inverse signal level.

[ThomasB]

Great. Glad it's working.

I simply jumped GPIO-5 to RST with a piece of wire. The transistor seems redundant. But I suppose you prefer writing GPIO,5,1 instead of GPIO,5,0.

- Thomas

[mackowiakp]

All you need was a cable? Not in my case. GPIO5 shorted to GND at boot time for a fraction of a second, causing boot-loop.
Hence, I had to use an intermediate transistor.
You see "Chinese copy of the Chinese copy" of nodeMCU does not equal other "Chinese copy of the Chinese copy"
Anyway, this is not the first time I have encountered something like this.

[TD-er]

Shorting GPIO-5 to GND may draw too much current from the ESP if it was high.
ThomasB did mention to connect GPIO-5 to RST.

[mackowiakp]

My part of ESP shorts GPIO5 to GND itself during boot time (for a fraction of sec). Why? I really dont know. It should not.
I just connected transistor to GPIO5 via resistor and transistor shorts RST to GND when command GPIO,5,1.
That's just for the more precise explanation.

[TD-er]

Hmm that's strange.
GPIO-5 should be "safe to use for relays" .
See also the links I put on this page: https://espeasy.readthedocs.io/en/lates ... on-esp8266

[mackowiakp]

Yes, its strange but its a feature of my one personal ESP. I check another one, works as docu stands. "Chinese copy of Chinise copy..."

[mackowiakp]

Today the device hanged itself for the first time. As a result, the GPIO rule-initiated hard-reset did not work.
I know for sure that there was a hanging, because the simple rule "LED blinking" did not work. The LED was on all the time, not blinking.
The power cycle helped.
So I will have to use an additional external hardware watchdog based on timer 4541.
If the timer is not reset, let's say - for 5 minutes, it will turn off for a while (via relay) the power to everything (including timer 4541) .