(power issue) ESPEASY is not work on WeMos D1 NodeMcu Lua V3!

[aperoap]

I have WeMos D1 NodeMcu Lua V3.
I tried following ESPEASY MEGA:

• ESP_Easy_mega-20190315_normal_ESP8266_4M.bin
• ESP_Easy_mega-20190311_normal_ESP8266_4M.bin
• ESP_Easy_mega-20190305_normal_ESP8266_4M.bin

i can see "ESP_Easy_0" and conact with this. web AP ist very slowly. I can search my router WIFI. When i choose my wifi and enter my password, starts the countdown but it cant conact with my router and i have to repeat it all again.

with build R120 can i conact und anything works.

Please help, i have 25 WeMos D1 NodeMcu Lua V3 and i need MQTT-import.

[TD-er]

have you also tried other core builds of the latest build?
For example core 2.6.0 sdk 2.2.2?

Please also try 20181231 build

[HV-NL]

None of the current versions (20190315) does work on my Wemos (cheap nodeMCU clone). I tried them all.

Then I tried 20181231: that one gives quite another output in the debug screen. But also 20181231 does not properly make a connection to my AP.

20181231: Wifi indicates that it is connected to the primary AP, but after a beacon timeout it stops.

Quick analysis: it can send, but does not receive (no DHCP address claimed)

dhcp client start...
bcn_timout,ap_probe_send_start
ap_probe_send over, rest wifi status to disassoc
WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 25 s

Then it tries to connect to the fallback AP, etcetera.
This is what my AP sees:

attempts to associate
connected, signal strength -48
disconnected, received disassoc: no activity (4)

attempts to associate
connected, signal strength -48
disconnected, received disassoc: no activity (4)

So sending does work in 20181231, but no wifi packages are received.

[uzi18]

In my opinion it is antena issues or faulty module/board.

[uzi18]

Please post here photo of board

[TD-er]

Well, it was said to be working with R120, but that one was using a totally different core library and was also do a lot less at startup.

[HV-NL]

See [/issues/1337/] (april 30 2018) for a picture of this cheap clone.

The antenna should be OK: the device can send, and the message is properly received by the accesspoint. The device even gets a DHCP address once, so it even receives properly, but finally a 'beacon' is not received, and the connection is broken down. After that no new connections are possible any more.

connected with LinksysAtHome, channel 1
dhcp client start...
ip:192.168.11.71,mask:255.255.255.0,gw:192.168.11.1
4567 : WIFI : Connected! AP: LinksysAtHome (B8:69:F4:1C:56:90) Ch: 1 Duration: 3843 ms
4568 : WIFI : DHCP IP: 192.168.11.71 (ESP-Easy-20) GW: 192.168.11.1 SN: 255.255.255.0 duration: 41 ms
4574 : Webserver: start
bcn_timout,ap_probe_send_start
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
13105 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 8536 ms

An older version of ESPEasy does work, so the device is probably not completely faulty.

[TD-er]

See also the discussion here: esp8266/Arduino#5908 (comment)
Maybe you can also try this?

Maybe it is also possible to just wipe the flash and try core 2.4.1 or 2.4.2.
Wiping the flash should also clear the RF calibration values.

[HV-NL]

Wiping the RF calibration data did not help.
Wiping the flash + reflash 20190315 core 2.4.2 also did not give me a working wifi.

Just flashed v2.0.0-dev13 again: wifi is working again.

So I tried a different approach: I created a very small program, to test this device stand-alone, using the current Arduino IDE. I used the library 'wifiManager' for this test.

#include <ESP8266WiFi.h>
#include <DNSServer.h>
#include <ESP8266WebServer.h>
#include <WiFiManager.h> //https://github.com/tzapu/WiFiManager WiFi Configuration Magic

void configModeCallback (WiFiManager *myWiFiManager) {
Serial.println("Entered config mode");
Serial.println(WiFi.softAPIP());
Serial.println(myWiFiManager->getConfigPortalSSID());
} //configModeCallback

void setup() {
Serial.begin(115200);
WiFiManager wifiManager;
wifiManager.setAPCallback(configModeCallback);
if(!wifiManager.autoConnect()) {
Serial.println("failed to connect and hit timeout");
//reset and try again, or maybe put it to deep sleep
ESP.reset();
delay(1000);
}
//if you get here you have connected to the WiFi
Serial.println("connected...yeey :)");
} // setup

void loop() {
} // loop

This also does not work on this cheap 4M Wemos clone (I wiped flash before upload): no wifi.
I also uploaded this to a 'normal' 4M nodeMCU clone (with a blank aluminium cap over the wifi part): works OK.

So my impression is that this cheap Wemos clone is currently incompatible with the current IDE and/or ESP8266 library, and this is not a dedicated ESPEasy configuration related item.

[TD-er]

Thanks for this test with a simple setup using WiFimanager
That's giving me some confidence it is indeed not an ESPeasy issue.

One thing you could try to do is to call lots of delays at boot until connected

[aperoap]

have you also tried other core builds of the latest build?
For example core 2.6.0 sdk 2.2.2?

Please also try 20181231 build

i have 20181231 build tried. it works very good.

a pic of my ESP from Wemos

[uzi18]

interesting it is not covered by metallic cup

[TD-er]

@uzi18 The Wemos D1 mini pro (16M) is also not covered with a metal shield.
One of the things changed since 2018/12/31 is that it now tries to lessen the load during startup.

[jcpy70]

Hello everyone,
For more than 6 months, I use EspEasy with happiness, congratulations to all.
I use either classic NodeMCU Lua V3 (with metal shield) or Wemos D1 mini (also with a metal shield) or Wemos D1 mini Pro with ceramic antenna and no metal shield...
It's the D1 mini Pro which poses problem starting from the version ESP_Easy_mega-20190305_normal_ESP8266_4M (idem for test and dev).
Wifi is working but the browser (Firefox or IE) is waiting for a response...
A port scan indicates that ports 25,80,110,119,143,465,563,587,993,995 are open.

[jcpy70]

I tested several versions with the Wemos D1 Mini Pro (ceramic antenna and no WiFi shielding):
The latest stable release is ESPEasy_mega-20190216.
If it can be useful.

[khambrecht]

I also have one of these Wemos devices. Mine looks exactly as the one @aperoap has posted. Old firmware R120 work fine. I then stepped through more recent firmware builds, beginning with 20181231 (but skipped some in between). Here are my results:

• 20181231_normal_ESP8266_4096.bin -> OK, stable
• 20190106_normal_ESP8266_4096.bin -> not OK, connect to initial AP mode fails
• 20190212_normal_ESP8266_4096.bin -> not OK, connect to initial AP mode fails
• 20190215_normal_ESP8266_4096.bin -> not OK, connect to initial AP mode fails
• 20190216_normal_ESP8266_4096.bin -> not OK, initial AP mode worked, later WiFi client slow and unstable.
• 20190225_normal_ESP8266_4M.bin -> OK, stable (*)
• 20190226_normal_ESP8266_4M.bin -> OK, stable (*)
• 20190227_normal_ESP8266_4M.bin -> not OK, initial AP mode worked, later WiFi client slow and unstable.
• 20190305_normal_ESP8266_4M.bin -> not OK, connect to initial AP mode fails
• 20190311_normal_ESP8266_4M.bin -> not OK, connect to initial AP mode fails
• 20190315_normal_ESP8266_4M.bin -> not OK, connect to initial AP mode fails
• 20190404_normal_ESP8266_4M.bin -> not OK, connect to initial AP mode fails

(*) these two firmware releases sometimes require several attempts to proceed with the initial AP mode

[jcpy70]

Good new !
The latest version ESP_Easy_mega-20190406_xxx is well supported by the Wemos D1 Mini Pro card (with ceramic or external antenna).
Thanks to the whole team !

[TD-er]

@jcpy70 Good to hear.
Not to spoil it, but I want to make sure it isn't a build issue, so let's try again for the next build.

[jcpy70]

@TD-er :
Tested today... Ok with ESP_Easy_mega-20190409_xxx
I use these cards, the soldering for the external antenna is not easy, the 0 ohm resistor (R9) is small ...

[TD-er]

Great, good to hear it isn't just a single build that was working by accident :)
I use these boards too. They are great and I'm also working on getting to use the whole 16M of the flash.
About the 0-Ohm resistors. I know what you mean. I have a strip of them in case I loose one or destroy in the process.

[khambrecht]

unfortunately neither 20190406 nor 20190409 will work on the Wemos D1 NodeMcu devices (these are not like the D1 mini [pro/lite] devices). See @aperoap #2409 (comment) for picture of the Wemos D1 NodeMcu device. Have to revert back to 20190226 or 20181231 to get the device working.

[zerog2k]

FWIW:
Also having this strange issue. This is a new clone of Wemos D1 R2. But what I notice from the picture above, is that my mcu is also strange: it has "ECO Plugs" label on mcu instead of familiar ESP8266... labeling. I'm suspecting these are some sort of rebadge/rebrand (and maybe rejects/extras/grey-runs :( ).
Anyhow,
ESP_Easy_mega-20190409_normal_ESP8266_4M.bin also does not work for me: it never picks up an ip address, whereas ESP_Easy_mega-20190226_normal_ESP8266_4M.bin works.

[arnemauer]

Good new !
The latest version ESP_Easy_mega-20190406_xxx is well supported by the Wemos D1 Mini Pro card (with ceramic or external antenna).
Thanks to the whole team !

I am using also the Wemos D1 mini pro. It works with 20190226. It doesn't work with 20190227 and later. The card i have is a v1.0.0. Which versions is yours?

[sebastianheyn]

IMHO, its power supply issues. I've had that with other boards from china before. Its a capacitor/regulator misalignment. try adding some caps to the 5V an 3,3v and you will see the problems shift or disappear.
For example, for me the at firmware always worked, since the consumption is lower somehow. but then after changing to easyesp, sometimes they would work, sometimes they dont.
I add a 470µF to the 5V and 100µF to the 3,3V, and 2 or 3 0,1µF to the 3,3V. Helps most of the times.
Problem is they use cheap regulators, that cannot handle power bursts.

[TD-er]

I am running now on a few of these Wemos D1 mini pro's here on my desk and they all seem to work.
I am using good (and short) USB cables and all is powered from a 7+3 port USB3 hub from Anker, with a 60 Watt power supply.
Also on the boards I make, I have added a few capacitors and these boards also run stable.

The boards I make have a 470uF capacitor near the ESP node (and the sensors that need 5V) and have thick copper traces for the traces that run power lines.

[jcpy70]

@TD-er & sebastianheyn
Yes, of course, these are basic engineering rules ... But how do you explain that the same Wemos on the same PCB (this is my case for my personal-made PCBs) works correctly with some versions of ESPEasy and not others? The presence of capacitors does not explain everything.

@arnemauer : My Wemos are also 1.0.0 versions.

[arnemauer]

@arnemauer : My Wemos are also 1.0.0 versions.

I found this tread on reddit about a bad voltage regulator on de wemos clone boards: https://www.reddit.com/r/esp8266/comments/9iizx4/warning_clone_wemos_d1_minis_with_only_150ma_33v/. And... yes mine came with a 150ma voltage regulator :(

I removed the regulator and replaced it with an ams1117-3.3v and couple of capacitors but the esp keeps crashing :(

[Domosapiens]

I removed the regulator and replaced it with an ams1117-3.3v and couple of capacitors but the esp keeps crashing :(

I confirm that

[TD-er]

It can have many causes.
Apparently Tasmota is doing things different here, so we may need to see what they are doing.
ESPeasy is using events to keep track of the connectivity and process the next steps.
I know Tasmota is not doing that, so maybe the core library is handling the WiFi connect/reconnect in a different way here? (maybe longer timeouts, who knows)

[mrdc]

Oh, good idea - i'll put Sonoff switch (with stock firmware) near ESP-01S.

[mrdc]

I can confirm that using these settings the wifi problem was fixed for me:

ESP-01S is accessible via web interface, doesn't drop wifi connection etc. Wifi signal level is the same as I've posted above. No changes were made to hardware&software part: the same power supply, the same ESP-01S module, the same ESP-01S position, the same router settings.

So, looks like the problem is caused by Wifi Sleep as previous time Force WiFi B/G was enabled and I've had the same connections issues.

[TD-er]

Not sure if these settings have a command, but I guess it would be great to have some command to set WiFi into "safe mode" or something like that.
Or maybe these should also be selectable during WiFi setup? When AP+STA is active, it is effectively the same as the last option "Force WiFi No Sleep".

[mrdc]

WiFi into "safe mode" or something like that.

Yes, some sort of a fallback when a lot of disconnections occur. Or Wifi sleep function should be investigated as in my case it causes wifi connection issues.

[TD-er]

During WiFi sleep mode, the WiFi is turned on every "beacon interval", which is often 102.4 msec.

On some ESP units, the used crystal is of really inferior quality, which will also have an effect on other functions, like timing this interval and thus it will miss the beacon interval.
With WiFi no sleep, the radio is always listening when not sending, so it will not miss the interval.

You can check the drift of the internal clock by looking at the logs for NTP updates.
It will also show something like "0.1 msec/sec" when a new update is received.
I think it is useful to also have it in the sysinfo summary, since I do see some extremes here. which will for sure cause issues with WiFi connectivity. (and other timing issues)

[mrdc]

You can check the drift of the internal clock by looking at the logs for NTP updates.

7550439: NTP : NTP replied: delay 170 mSec Accuracy increased by 0.846 seconds
7550440: Time adjusted by -248.94 msec. Wander: -0.07 msec/second

[TD-er]

0.07 msec/second

That's not too bad.
I've seen unit with > 1 msec/sec and that's a receipt for instability.

[mrdc]

Wifi uptime is solid now - almost 14 hours and a few disconnects:

[MiloshCZ]

Hi, what about Xtal frequency? Some ESP8266 has 40MHz, but some has 26MHz Xtal. Default builds are with 40MHz Xtal?

[TD-er]

I have actually no idea how that's being scaled internal and where it is defined.
The only thing I am aware of when building our project is the clock frequencies used for the CPU and flash.
But that doesn't have a strict 1-to-1 relation with the used crystal.
I guess the ESP does have some PLL internal which does the up-scaling, but like I said I have no idea if that's being defined somewhere and how.
26 and 40 MHz is quite far off, so maybe the ESP can switch PLL configuration dynamically at boot?

[khambrecht]

I can confirm that using these settings the wifi problem was fixed for me:

So, looks like the problem is caused by Wifi Sleep as previous time Force WiFi B/G was enabled and I've had the same connections issues.

Unfortunately this does not solve the issue on the Wemos D1 NodeMcu devices.

As this one has 4MB flash, I tried these firmware builds:

• ESP_Easy_mega-20190903_normal_core_242_ESP8266_1M.bin
• ESP_Easy_mega-20190903_custom_ESP8266_4M1M.bin (-> has core 2.5.2)
• ESP_Easy_mega-20190903_minimal_core_242_ESP8266_1M_OTA.bin

Still DHCP reconnect every 10 sec. Due to the intermittent connection, it's hard to access the advanced configuration, but once you have managed to activate "Force Wifi No Sleep", this does not have any effect.

So, as release 20190226 was the last known working one (with core 2.4.2 btw.), I also tired test/dev build with core 2.6.0 (ESP_Easy_mega-20190226_test_core_260_sdk2_alpha_ESP8266_4M.bin). This is also stable, without these reconnects.

[TD-er]

Can you make a test build yourself?
If not, then I can build you a test build on the current core 2.6.0

Last night there has been a fix merged into core 2.6.0 stage, which may deal with disconnect issues like these and I would really like to know if it does fix these disconnect issues you're seeing.

Edit:
Can you test test_core_260_sdk222_alpha_ESP8266_4M1M_issue2409.bin ?

[khambrecht]

Can you test test_core_260_sdk222_alpha_ESP8266_4M1M_issue2409.bin ?

tested, but no improvement, even with force wifi no sleep :-(
Still DHCP requests every 10 sec. Have attached serial debug log.
test_core_260_serial-debug.log

[mrdc]

Some update:


RSSI: -78 dB

But sometimes Wi-Fi connection is unstable and my router logs are full of reconnects from ESP-01S:
disconnected, received disassoc: no activity (4)

[TD-er]

That's similar to being kicked of the AP by the AP due to no activity.
If you check to send Gratuitous ARP, then there will be activity every N seconds (max 5 seconds if I'm correct)

[TD-er]

Is this still an issue?

[khambrecht]

Is this still an issue?

Just checked with mega-20191104, used these binary files

• ESP_Easy_mega-20191104_normal_ESP8266_4M1M.bin
• ESP_Easy_mega-20191104_normal_core_260_sdk222_alpha_ESP8266_4M1M.bin
• ESP_Easy_mega-20191104_normal_core_241_ESP8266_4M1M.bin

and yes, still an issue with frequent DHCP requests.

[mrdc]

@TD-er
Looks like in my case it was Mikrotik router issue: the same ESP-01S, the same "old" mega-20190903, the same place (distance to my router), but new RouterOS 6.46 (auto updated yesterday). No more extensive data loss, disconnects due inactivity etc.

Before it was thousands reconnects a day.
Or maybe it's related to WiFi channel? :) Will test how it performes with ROS 6.46 and report later.

[TD-er]

Hmm good to know there is an update for MikroTik.
Will keep it mind to do some tests here between versions.

[mrdc]

Powered off the router, turned on and look what I see:

11th channel is not as good as 9th.

[mrdc]

ESP-01S with mega-20190903.

BTW in my previous post I wasn't correct - additionally to the new router firmware the router itself was moved ~ 15cm. Don't think that it can affect WiFi so dramatically in my case (the same walls etc and "line of sight" between router and ESP-01S).

[TD-er]

BTW in my previous post I wasn't correct - additionally to the new router firmware the router itself was moved ~ 15cm. Don't think that it can affect WiFi so dramatically in my case (the same walls etc and "line of sight" between router and ESP-01S).

Well, the wifi wave length is 12.5 cm.
A quarter of a wave length difference can be the difference between min and max. reception.
12.5 / 4 = 3.125 cm.
So if you move it (N+1/4) or (N + 3/4) times the wavelength in the direction of the receiving node, then it can make a lot of difference in signal strength.
This 12.5 cm is a rough estimate based on 2.4 GHz, but if you change the channel, you will use a different frequency, so also the wavelength changes.

So in short, 15 cm movement can have a very big effect on the signal quality.

[mrdc]

So if you move it (N+1/4) or (N + 3/4) times the wavelength in the direction of the receiving node, then it can make a lot of difference in signal strength.

I've moved it not in the direction of ESP-01S. The distance is the same - router was moved ~15cm to the left if you stay upfront of ESP-01S.
But now the connection is rock solid: day+ without reconnects.

[tonhuisman]

This seems to be resolved, so can be closed.