Wemos D1mini - strange behaviour

Hi, (This is going to be a long post)

I have wemosD1 mini running blynk example (a bit edited) terminal sketch, and i am experiencing some strange behaviours on it. For example:

I have on pin D5 LED strip via transistor.
On the phone i control pin D5 with slider.
Now, everythhing works fine, until i do this:

  1. Boot up WeMos
  2. connect to server
  3. slide slider to any higher value
  4. play with it little bit // or not, because up to this point everything behaves normal.
  5. Then, when i set slider all the way to zero value - led goes completly off - ok
  6. NOW - IF i set slider to any higher value, everything behaves ok, BUT IF i set slider only little bit higher say to value 10 within 0-1023 range, WeMos get frozen, and after couple of seconds reboot-self.

or another one (latest):

i have on the same wemos onnected RGB LED, and using widget zeRGBa in app. now, if i am changing color slowly - one at a time - not too fast switching between colors, everything is ok, but when i am changing colors faster (or have “send on release >off” - 100ms and pulling between colors) wemos freezes for under a second, and then reconects to server - in serial monitor is:

[19420] <[14|1E]b[00|07]dw[00]16[00]0
[22151] Cmd error
[22151] Connecting to 80.211.207.110
[22170] <[02|00|01|00] ac355a6476e44a059a4828663a47f7c6
[22196] >[00|00|01|00|C8]
[22196] Ready (ping: 8ms).
[22196] Free RAM: 41640
[22197] >[14|00|01|00]5
[22197] >pm[00]5[00]out[00]13[00]out[00]16[00]in[00]17[00]in[00]4[00]in[00]15[00]out[00]12[00]out[00]14[00]out
[22263] <[11|00|02|00]Hver[00]0.5.2[00]h-beat[00]10[00]buff-in[00]1024[00]dev[00]Arduino[00]build[00]May  7 2018 08:04:03[00]
[22286] >[00|00|02|00|C8]
[25351] >[14|1E]b[00|05]
[25351] >dr[00]16

yup, it is that “cmd error” ( i do not have log from serial mon in dimming LED strip case, because, as i reflashed wemos with code with “#define BLYNK_DEBUG” line, the issue magically dissapeared, and did not come back untill now)

Also another thing besides less blynk related, i have “ArduinoOTA.h” library in code, and when uploading code to wemos some pins is turning on and off pretty fast - maybe 4 times per second (every 250 ms). By the way, few days ago, when i finally get working OTA for the first time, when i was very first time uploading my code via OTA, it was about 1:00 AM and LED strip above me (wich i trying to control via that wemos) started switching between full brightness and zero brightness (off) every 250ms and it was a bit spooky and i was like: "Oh, someone does not like, that i get it to work after that few hours or whatever :smiley: ", interestingly, that pins wich is switching during OTA is some time the same, and then - IDK how and why… - it is doing another pins, and that what is was doing before is now simply at low//0

so… yes that is the whole problem. Also i remember, that similar things happened on arduino uno (i do not have more of that boards at this time).

I almost forget - the code:

#define BLYNK_PRINT Serial
#define BLYNK_DEBUG

#include <ESP8266WiFi.h>
#include <ESP8266mDNS.h>
#include <WiFiUdp.h>
#include <ArduinoOTA.h>
#include <BlynkSimpleEsp8266.h>

// You should get Auth Token in the Blynk App.
// Go to the Project Settings (nut icon).
char auth[] = "trust me, this is valid and working.";

// Your WiFi credentials.
// Set password to "" for open networks.
char ssid[] = "does this really matter?";
char pass[] = "i do not think so...";
const char* ssidota = "also nothing";
const char* password = "to see";

// Attach virtual serial terminal to Virtual Pin V1
WidgetTerminal terminal(V1);

// You can send commands from Terminal to your hardware. Just use
// the same Virtual Pin as your Terminal Widget
BLYNK_WRITE(V1)
{
  if (String("restart") == param.asStr()) {
    terminal.println("Command for reboot receieved.") ;
    terminal.println("issuing restart!") ;
    terminal.flush();
    ESP.restart();
  }

  if (String("reset") == param.asStr()) {
    terminal.println("Command for reboot receieved.") ;
    terminal.println("issuing reset!") ;
    terminal.flush();
    ESP.reset();
  } else {
    terminal.print("write restart to restart");
    terminal.print("write reset to reset");
    terminal.println();
  }

  // Ensure everything is sent
  terminal.flush();
}

void setup()
{
  // Debug console
  Serial.begin(74880);
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssidota, password);
  while (WiFi.waitForConnectResult() != WL_CONNECTED) {
    Serial.println("Connection Failed! Rebooting...");
    delay(5000);
    ESP.restart();
  }
  ArduinoOTA.onStart([]() {
    Serial.println("Start");
    terminal.println("OTA Start");
    terminal.flush();
  });
  ArduinoOTA.onEnd([]() {
    Serial.println("End");
    terminal.println("OTA End");
    terminal.flush();

  });
  ArduinoOTA.setHostname("WeMos Blynk LED");
  ArduinoOTA.onProgress([](unsigned int progress, unsigned int total) {
    Serial.printf("Progress: %u%%\n", (progress / (total / 100)));
    terminal.println("Progress: %u%%\n");
    terminal.flush();
  });
  ArduinoOTA.onError([](ota_error_t error) {
    Serial.printf("Error[%u]: ", error);
    if (error == OTA_AUTH_ERROR) Serial.println("Auth Failed");
    else if (error == OTA_BEGIN_ERROR) Serial.println("Begin Failed");
    else if (error == OTA_CONNECT_ERROR) Serial.println("Connect Failed");
    else if (error == OTA_RECEIVE_ERROR) Serial.println("Receive Failed");
    else if (error == OTA_END_ERROR) Serial.println("End Failed");
  });

  ArduinoOTA.begin();

  Blynk.begin(auth, ssid, pass, IPAddress(this os ok too), 8080);
  terminal.println(F(" "));
  terminal.println(F("Blynk v" BLYNK_VERSION ": Device started"));
  terminal.println(F("-------------"));
  terminal.println(F("WeMos D1 mini controlling LED strip"));
  terminal.println(F("write restart to restart"));
  terminal.println(F("write reset to reset"));
  terminal.flush();
}

void loop()
{
  Blynk.run();
  ArduinoOTA.handle();
}

I don’t think there is anything particularly wrong with Blynk in this case… probably just a simple case of too much too fast, causing buffer overflows or something… and switching to DEBUG would naturally slow things down enough to not be an issue.

You running all the latest App, Library and Local Server versions?

Why such and odd BAUD rate… probably not a big issue as it is only for debug, but still… 9600 is more than sufficient for that.

Also seems you are using both direct pin control and virtual pins… probably best to stick with one or the other. Generally leave all widgets to PUSH, and as high a sending rate (for the ones that always use such) as you can stand so as not to flood too much data (although newer library should have prevented that).

Also you could be running into power issues… ESP’s are picky about resets due to brownouts and heavy WiFi can draw more power.

  1. It happens with or without debug enabled.

  2. Why it do not overflows “simillarly” every time? I mean: why 2 days is “overlofwing” (or whatever is happening) causing led slider, another day button (i did not wrote about that one) and another it is RGB LED? I know that electronics is sometimes unpredictable but not this way - it is not the first time i have met with electronics.

  3. I updating libraries, server and app as soon as i notice it was released, so yes, everything running is latest.

  4. I do not think that baud rate matter that much, i u wanna know - as is wemos starting it sending boot messages trough serial at 74880 baud rate. Either i will have serial glitches instead of readable boot messages and readable blynk output, or readable boot messages and glitchy blynk serial output. Or i will set baudrate to same and it will be radable all. So this is why.

  5. I know, that MCUs is sensitive to power issues, but i tried different power sources, including Lab power supply, that can handle up to 6 Amps, so i do not think, that it can be caused by power issues.

There is also possibility, that i simply got deffective unit, but soon i will test it with more MCUs, and eventually find a cause of that behaviour.