(SOLVED) Blynk controlled DigitalWrite problems with Sparkfun ESP8266 Thing Board

I will try to describe this odd behavior as best as I can:

digitalWrite(5,HIGH | LOW) works until I start the app (android). Then it no longer changes the hardware pin state. A button in the app on GP5 always works. Stopping the app doesn’t fix it. Triggering with the GP5 button widget fixes it, until I stop/start the app (play button).
It seems to only affect GP5.

My setup:
Local server, v 23.0
Sparkfun Thing Dev board
Arduino IDE

Things I’ve tried
If I create a new android app, it works. If I clone my old app, it does not.
I have tested on two Sparkfun ESP8266 Thing Boards.
I have simplified code to just the LED(s)
Since this had been working for a while, I tried un-doing some things that have changed:
-downgraded Blynk Arduino lib
-downgraded ESP Arduino lib
-downgraded local server jar
-remove the GP5 button on the app (there’s no other GP5 widgets)

Question: Was there some kind of schema update that makes my app no longer valid? My app is pretty involved so I’d like a way to make this work without having to recreate it all.


#define MYLED 13
#define VIRTUAL_DOOR 1
char auth = “xxxxx”;
#define BLYNK_PRINT Serial
#define WIFI_SSID “myAP”
#define WIFI_PASS “pass”
#define BLYNK_HOST “myhost.com
#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>
#include <SimpleTimer.h>
#include <SoftwareSerial.h>
SimpleTimer timer;
int doorState = 0;

void door(){
if(doorState == 0){
Serial.println(“Door Power High”);
doorState = 1;
Serial.println(“Door Power Low”);
doorState = 0;


void setup() {
// put your setup code here, to run once:
Serial.println(“Door Power Low”);

void loop() {
// put your main code here, to run repeatedly:

I have figured out what’s causing it, but it still doesn’t make any sense.

I have a button tied to GP5 and a value display widget on GP4 set to 1sec update. If I remove the value display from the dashboard, the problem goes away. If I put ANY digital pin value display widget on the dash, it causes GP5 to misbehave as indicated above. If I change the button to GP13 , then it’s GP13 acting the way GP5 was before.

Can someone comment/verify? Am I the first one to discover this?

Try to duplicate the issue with a very simple app and sketch… that way you can eliminate either hardware or code as a probable issue.

@Gunner Yes, that’s what I did. See original post.

What I meant was break it down to the bare basic in the sketch, and if the same issue show it here… not downgrade all the libraries or whatever you did… it is a bit confusing :wink:

And after a quick look at the specs of the Thing: https://learn.sparkfun.com/tutorials/esp8266-thing-development-board-hookup-guide/hardware-overview I found this… perhaps it is conflicting with whatever you are trying to do.

I did try a lot of things. The latest was a barebones sketch and dashboard. The sketch code is above. The dash has only a button and a value display.

Well as stated in my last post… if you tried other pins and only GPIO5 is the issue, then there is the reason (Shared LED) and solution (Don’t use for your application).

It happens with gp13 also. Gp5 just has an led on it.

Well that differs from your initial comment :wink: but regardless…

“Just an LED” includes just a current limiting resistor… and who knows how Blynk’s internal timing interacts with the hardcoded MOSI pin on GPIO13.

There are many topics in this forum alone indicating how many differing ESP based dev boards have glitches when accessing varying pins, depending on the manufactures layout, etc.

Now that you have determined some issue with those pins, in that application, avoid them for that application and move forward.

PS, I updated your title to better relate to your issue, in case other Sparkfun ESP8266 Thing Board users have some ideas.

In your original post you say if you create a new app it works ( I assume you mean project), can you expand on this?

Also your sketch is a bit confusing can you explain what you are trying to accomplish. From your original post the button should be on virtual pin 1, not gpio5.

Not using the pins is not an answer. Gpio are meant for doing things like driving or sinking LEDs. Furthermore, I only checked 5 and 13, it may be on more. And beyond all of that, you don’t find it odd that the blink sketch I posted works perfectly fine until the app is connected, and only when the app contains a button on the gpio pin being oscillated by the sketch program and only when the app also contains a value display set to another gpio? Something is happening when the app connects. No widgets are being manipulated.

Please understand this too: My main project has been working fine for over a year. I recently made some minor changes but also updated the app, server, Arduino IDE, including board defs and Blynk lib. If I go back to my original code this problem still happens. It’s related to one of the updates.

I created a very basic program to help narrow it down and I did. When I wrote the original post, I had not yet seen the behavior on other pins, nor had I observed that it relates to the button and value display. I continued to test after I posted, which is why I posted a follow up.

I appreciate you responding to me but please try to understand my issue instead of just finding a way to dismiss it.

1 Like

@Toro_Blanco in the sketch, forget about virtual pin 1, that’s just a way to manually enter the function. The sketch will toggle gpio pins 5 and 13 every 5000ms. It will do this happily until the app is connected. Then, if I have a button in the app on Gp5, and a value display on some other gpio, Gp5 will stop toggling every 5000ms until I either manually toggle it with that button, or reset the board. If I remove the value display or the button from the app, I can connect the app and both 5 and 13 continue toggling…

Actually that can be a common answer for many strange situations where in certain pins on particular dev boards don’t play nicely with other libraries, etc.

As for the rest… take a deep breath :slight_smile: We can try to help, but can only give suggestions based on the information YOU provide. You are the primary troubleshooter and up until that later post of yours, you were somewhat unclear in your OP and contradictory with your answers. And as @Toro_Blanco mentioned, your sketch is also a bit unclear as to what it is doing…

…It appears that your primary usage of Blynk in the sketch is to trigger a single function call BLYNK_WRITE(VIRTUAL_DOOR), and do so regardless of the state of the virtual button… why? EDIT - I saw your explanation… and just reinforces my next recommendations…

We don’t know what else you have running on the App side that makes things so complex?

Are you trying to manipulate the same hardware pins with both the sketch and direct pin manipulation/state reading on the app? Don’t! Direct pin manipulation is fine for few LEDs or something (with no extra code in the sketch), but for anything more complex, try to use virtual pins and properly formatted BLYNK_WRITE() commands from the app to the hardware and Blynk.virtualWrite() from the hardware to the app. Leave all digital pin reads and writes to the sketch commands.

Thank you. I should have removed the virtual pin stuff from the sketch as it’s inconsequential. The app is extremely simple and has two widgets, the button and the value display.

Understood about the Vpins. That is essentially the conclusion I came to. The strange thing to me is that it had never been a problem before.
Perhaps with some of the updates the button state is pushed to the hardware on connection of the app. That would partially explain this. I will reconfigure the main project to not have any widgets access gpio directly. Those are a holdover from the very early testing of the project.

I still maintain that not using the pins is not a good answer because the pins work fine and they are not reserved or anything. My career is designing and troubleshooting electronics and software but it’s been a long week. It does not help either that I need this working before I am out of town for a while.

Again, thank you both for your responses. It seems to be OK after having removed the app’s direct access to gpio.