Advanced Warning - next library update will send ESP pins low on bootup

This is marked for reference and help wanted, so community members are welcome to investigate it further, to understand what exactly goes wrong. It might be a bug in ESP8266 Core.

@vshymanskyy I accept what you say but Serial Monitor suggests a Blynk issue.

There are 2 bugs:

  1. When we delete your first button is sends the second button LOW. Almost certainly your problem.

  2. Connecting to Blynk is sending first button LOW. Could be core related when WiFi connects but probably Blynk related.

Yes but we do nothing more than call to pinMode. It may be causing this issue by itself on ESP8266.
This is not treated as high priority issue so more investigation is welcomed to resolve this asap.

@vshymanskyy not for bug 1. but possible for bug 2.

Will leave bug 1 with you.

Let me know where you call pinMode() in your libraries and I will do more testing for bug 2.

@Costas Agree. https://github.com/blynkkk/blynk-library/blob/master/src/BlynkApiArduino.h#L94

1 Like

@vshymanskyy a few observations regarding pinMode() for “bugs” 1 and 2.

Blynk buttons require pinMode() as OUTPUT rather than the default INPUT so pinMode() is specifically required. Calling pinMode(x, OUTPUT) should set the pin LOW and this is what’s happening in Blynk so maybe not a bug in itself.

But your iterator (variable “it” I believe) would be expected to iterate through all the OUTPUT pins in the project. It seems to be just applying pinMode() to the first pin created and it’s not numerically based say from 1 to 4.

Presumably this is because you use a json file for the project and this contains data in the order the pins were created i.e. if pin 5 was created before pin 4 then pinMode() will be applied to pin 5 but not pin 4.

This would explain why deleting the first pin created then gives rise to the “bug” for the second pin created, irrespective of pin numbering sequences.

So I would say it’s a single bug whereby Blynk is not iterating pinMode(x, OUTPUT) to all the required pins in the project rather than wrongly setting the “oldest” pin to LOW after boot or editing the project.

If you agree that this is the issue could you please check why the iteration is failing.

All Blynkers - this is why virtual pins are recommended because you can then easily sync the pin status to the condition prior to the MCU rebooting. If the iteration is “fixed” all digital pins that are required as OUTPUT will be LOW on reboot or when you edit the project.

2 Likes

Thanks. This well might happen, thanks for your input! I’ll check this scenario

1 Like

@Costas @Georg1811 @zodiac could you check on the latest master branch?

1 Like

@vshymanskyy master branch looks to be working fine now.

Resets all Blynk button pins that are in the project as LOW when Blynk connects. Also removing a button doesn’t change the pin status of any of the other Blynk button pins.

Great work.

2 Likes

Yes, it’s fine now, thanks!

@vshymanskyy when you issue the next library update can please you add a note that some systems that use direct pin access will “break” i.e. users with active LOW relays etc but that the new library is actually a fix for their broken systems that they may not have been aware of.

Personally I would never touch direct pin access as your virtual pin system is way better.

4 Likes

I am hoping because I have not had any issues with this “bug” that it will not really be an issue for me, but I just wanted to clarify something.

Will this “will send ESP pins low on bootup” only apply to GPIO pins that are attached to button widgets in the APP, or will it apply to all pins regardless of their use.

@Toro_Blanco I would say all widgets in the CONTROLLERS section that use direct pin access and possibly other widgets too. Assume everything until we know otherwise.

#define BLYNK_NO_BUILTIN  // Disable built-in analog & digital pin operations

I tend to use this command in most of my sketches anyhow… mainly because I only use vPins and it supposedly saves on resources.

I am guessing that running this command will also nullify whatever effects this “bug” and/or its replacement would have… leaving all physical pins in their “natural” and hopefully predictable state… ripe for vPin manipulation of normal digital and analog pin commands.

4 Likes

@Gunner absolutely right!
regarding digital pins-only those you select in any widget are affected. Not all mcu pins, that would be crazzzy :wink:

1 Like