ESP8685-WROOM-03 ESP32c3 OTA update

[TommoT1]

Hi there!
I have just replaced the chips in two MEROSS Smart Power Strips with the mentioned ESP8685-WROOM-03 H4 wich is an ESP32c3 with 4MB Flash.
I flashed the firmware ESP_Easy_mega_20240414_normal_ESP32c3_4M316k_LittleFS_CDC.factory.bin before mounting them into those Power Strips.
Everything now works fine except an OTA update.
There is no failure message or anything else, it just takes forever until the browser reports that there is no reply anymore.
Flashing via serial is also not easy anymore as the RX and TX lines are now wired to some transistors who turn relays on and off.

Any suggestions?

Regards Tom

[Ath]

Everything now works fine except an OTA update.
There is no failure message or anything else, it just takes forever until the browser reports that there is no reply anymore.

This is a known issue related to the current Arduino 3.0 framework, and is being investigated.
It sometimes helps to enable Arduino OTA in the Tools/Advanced page (assuming that's available). Maybe after a few retries.

[TD-er]

You can also try to disable all tasks and controllers temporary to make sure the ESP is processing as little interrupts as possible during the OTA update.

[TD-er]

I just updated the build on the web flasher: https://td-er.nl/ESPEasy/latest/

Maybe the fixes made in that build will also help to get a higher success-rate on future OTA flashes.

[TommoT1]

OK, thanks for the help,
I did a factory reset on the node and then tried the OTA update, so it had as few tasks as possible but no help.
The webflasher page ist at the moment not available but therefore I have to desolder the chips anyway.
I'll wait till another node arrives via mail and then try while it is not soldered somewhere.
Is this problem just one the C3 or on all ESP32?

[TD-er]

I have no clue to be honest why this may happen.
What I've seen is that some ESP32 nodes did have issues lately with OTA updates.
But the ones I noticed issues with mainly had 16M flash and thus the biggest (MAX build) uploads.

Also the unit was totally unresponsive when the OTA failed, so I had to reboot the unit.

I did perform quite a lot of OTA updates on a C3 unit, so it is for sure not specific to C3.

You can also try to force the WiFi to B/G mode to see if this makes any difference.

Like I said, I have absolutely no clue why it is suddenly a problem.

[TommoT1]

OK, no luck so far, also with forcing the WiFi to B/G mode and yes, the unit has to be powercycled to be reachable again.

[TD-er]

Can you make it connect to a different WiFi access point?
Or reboot the access point?

[TommoT1]

Original accesspoint is a Fritzbox, I tried with my Phone as a hotspot and with another tplink Router. Both did not work

[TommoT1]

I just did a total factory reset and kept nothing....
Not a good idea....the node doesn't start an AP so I guess I have to desolder it...

[TommoT1]

After desoldering I flashed ESP_Easy_mega_20240604_normal_ESP32c3_4M316k_LittleFS_CDC_ETH.factory.bin
After boot I tried an OTA flash with the same build, no problems.
Then I flashed OTA ESP_Easy_mega_20240414_normal_ESP32c3_4M316k_LittleFS_CDC.bin
Flash worked, after booting I tried to flasb back to the 20240604 Version --> Unit stuck.

The problem seems to be the version 20240414

[TD-er]

OK, so at least on newer builds it seems to be fixed...

[TommoT1]

Yes! But there seems to be some difference in the FHEM Controller Module in this build....FHEM now reports the ESPs as "absent".

[Ath]

Yes! But there seems to be some difference in the FHEM Controller Module in this build....FHEM now reports the ESPs as "absent".

Hmm, I did work on the MQTT controllers, so I may have broken something there . Will have a look this weekend.

[Ath]

Hmm, I did work on the MQTT controllers, so I may have broken something there . Will have a look this weekend.

Had a quick look, but my work on MQTT controllers doesn't touch the FHEM controller and isn't merged yet, so there must be another cause I'll still have a look at what may be a cause here, though

[TommoT1]

Thanks, it looks like it doesn't report to fhem anymore.
Some devices are reported on boot, some don't and then there are no updates anymore even on status change.

[TommoT1]

I also notice that the MQTT connection gets lost after a while. After Reboot it is available again.

[TD-er]

Can you tell if a disconnect is happening at some quite specific time since the last message?
Another user (not using FHEM, but it was MQTT related) had similar issues and those went away when he lowered the send interval to less than 10 sec.
Maybe the newer builds do stuff slightly different and thus the keep-alive messages are sent just at the max. interval and sometimes just past...

[TommoT1]

No I can't tell any specific intervall.
If you do a reboot three of five devices post their status. But if you switch those devices or do a taskrun no update gets posted to fhem anymore regardless which intervall time is set and then after the fhem timeout (300s in my case) those devices change to absent like the other two.

The MQTT connection get's lost after some hours...

[TD-er]

And no logs on the MQTT broker?

[TommoT1]

Yes good point, have to enable that....
Oh, one unit left the Wlan completely....
I've to find out whats happening when I'm back home next week

[TD-er]

One tip: Enable "Restart WiFi Lost Conn" on Tools->Advanced page for the nodes that are still accessible.

I also noticed some node suddenly not able to reconnect to WiFi right after I did restart all my access points at the same time.

Still have to look into this, but I got the impression I might not get some WiFi events and thus my WiFi code is entering some limbo state from which it can't get out unless the WiFi is completely turned off and on again.

[TommoT1]

Thanks, I'll do!

[TommoT1]

Are there any new hints to get the fhem connection working again? I'd love to avoid flashing back to 20240414...

[Ath]

Are there any new hints to get the fhem connection working again? I'd love to avoid flashing back to 20240414...

The only thing really changed in this controller is a more safe handling of memory allocation, but that should not have a negative effect when sending out data.

Have you checked the logging at the ESPEasy node? You should be able to recognize the outgoing messages and their response to FHEM, as long as you have the log level set to Info. The log can be viewed from the Tools page (or via serial, but you have those pins otherwise occupied).

[TD-er]

There are some commits pending on ESP32/Arduino which may have an impact on how WiFi reconnects.
So I can make a test build based on those, but that only makes sense if your nodes have been disconnected from WiFi right along the same time when the node was no longer available via MQTT.

[TommoT1]

Hi Ton,
Right now I'm not at home and the internet connection is not too good...
I checked on a esp8266 node which is connected to my fhem server and I can see those messages.
On the ESP32c3 node there are no messages to the fhem server whether in INFO nor in DEBUG....

[Ath]

Hi Ton,
Right now I'm not at home and the internet connection is not too good...
I checked on a esp8266 node which is connected to my fhem server and I can see those messages.
On the ESP32c3 node there are no messages to the fhem server whether in INFO nor in DEBUG....

That's a bit unexpected. I assume you have the Controller Enabled, and also the checkbox for that controller in the Device configuration, so that should at least show something as the used HTTP POST messaging should always log some info on send, AFAICS.

[TD-er]

Do you use a DNS name or IP-address to address the MQTT broker in the controller settings?

If it is DNS, can you try either switching to use IP-address, or at least save the controller settings again?
This will then force a new DNS lookup of the IP-address.

[TommoT1]

Yes all the settings are the same as they where with version 20240414 when fhem and MQTT connection was as expected.
The fhem server and the MQTT server are configured with their IP Adress.
FHEM only get's one update when the ESPEasy node boots, but not for all configured devices.
MQTT loses the Connection after serveral hours, I still have no log from those disconnects.
What I also noticed, sometimes the uptime of the two ESP32c3 nodes ist more than one day, Sometimes only a couple of hours, meas that they restart quite often.
All my other ESPEasy nodes have uptimes of several months.

[TD-er]

Hmm I wonder what may cause those reboots.

Can you set the node to alway send at max. TX power (tools->Advanced page) ?
If it is a power source related issue, then this may cause more frequent disconnects and reboots.
If it isn't, then it might be related to one of those pending pull-requests on ESP32/Arduino repo where the call to set or read the WiFi TX-power is not always done right.
By setting ESPEasy to send at max. TX power you no longer use those function calls, thus the proposed fixes might also work here.

[TommoT1]

Send with max TX Power was already marked Also when Version 20240414 was running

Boot: Soft Reboot (4)
Reset Reason: CPU0: Software reset digital core
Last Action before Reboot: Background Task

Boot: Soft Reboot (4)
Reset Reason: CPU0: Software reset digital core
Last Action before Reboot: Const Interval: TIMER_20MSEC

The FHEM problem seems to be in the release 20240604.
I also had a "classic" ESP32 flashed to this version, no fhem communication possible. Now flashed this one back to 20240414 and instantaneously it connected to fhem.

[TD-er]

I just did update the webflasher to a build including the (pending) PR for ESP32/Arduino regarding the fix for changing WiFi TX power (and some other WiFi code too)

https://td-er.nl/ESPEasy/latest/

Also the all.zip is located there, so you can also do manual upload of the bin file.

[TommoT1]

This version also doesn’t talk to FHEM

[TD-er]

Not at all or no longer talking after some time?

[TD-er]

What do you try to send to FHEM?
Is it possible one of those values does contain a NaN?
What task is sending to FHEM?

[TD-er]

What exact controller do you use to communicate to FHEM?
C009 is FHEM HTTP

But you mentioned MQTT, so which controller do you use?

[TD-er]

Just a short update, I can reproduce not sending to controller.
It is not specific to FHEM...

[TD-er]

Found the bug, building a new testbuild.

[TD-er]

It still has the same build date in the filename.
https://td-er.nl/ESPEasy/latest/

But after flashing you should see a build timestamp of either the last few minutes of the 17th or just past midnight of the 18th.

I just didn't want to stay up longer to get rid of this potential confusion

[TommoT1]

Good morning Gijs!
Yes now everything ist working again, Thanks!
I use both C009 for the connection to FHEM and MQTT for some other stuff.

[TD-er]

Great!
Thanks for reporting back.

I will still have a look to see if I made some similar mistake elsewhere.

[TD-er]

I did just update nearly all my nodes here to this build, mainly to see if the OTA issues now are resolved.
Updating went flawless again.

So probably when updating from the April build, one may run into timeouts, but earlier and builds made in the last 2...3 weeks do not seem to cause issues.

[TommoT1]

Yes I noticed this as well, and the issue not beeing OTA able I just experienced with the ESP32c3.
8266, 8285 and "classic" ESP32 all where OTA flashable with 20240414.