Correct… based on my testing, with the built in function disabled you should not be able to read or write directly to analog or digital pins from the App.
And if you are using virtual pins, you should have the built in disabled as I suspect it will cause issues eventually. I wouldn’t call this a bug so much as a conflict of resources.
Also, in the past it seems having widgets set for both reading rate and PUSH can cause timing issues.
Well, it’s in BlynConfig.h, so it should be…
so why can I still operate the digital pins directly from the app?
I suspect you have something goofy in your code… from what you have implied, it is complex.
Try changing the position of the command… this is what I have in one of my more complex sketches at the very beginning of the code…
// ===== Variable Setup =====
//#define BLYNK_DEBUG // Advanced diagnostic data... also drasticly slows entire sketch
#define BLYNK_PRINT Serial // This prints to Serial Monitor
#define BLYNK_MAX_READBYTES 1024
#define BLYNK_MSG_LIMIT 0
#define BLYNK_HEARTBEAT 60
#define BLYNK_USE_128_VPINS
#define BLYNK_NO_BUILTIN // Disable built-in analog & digital pin operations
#include <ESP8266_Lib.h> // ESP-01 Link
#include <BlynkSimpleShieldEsp8266.h> // ESP-01 Link
And this in another…
#define BLYNK_MAX_READBYTES 1024
#define BLYNK_MSG_LIMIT 0
#define BLYNK_HEARTBEAT 60
#define BLYNK_NO_BUILTIN // Disable built-in analog & digital pin operations
#include <ESP8266WiFi.h> // For Blynk
#include <BlynkSimpleEsp8266.h> // For Blynk
ok moved those two way to the top of my header file and it now appears to be working (or not working as the states indeed no longer update). Now I again need to wait a few hours to see what the long term effect is. Ill report (once more) in the morning. thnx all for the help, much appreciated!!
Can you not adjust your timers for testing?
PS you may or may not want your heartbeat detection to wait 60 seconds instead of the default 10… I am sure that line is relevant to your situation
timers are one minute, unreliability issues kick in after 15 minutes to a few hours. Currently everything is working correctly, but it so far has always worked ‘correctly’ (save my own bugs) for the first 15 minutes or so.
PS the heartbeat I’ve just added new to the code, I get quite a few ‘disconnects’ from my units while they’re still ‘connected’ according to the router, less however since I’ve grouped all the one minute timed routines into one main routine, but occasionally it still (dis)connects, want to see if this heartbeat resolves that issue.
The relays are still working, however some vpins in the app now no longer update. If I manualy change the Temp the relays go off (as they should) but the app no longer updates. Only the horizontal step widget shows the correct T, the rest remains ‘stationarie’. Less of a big deal, but still buggy…
edit: took a minute, app is responding again…weird stuff.
Anyway: unreliability issue appears to be gone and apparently was caused by NOT using this line (waay at the top of my code):
#define BLYNK_NO_BUILTIN
the last question that remains now is: is this a Blynk bug or not? As i said: if I remove buggy parts of blynk which results in working code, that does not mean that there isn’t a bug in blynk.
The question remains… why does it affect your code more than others? I often have that line uncommented as I run other tests on my heavy laden 24/7 testbench system running many counters and sensors. And quite honestly, don’t even have it in many of my other smaller sketches.
Bug or just conflict with code, what being it a redundancy with proper coding practices… only the developers can say, and only if they feel it worthy of resources.
But If you can supply repeatable examples I am sure they will investigate…but even if provable (AKA my map issue) it seems quantity of complaints count as well. So I will comment it out on a few of my sketches, and if I run into something I will let you know 
that I fully agree with.
good question, as said, Im running it on wemos d1 and it might be specifically related to that board. However if most wemos users mainly use it to e.g. a wheather station, then they’ll never run into this issue. Also keep in mind that it took me a week to figure out what on earth is going on AND I’m an active forum user. So other users have to comply to the following filter:
using Wemos AND using relay AND identified issue AND be active on forum AND NOT use the #define line initially.
Currently that filter resulted in no found: 1.
yeah, thats the joke concerning ‘unreliability’ if its a simple yes/no bug then examples are easily created but if it ‘happens after a while’ there might be many other factors involved, in my experience it usually is a memory leak, which would mean that if you create a simpler version of the code that the issue might not occur at all or maybe after a few days.
Anyway, for me now its case closed, I’ve found a workaround to the issue. Its up to the devs to either pick this up or not.
Again: many many many thanks for your time and effort especially @Gunner and @marvin7