Dear all,
I have different version of Wemos D1 and I observed that if I load my sketch to a wemos D1 mini pro (the one with the ceramic antenna) blynk performs as expected …great
But if I upload the same sketch to the older Version Wemos D1 mini (the one with the PCB antena) the sketch startes and responds to the serial monitor but it does not connect to the WIFI
Does some one have a idea what´s wrong ?
With other words:
using wemos D1 mini pro WIFI connects and blynk runs
using wemos D1 mini WIFI does not connect
There is no difference between a WeMos D1 Mini and a WeMos D1 Mini Pro other than the aerial and “extra” memory on the Pro. Neither of these will affect Blynk other than perhaps if your router is in a very marginal location.
If I write Nike on my t-shirt does it make it genuine?
I have both versions of WeMos as supplied directly by WeMos, they work identically with Blynk.
That said, I never use the WeMos board in the IDE. I always use Generic for the benefits that provides.
If you have some ESP’s not supplied by WeMos that don’t work you need to ask the supplier why they don’t work.
There’s your answer. All the genuine Wemos boards have the name printed on them. Still, it’s odd that the code behaves differently, since the clone manufacturers use the same Espressif chips. I’ve used a few of the clones, and have had good luck with them (knock on wood).
Thank you for your comments.
But because I bought it as original wemos D1 I´m a bit frustrated.
The vendor does not response and I got about 10 of these may be fake devices.
Any idea how to get these devices to run would be great.
Please don´t give me comments like “by the original…” I assumed to do so.
That´s it thank you
sometimes the simplest solution works
It seems that the ceramic antenna performs much better than the PCB version.
When I changed my location close to the rooter using the PCB version the devices works fine.
It is not so easy as it locks like.
First I used the wemos device very close to my rooter ( less than 100cm)
But by some reason the clone one did not work at all
Because of Costas note I tried it again using it at another room about 10 meters away from my rooter.
And suddenly it works. ??!!
My first gues was that this is caused by the different location.
That´s why I posted it.
But no now it works also close to the rooter.
I did not change my code!
Now I tested all of my devices using the same code.
And found the root cause (I hope so)
3 of 10 devices does not connect to the rooter while the other does.
So I think that my purchase was not the best.
How ever
I hope I did not wast the time of someone.
And I want to say thank you for this great community.
From personal experience I have found that Wemos Mini PRO is a great deal more stable with respect to handling interference. Let me explain my experience:
SetUp:
I have Wemos controlling 4 x Solid State relays that switch 24V AC. (Sainsmart type)
WITH WEMOS MINI
I find with the Wemos Mini or Wemos R1 D2 my Wemo resets very often e.g. every 5 mins when switching the relays ! - the reset reason reported by Wemos is : EXCEPTION
WITH WEMOS MINI PRO
When I swapped it for the Wemos mini PRO i find it resets every 50 hours ! and the reason is HardWare watchdog. BTW: I have no idea what is triggering the Hardware Watchdog - perhaps Costas you can provide some tips.
CONCLUSION:
The handling of interference especially when driving relays to switch AC voltage is excellent with the PRO vs the older MINI’s.
@mars yes the PRO is an improved design from the original Mini and maybe when they get to PRO+ they will increase the maximum AO voltage from 3.2V to 3.3V.
To debug system resets you could try:
Switching from WeMos to Generic board in the IDE, add Serial.setDebugOutput(true); to setup() and select Serial and All from Tools Menu in the IDE for Debug port: and Debug Level:
As far as I can tell, enabling ESP debugging like Blynk debugging, does require additional processing power and if your system is running at close to the limit (available free Heap etc) then it will only make things worse. Therefore debugging should be disabled as soon as you have found the problem and might not work at all if you are close to the margin.
You can add the ESP Exception Decoder to the IDE Tools menu to investigate the stack. To make the best use of this you would need to make use of the ESP bug whereby the device will not reset following a serial update without first manually resetting the device. What I mean by this is keep Serial Monitor open, don’t reset after a flash and the stack error will be shown as the last entry to cut and paste into the decoder.
If you have heavy routines in your project that can’t be avoided you can feed the WDT with ESP.wdtFeed(); and consider disconnecting and reconnecting to the Blynk server as part of the routine.
The good thing about ESP’s, providing you account for the reset bug, then they handle resets very well and for most projects an occasional reset will not be a problem.
thanks Costas.
I continually feed WDT and I know (or believe :-)) I have the Software Watchdog under control and I do not receive software watchdog resets (only hardware watchdog). When I loose internet connectivity and try to reconnect I disable WDT and try reconnecting and then I enable WDT again immedately after a success connection or non successfull connection attempt so as I avoid WDT active during long delays. Perhaps this is where the hardware watchdog is kicking in
Given this occurs every 40+ hours its hard to disagnose.
