digitalWrite(4,HIGH); fails if Blynk is running

I have looked for similar topics here and a number of user have reported outputs not working.
One was to do with widgets talking to the same pin
One was to do with number confusion
I could not see anything that matched.

Hardware:
• SparkFun 8266 thing dev + wi-fi/standalone
• Android, but failure happens even without the app running
• Blynk server
• Blynk Library version - whatever was around this week

Here is the issue:

In a non-Blynk sketch I am able to say:

pinMode(4,OUTPUT);
digitalWrite(4,HIGH);

and it works perfectly.

In Blynk it does not work. I created a minimalist sketch (below). If I comment out the Blynk.begin line, the code works and an LED connected to output 4 lights up when the sketch starts as expected.
If Blynk.begin is used, the LED does not come on.

#define BLYNK_PRINT Serial
#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>
char auth[] = "xxxx";
char ssid[] = "xxxx";
char pass[] = "xxxxx";

void setup()
{
  Serial.begin(115200);
  Blynk.begin(auth, ssid, pass);   //<- it works if I comment this line out
  pinMode(4,OUTPUT);
  digitalWrite(4,HIGH);
}

void loop()
{
 }

The app on the phone has nothing connected to D4 and is not running either.

Does Blynk remap the outputs?
The Blynk doc says one can use digitalWrite as usual, but I cannot find a single code example of actually setting an output pin on the site.

It works fine (same hardware and connections) in a more complex sketch (non Blynk) that also connects to my wifi and even takes commands in through an additional TCP connection. It seems as though output 4 is not the same port for some reason once Blynk attaches to the network.

BTW, without Blynk.run(); in the void loop there is NO Blynk running :stuck_out_tongue_winking_eye:

Pin 4 (Arduino designation) and D4 (Some ESP silk-screened designations) have nothing in common… they are actually two different pins… this is NOT a Blynk specific issue.

1 Like

Not sure what you are referring to here… Aside from Blynk’s built-in pin management (mostly for beginners - set a GPIO in the App and it controls the physical pin on the board) one MUST use a digitalWrite() to control ANY pin via code… particularly used with virtual pins

BLYNK_WRITE(V0) { // If this vPin is assigned to a Button Widget this function gets called each Button Widget press AND release
digitalWrite(2, param.asInt()); // this will set GPIO pin 2 (AKA D4) HIGH or LOW depending on button widget state... pulled from param command
}

Alternate ways of using this function for more control

BLYNK_WRITE(V0) { // If this vPin is assigned to a Button Widget this function gets called each Button Widget press AND release
  if (param.asInt() == 1) {  // the state, as integer, of virtual button
    digitalWrite(2, 1); // GPIO pin 2 (AKA D4) HIGH
  } else {
    digitalWrite(2, 0); // GPIO pin 2 (AKA D4) LOW
  }
}

Also… FYI… Blynk.begin() is a blocking command… if there is no actual connection made to the Blynk server then nothing happens past this command… (and of course you need the aforementioned Blynk.run(); in the loop)

There are workarounds for those wanting to make their code run either way (connected or not)…

Thanks for the suggestions…

  • It was not because I did not call > Blynk.run(); The setup() function runs before the loop() anyway.
  • It was not because the SparkFun pin 4 is not GPIO4 (it is).

The app ID I used for the bare bones demonstration to illustrate the problem, was assigned to a project that was using a different ESP8266. Once I created a new app, with Sparkfun thing as the hardware and changed the auth to the new key… the bare bones demo of the problem started working.

However, the original Sketch in which I ran into the problem does have the matching hardware, and still has the problem, so I have to start removing things again until I can isolate the issue.

I still believe that it may be a pin mapping issue. A non Blynk based sketch turns on the LED with digitalWrite(4,High), but in one of my Blynk sketches, it does not.

GPIO 4 on the SparkFun thing dev is labeled ‘4’. It responds to digitalWrite(4,HIGH);

Here is the sketch that still fails:

/* Comment this out to disable prints and save space */
#define BLYNK_PRINT Serial
#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>

char auth[] = "xxx";
char ssid[] = "xx";
char pass[] = "xx";

// =========================================================

// Leds in app definitions
WidgetLED HpR(V10); 
WidgetLED HpG(V11);
WidgetLED HpY(V12);
WidgetLED VrO1(V13);
WidgetLED VrG1(V14);
WidgetLED VrO2(V15);
WidgetLED VrG2(V16);

// colors
#define BLYNK_GREEN     "#23C48E"
#define BLYNK_YELLOW    "#ED9D00"
#define BLYNK_RED       "#D3435C"


// Signal modes
int Hp = 0;
int Vr = 0;


void displayVr() {
 
  Serial.print("Vr");
  Serial.println(Vr);
  if (Hp == 0) {
    VrO1.off(); VrO2.off(); VrG1.off(); VrG2.off()   ;
  }else{
      switch (Vr){
    case 0:
      VrO1.on(); VrO2.on(); VrG1.off(); VrG2.off()   ; break;  
    case 1:
      VrO1.off(); VrO2.off(); VrG1.on(); VrG2.on()   ; break;    
    case 2:
      VrO1.off(); VrO2.on(); VrG1.on(); VrG2.off()   ; break;  
    }
  }
}

BLYNK_WRITE(V7) // Hp selector
{
  Hp = param.asInt() - 1 ; // assigning incoming value 
  Serial.print("Hp");
  Serial.println(Hp);
  switch (Hp){
    case 0:
      HpR.on(); HpG.off(); HpY.off()   ; break;   // hp 0
    case 1:
      HpR.off(); HpG.on(); HpY.off()   ; break;   // hp 1   <- this line gets executed
      digitalWrite(4,HIGH);                       // hp 1   <- this line fails 
    case 2:
      HpR.off(); HpG.on(); HpY.on()   ; break;   // hp 2
  }
  displayVr(); // force Vr to update also
}

BLYNK_WRITE(V8) {    // Vr selector
  Vr = param.asInt() -1; // assigning incoming value 
  displayVr();
  }

BLYNK_WRITE(V10) {   
  int Nv = param.asInt() ; // assigning incoming value 
  Serial.println("We got a V10 write!\n");
  
  }

  
//============================================================

void setup()
{
  // Debug console
  Serial.begin(115200);
  Blynk.begin(auth, ssid, pass);
  //change LED colors
  Blynk.setProperty(V10, "color", BLYNK_RED);
  Blynk.setProperty(V11, "color", BLYNK_GREEN);
  Blynk.setProperty(V12, "color", BLYNK_YELLOW);
  Blynk.setProperty(V13, "color", BLYNK_YELLOW);
  Blynk.setProperty(V14, "color", BLYNK_GREEN);
  Blynk.setProperty(V15, "color", BLYNK_YELLOW);
  Blynk.setProperty(V16, "color", BLYNK_GREEN);
  // set the relay pins as outut
  //pinMode(0,OUTPUT);
  //pinMode(1,OUTPUT);
  //pinMode(2,OUTPUT);
  //pinMode(3,OUTPUT);
  pinMode(4,OUTPUT);
  //pinMode(5,OUTPUT);
  //pinMode(6,OUTPUT);
}
 

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

aagh I found it!

HpR.off(); HpG.on(); HpY.off()   ; break;   // hp 1   <- this line gets executed
      digitalWrite(4,HIGH);                       // hp 1   <- this line fails 

I have the break; before the digitalWrite !!! what a dummy!

How can I mark this as resolved? Multiple compounding errors.
Feel free to delete the whole thing, dont want to waste any more of anyone’s time…

1 Like

Don’t worry about it… :smiley:

it is human nature to think the issue with the new thing we are just trying, must be due to a problem with the new thing itself. I see lots of “Blynk is broken” posts from new users, stuck in their Arduino programming ways… heck, I posted many myself, generally followed up by answering my own questions before anyone else could. I guess the process of writing it down got the Synapse firing :zap::laughing:

All I was trying to point out was that it was unlikely the case this time and make suggestions based on my two years of using Blynk and working on this forum almost every. single. day. :astonished:

We generally leave these topics as they still contain some gems of info… not that many search and read them before asking anyhow :crazy_face: Oh, well… we try… :slight_smile:

Good to know… Sparkfun did something right! You threw me off track using the D4 reference :wink:

yes, I am well aware of that tendency, and that is why I made a whole new sketch to isolate the problem, and it behaved in the identical manner, but for a different reason.

There is also a tendency for old hands to think that new members are also new to engineering and software development!

Hehe… to be blunt… I don’t care what other users skill sets may be… My “tendencys” are based on my experiences in this forum and others. If new members ask for help, then based on how they do so and whether they show tendency to ask first, read first, or just expect handouts, I answer accordingly. If they are smarter then me, then shame on them for using my Google/research skills on their behalf, if not, then they learned something. Either way I try to help guide them whilst learning for myself along the way :smiley: Win Win!