I have also used NodeMCU, but I had same behavior on ESP07, so it’s not related to board exclusively. One pin connected to button in app will go high, no matter what pin is used, even if using only one pin and one button. I haven’t tried Wemos without using virtual pins, so I don’t know.
Maybe but WeMos copied most of the NodeMCU even down to the “wrong” resistors on the AO port.
I only have one NodeMCU and it’s tied up.
Why are you doing this? It’s not something I bother with as all my projects are just left running forever and I probably have close to a hundred projects.
Questions to you and @zodiac
-
Are you using NodeMCU in the IDE. I always use Generic for all boards?
-
If you enter the following in a browser do you have some strange pin references right at the bottom of the project listing?
Yes, I always specify right board in IDE. So NodeMCU was programmed with NodeMCU v1.0, Wemos with Mini D1, ESP01 and ESP07 with generic ESP8266 board.
I’m afraid I don’t understand your second question.
As zodiac I specified the board “NodeMCU 1.0 ESP-12E Module”
I didn’t know that generic works as well.
As I am currently using my NodeMCU with virtual pins I don’t get any strange pin references but I’ll try tomorrow without it.
and about that. I did it on to change the buttons and just noticed this behavior. I just wanted to let you know. Now that its up and running i wont stop it 
And BTW wow 100 projects. Sounds like you even control your toilet flushing withh blynk 
I am trying to say that is wrong. Generic is the only one that has full IDE debugging.
Does the json file that you see in the web broswer end with data similar to this?
[{"id":0,"name":"VidTest","boardType":"ESP8266","connectionType":"WI_FI","connectTime":1515770676432}],"theme":"Blynk","keepScreenOn":false,"isAppConnectedOn":false,"isNotificationsOff":false,"isShared":false,"isActive":true}
I checked some projects recently and they had some extra fields and from memory they related to something like “pin status”. They might have been projects left over from Blynk’s recent pin bugs that they fixed.
{"id":1240031533,"parentId":-1,"isPreview":false,"name":"testproject","createdAt":1515791267580,"updatedAt":1515791531445,"widgets":[{"type":"BUTTON","id":129961,"x":3,"y":2,"color":600084223,"width":2,"height":2,"tabId":0,"isDefaultColor":true,"deviceId":0,"pinType":"DIGITAL","pin":4,"pwmMode":true,"rangeMappingOn":false,"min":1,"max":0,"value":"1","pushMode":true},{"type":"BUTTON","id":177010,"x":3,"y":4,"color":600084223,"width":2,"height":2,"tabId":0,"isDefaultColor":true,"deviceId":0,"pinType":"DIGITAL","pin":5,"pwmMode":true,"rangeMappingOn":false,"min":1,"max":0,"value":"1","pushMode":true}],"devices":[{"id":0,"name":"testproject","boardType":"ESP8266","connectionType":"WI_FI","connectTime":1515791526285}],"theme":"Blynk","keepScreenOn":false,"isAppConnectedOn":false,"isNotificationsOff":false,"isShared":false,"isActive":true}
Couldnt wait till tomorrow… btw I tried with “Generic ESP8266 Module” same issue here
sorry that was wrong I just realized that the upload failed so generic doesn’t work for me…
You just have a regular sketch right?
Are you using GPIO references or silkscreen D references in the sketch?
I re-checked the pin conditions of the WeMos and NodeMCU and the only difference on boot up relates to the onboard LED for the NodeMCU.
WeMos
0: 1
2: 1
4: 0 // previously shown as 1
5: 0 // previously shown as 1
12: 1
13: 1
14: 1
15: 0
16: 0
NodeMCU
0: 1
2: 1
4: 0
5: 0
12: 1
13: 1
14: 1
15: 0
16: 1
Data above is obtained with Generic as the board type in the IDE. If for example you set pins 4 and 5 high with Blynk and then reboot the WeMos / NodeMCU they retain their high status.
I am using the following function directly after the initial Serial.begin() and before the Blynk.begin() in setup(). The function is also called at 3s intervals with BlynkTimer.
void displayPins(){
Serial.print(" 0: ");
Serial.println(digitalRead(0));
Serial.print(" 2: ");
Serial.println(digitalRead(2));
Serial.print(" 4: ");
Serial.println(digitalRead(4));
Serial.print(" 5: ");
Serial.println(digitalRead(5));
Serial.print("12: ");
Serial.println(digitalRead(12));
Serial.print("13: ");
Serial.println(digitalRead(13));
Serial.print("14: ");
Serial.println(digitalRead(14));
Serial.print("15: ");
Serial.println(digitalRead(15));
Serial.print("16: ");
Serial.println(digitalRead(16));
}
If pinMode(x, OUTPUT) is called for the 9 pins then the NodeMCU shows the status of all pins as LOW irrespective of the last pin setting in Blynk.
Serial Monitor is obviously just a snapshot of the pins at any given time so it would be possible that some of the pins have gone high or low before or after the Serial.println() function is called.
These tests were based on Blynk library version 0.4.10 and using the cloud server.
If you are seeing weird behaviour from your NodeMCU you might want to sprinkle your sketch with the displayPins() function.
Edit: I might have just seen the “issue” referred to in the first post.
I created a new project.
Button on GPIO 4 copied to GPIO 5.
The NodeMCU is booting with last known state for both pins as high before Blynk kicks in.
Once Blynk is connected GPIO 4 is shown as low.
This is probably the same as the OP’s issue but in reverse based on active LOW relays.
In the first project test I created GPIO 15 and then copied to 16, 4 and 5. There didn’t seem to be any problem with this. Will test further.
1 Like
Just created a new project.
First GPIO 14 button, copied to 4 and 5.
GPIO 14, i.e. the first button created is going LOW when connecting to Blynk others are fine.
As soon as GPIO 14 is deleted GPIO 4 goes LOW i.e. the “latest” oldest pin created.
As soon as GPIO 4 is deleted GPIO 5 goes LOW i.e. the “latest” oldest pin created.
This is quite clear to see with the displayPins() function.
I don’t know if it’s an issue related to copying the buttons or just the sequence of pins used when creating them.
My first test missed this issue because I started with GPIO 15 that always boots low and we were probably confused by the reference to HIGH in the subject of this thread. I think the OP means LOW and it’s a confusion regarding active LOW relays etc.
I will check to see if the problem is NodeMCU specific etc.
Applies to WeMos as well as NodeMCU, presumably a problem for all ESP8266’s.
@Dmitriy see Serial Monitor below that highlights the Blynk “bug”. First part is before connecting to Blynk showing GPIO 4 and 5 as their last known states i.e. HIGH. Once it connects to Blynk the first button created i.e. GPIO 4 goes LOW. If you were then to delete the button tied to GPIO 4 you would see GPIO 5 go immediately LOW.
0: 1
2: 1
4: 1
5: 1
12: 1
13: 1
14: 1
15: 0
16: 0
[51] Connecting to GargoyleTest
connected with GargoyleTest, channel 1
[551] Connected to WiFi
[552] IP: 192.168.10.226
[552]
___ __ __
/ _ )/ /_ _____ / /__
/ _ / / // / _ \/ '_/
/____/_/\_, /_//_/_/\_\
/___/ v0.4.10 on Arduino
[5001] Connecting to blynk-cloud.com:8442
[5170] Ready (ping: 86ms).
0: 1
2: 1
4: 0
5: 1
12: 1
13: 1
14: 1
15: 0
16: 0
All, until the bug is found then the temporary fix is to simply ensure that the first button you create is a dummy button i.e. one that you are not going to use in the sketch. Alternatively use pinMode(x, OUTPUT) to ensure all pins are low on bootup. I have edited the subject line to LOW rather than HIGH.
1 Like
Sorry, I’ve already forgot, you are right, it was going LOW, not HIGH. I’m using LOW triggered relays.
@Gunner could you please check if the bug applies to Arduinos. I’m guessing it applies to all MCU’s but it could be ESP specific.
Cool that my issue was reproduce able for you.
Before I used the virtual pins I also tried with the dummy button.
So this might be a bug after all.
BTW sorry for messing up low and high and thx for correcting it.
For sure.
Sorry, wasn’t following this topic that close… are you referring to some multi-button test with direct pin control?
So no additional code aside from connection, and I am looking for pins that boot high without virtual button intervention when App starts?
I will dig out an arduino and see what I can do. I can’t remember how NOT to use code now 
Ironically, despite starting with Blynk so that I DIDN’T have to code, I jumped right to vPins and coding 
@Gunner yes direct pin access, 2 buttons say GPIO 4 and 5. Not sure if Arduino pins remember last state on reboot but none special ESP8266 pins do.
Set GPIO 4 and 5 HIGH with Blynk and then reboot Arduino.
If Arduino has the bug GPIO 4 will boot LOW and if you delete GPIO 4 then GPIO 5 will go LOW as soon as you delete GPIO 4.
@Dmitriy I checked the “button removal bug” with Arduino (Mega with Ethernet) and it looks like it only applies to ESP8266.
However the “reboot bug” does seem to apply to Arduino’s as well as ESP8266’s.
Serial Monitor below is for a Blynk button on digital pins 4 and 6. Starts with pins HIGH and on reboot pin 4 is still high after reboot but before Blynk starts. Once Blynk connects the pin goes LOW.
Strangely pin 6 that was HIGH before reboot goes LOW even before Blynk kicks in.
Ignore references to pins 5 and 7.
4: 1
5: 0
6: 1
7: 0
Rebooted
4: 1
5: 0
6: 0
7: 0
[53]
___ __ __
/ _ )/ /_ _____ / /__
/ _ / / // / _ \/ '_/
/____/_/\_, /_//_/_/\_\
/___/ v0.4.10 on Arduino Mega
[5001] Connecting to blynk-cloud.com:8442
[5947] Ready (ping: 96ms).
4: 0
5: 0
6: 0
7: 0
Look, no Blynk block.
Ethernet still connected.
4: 0
5: 0
6: 0
7: 0
Look, no Blynk block.
Ethernet still connected.
4: 0
5: 0
6: 0
7: 0
I am guessing some of this relates to the way you are allocating pinMode() for the pins and all our tests are based on there being no pinMode() calls in our ESP and Arduino sketches.
1 Like
That’s correct. Most probably library issue. 1 pin goes LOW on ESP8266 after boot · Issue #391 · blynkkk/blynk-library · GitHub
1 Like