@distans can you also post a screenshot in development mode i.e. so I can see the pin settings of the widgets.
I want to set up your system here for testing but it might be a few days as my desk is covered in projects at the moment.
You might also want to add timestamps to the Serial.println() and virtualWrite() to Terminal calls, to see when the RF signal is being sent (through the night).
Ehhā¦?! 
How do I enable dev mode @Costas? Canāt find it anywhere Iām afraid! 
(using Android app 2.16.2)
I added timestamps in the scheduler a couple of weeks ago when it started the scheduler and lit up my bedroom. If I remember it correctly it did so at around 02:30. Now itās ending it instead (at a later time). Iāve added an extra timestamp to the virtualWrite() now.
Thatās why I also have a floor! 
Take your time!
Stop the project and take a screenshot.
I was looking for some hidden menu or setting that Iād missed 
Now Iām looking for the faceplant emoji 
I have done some minor changes to the code, but thatās mostly on how to read the sensor without delay so it should not affect the schedule. Guess I will know for sure tonightā¦ The new code and details will be uploaded in a Projects made tomorrow I think.
Eventor is also removed from the app.
Donāt forget common ground when you hook up the devices.
I think that @costas wanted you to It the square (stop) symbol in the top right hand corner of the screen (so that it changes to a VCR play symbol) then take a screenshot.
That way, heāll be able to see which pin the widgets are attached to.
Pete.
Feeling kinda stupid now! 
I uploaded a screenshot showing the pins, but then I remembered Iād removed Eventor so I made an new one. Of course I forgot to put it in dev mode! The dubble faceplant emoji isā¦ where? 
Thanks for bringing it to my attention @PeteKnight
@Costas, here is some data that might confuse you as well:
Timer set to 14:15 - 23:30, extra finish run at approx 05:18 = stop time + 5 h 48 min.
Timer set to 14:15 - 20:30, extra finish run at approx 02:18 = stop time + 5 h 48 min.
Thinking it might has something to do with the duration of the run time (Iām out of ideas, testing everything), this morning I changed the timer to 07:45 - 08:15. No extra run yet! I have looked at the code so many times Iām probably blind to flaws now.
Anyhow, a better screenshot for your amusement 
Latest code and a write-up about the project:
I assume your desktop is still swamped? Iām just keen to know how it works out for you, no hurries! 
Itās clearing slowly.
Minor update: Switched to local server, but the unscheduled scheduling still persists. The only notable difference is that it yet again sends the ON signal instead of OFF in the middle of the night! 
For reference, Iām not an early riser 
And I still canāt believe Iām the only one with this weird problem hehe.
Over the last few weeks we have noticed some strange scheduling events but ours have been at exactly midnight. We are not quite sure what the issue is at the moment but we are trying to track it down.
Our issue is the opposite of yours whereby we are seeing an unwanted OFF from our system, whereas you have an extra ON. I havenāt had chance to compare your code with ours but if we are using active low relays and you are using active high then it could be the same issue.
Just doing a cut and paste of the data you provided earlier in this thread:
Your profile states you are in Sweden so I believe you are GMT +1.
We have up to 6 timers in our project. Please confirm you just have 1.
Will report back if we find anything.
@Dmitriy regarding Time Input we have noticed the following anomaly:
unsigned int startseconds = (0 * 3600) + (0 * 60); // gives the expected result of zero
but with the Time Input set with a reset time of --/-- the result of the following calculation is 4294967280
unsigned int startseconds = (t.getStartHour() * 3600) + (t.getStartMinute() * 60);
This indicates with a reset time of --/-- the t.getStartHour() and or t.getStartMinute() is not zero.
What value / String does Blynk hold for t.getStartHour() and t.getStartMinute() with a time of --/-- ?
For anyone reading this you need to ensure you keep your code within:
if (t.hasStartTime()){
}
and the same for the t.hasStopTime() to ensure your code isnāt triggered when you use the reset time feature.
For anyone using our EziScheduler code you need to ensure none of your timers have the reset time of --/ā
Unless you modify the code, reset time has the potential to crash your ESP at midnight local time, every night.
We never use reset time ourselves as we find it much easier to simply disable the days rather than playing spin the wheel to set hour and minute when we want to re-activate a timer. If you are going to deselect days you need to ensure you have the 2 character library hack so no days really means no days, rather than all days as itās currently coded in Blynk.
@distans I donāt think this covers your bug though.
Itās just because we are using active low relays. In fact, it does not matter if it goes on or off when nothing should happen. The problem with my home setup was cleared when I stopped using reset time in the app. But Iām absolutely sure this problem is related to 2.17.0 and 2.17.1 Android app version, as I tried reverting to 0.4.8 and installing 0.5.0 Beta, also tried 3 different server versions, and itās same in every scenario.
So, using --:-- together with days selected is a big NO, no matter if youāre using basic, advanced, or some of EziScheduler versions of the code behind Time input widget.
Also, if you have an app made with 2.17.0 and your code has Blynk.syncall() function included, it will not work. Clone of that app made with 2.17.1 works with the same device/code/lib version without problem.
And one more observation, also came with newer versions of Android app: If I have started my relay at, letās say, 20:00 with Time input widget and stop it at 20:02. Light goes on at 20:00 and then off at 20:02. Then in next 10-20 seconds, I turn on the light by button. It switches off at 20:03, just like Time input finished it for the second time.
Iām telling all of this because Iām absolutely sure midnight ghost problem has nothing to do with Time input widget or backing code, as --:-- with selected days did nothing before. It seems that ESP pwm pins control with Blynk can be erratic in some versions, affecting other actions as well.
I suspect if EziScheduler only obtained startseconds and stopseconds within their respective functions then --/-- would be fine.
We are testing this issue for how long, Costas? Maybe 4-5 days, spending hours testing and trying to find the cause, delivering tens of messages per hour to each other?
After all this mess, just leave it.
It works if no --"-- is used, it was stupid of me to try just about everything, and finally having --:-- and all days selected in my projects by default was totally unusual scenario.
I suppose this issue will disappear just as it arrived, now we know how to avoid the problem until that happens, at least.
ā:-- is fine, as long as no days are selected. But agree, --:-- should be avoided just for additional sense of security that we need fighting Time input midnight ghosts 
Just finished last series of tests:
Time input widget library at all 3 scenarios has mweeekdays set to 0, in order to avoid no days set = all days set.
So just avoid scenario No. 3.
That is because you have bugs in your code not because there is a problem with Blynkās Time Input widget.
See
I fixed your code and it works fine with reset time of --|- -
I will send you a sample of the debugged code.
@Dmitriy still interested in your answer to this: