given the fact that I implemented that monitoring AFTER the issue to actually track down what on earth was going on, I doubt that that is the cause. However you’re right that it might make things worse!!
This brings me to the point: if I change the value reads into buttons to operate the pins directly, do the buttons change state when the pin state changes?? In short will the value be pushed instead of a read as it currently is.
Thank you though, i’ll make the changes.
I think, as a good practice for more advanced projects using VPins, it is good to disable direct hardware access with #define BLYNK_NO_BUILTIN
I have it hardcoded in BlynkConfig.h
and I have. I’ve only found out about (or thought of) direct pin acces last week, but only due to relay failures and me trying to figure out what on earth was going on. I’ve fixed the issue so I could remove the pin checks, however I still see discrepancy between the vpins and the actual pin states (which is the reason for this route in the first place). Basically I set a vpin at the same time when I change a relays state but a lot of times the app shows the wrong vpin state (its not updated) which made it hell on earth to figure out what was actually going on, that was the reason I started to look for other methods and reverted to direct pin state reading…
What really is a pain is that these issues happen ‘after a while’… if I reset or upload new code everything works peaches, but then the following morning I see a relay on with a vpin that tells me that its off or very recently the other way round, a vpin telling me its on, but the relays remains off.
That’s weird… It is unknown to me, but I’m not always “up to date” with new releases. It might, or may not be a Blynk error, but something is not right for sure. But instead of using direct pin manipulation try to read pin directly in code - I’m sure you will find a solution 
@wolph42 perhaps your device is resetting? Do you have pin syncing at startup?
BLYNK_CONNECTED() {
Blynk.syncVirtual(V0, V1, V2); // Syncronise these pin states at bootup and server connection
}
BTW the Red Issues and Errors are for Blynk bugs that have been identified as such, not general troubleshooting… which I think is more applicable in your case so far.
not resetting but they do occasionally loose connection and yes I do sync all relevant pins, but to no avail. Just now I’m looking at a Vpin that is ‘on’ while the relay is ‘off’. And if I manually lower the target temp (turning it ‘off’) and raising it again (‘on’) the relay goes on. I’m really at a loss as to why…
I’ve actually added an extra check in the thermostat to ‘force’ the setting every 15 minutes and checking the log it neatly shows 8 attempts (so 2 hours long) of updating the vpin of the relay. This started on 19:59 looking at the relay log, the last ‘reconnection’ attempt was (successfully) at 17:19 and has been online since…
edit: and yes I’m still convinced that there is some bug in blynk which is why I set it to ‘issues and errors’. If stuff stops working ‘after a while’ or is unreliable and sometimes works and sometimes not, it has to be something deeper then the code overlay that I write. Granted this might well be a mixture of the two (bug in my code and bug in blynk) as it covers multiple issues.
her another one also related. I’ve updated some logs for the relays to get more input and the log shows:
“START PUMP”
There is only one line in the code which has that log statement and that is this part of the code:
toTerminal("START PUMP");
pinMode(HEATER_RLY_PIN_PUMP, OUTPUT);
digitalWrite(HEATER_RLY_PIN_PUMP, LOW); // activate = LOW, deactivate = HIGH
resetMaintenanceTimerPump(); // reset maint. timer for pump as its now running.
the pump relay state however remains HIGH. While the Valve relays does go LOW. There are other pump operators in the code but they all report to the log, so if some other routine would sneakily turn it off immediately it would show up in the log. Note that this happens ‘sometimes’, usually when there is no user interaction, if I start playing with the temp (raising /lowering) it will set properly (with the same message). This makes it really really unreliable…
IF you really has issue in this piece of code, then I must “worry” you, as this simply CANNOT be Blynk Issue. There is nothing between these lines of code, that Blynk could do. It is just pure Arduino core here. Have you tried with 2.3.0 version of core?
EDIT: Well, there is one possibility however: shortly after that the pin is changed without notice…
irc I’m running 2.4.0 but I forgot wher you can check this. Any clue where to look?
NOte that I haven’t used
#define BLYNK_NO_BUILTIN
yet. So there is still blynk influence. Ill turn this on now to see if it helps.
Yes, DEFINITELY do it, at least for debug purposes…
Where to look for version?
yup!
Board manager, if under Arduino IDE.
2.4.0 is not recommended - it has some memory leak issues, if I remember. Shortly after its release there was 2.4.1 released
I think you mean ‘esp8266’ which is version 2.4.1
Yes… 
and we are talking about…?
you were talking about ‘core’. Hence the miscomprehension…
ok updated relays…again…and they’re working…again…now ill have to wait for 1 or 2 hours to see if they start failing.
Ah, OK. Arduino ESP8266 core version. Try 2.3.0, or newest 2.4.1, avoid 2.4.0. Every board has its core MCU, hence the terminology 
yes, as I said, version 2.4.1 was already there and as said, everything has worked great for months (well numerous bugs and updates in my code, but everything worked as ‘expected’) recently however unreliability has started to kick in. Stuff working for ‘a while’ and then starts failing.
Hmm this is weird. I’ve added this at the top of my code:
#define BLYNK_NO_BUILTIN
but in my app I still see gpio pins updating to HIGH and LOW when I change temp. Shouldn’t this have stopped working?
Not good. Yet quite unusual.
I wonder, If you could read the mode of the output pin? Would be good to know if the reason is the changed mode. But I don’t know how to do it with ESP. Although it is “Arduino”, the direct hardware operations are completely (?) different…
ok this is really weird, the gpio buttons that I created in the app are also working. I can * still* turn on /off a pin with an app button (directly so no vpin) is that line correct:
#define BLYNK_NO_BUILTIN
to be certain I check the version numbers of the esps and they’re all running code with that definition in it. It appears to do nothing?