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.
1 Like
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 active between 23:50 and 00:05 (0.4.8 / 2.17.0) - working
- Time input widget with --:-- and no days selected (0.4.10 / 2.17.1) - working
- Timer input widget with --:-- and all/some days selected (0.4.10 / 2.17.1) - all assigned digital pins goes HIGH, not working
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:
1 Like
Already changed the code on 3 devices, I will do some tests during the day. Thanks, Costas!
1 Like
We just need to find a fix for @distans now.
@distans due to our ongoing commitments and requests from a well known “fruit” conglomerate it might be quite some time (read months) before we are able to build a replica of your project.
I spotted cloud.blynk.cc in your sketches so I am surprised it works at all as that server was retired years ago.
The cloud server is blynk-cloud.com
To debug your sketch we would suggest:
-
Set up a local server where you can easily change the time of the server, before the Blynk server starts, rather than have to wait until after midnight every day.
-
Build a very basic sketch that you can keep hooked up to Serial Monitor and just use an LED and Serial.println() for debugging.
-
Obtain as much data as possible and publish it here for others to study.
-1. So this is signed int :).
1 Like
@Dmitriy of course it is. Over the last few days I had assumed it was going to be -1 but I was overlooking the data type we had set for the variable. Another mystery solved and it makes modification to existing code easier, thanks.
1 Like
It doesn’t seem to be an exact science 
Now it’s back to OFF again! 
Correct and correct!
I’ll read the rest of the discussion more carefully during the evening and see if I have any input that might help.
Is that something used only when resetting? Because I can’t find it in my code!? 
I’m hoping it’s for the greater good you’re looking in to this and not just for my sake, i.e. there is a “real” problem somewhere.
Haha! That’s weird! The only thing I can think of is that both names resolves to the same IP. But I’m using local server at the moment so that’s should not be an issue.
cloud.blynk.cc canonical name = blynk-cloud.com.
Name: blynk-cloud.com
Address: 139.59.206.133
I will obey your commands! 
I can confirm that midnight ghost has gone for good in all three setups I have used for testing after code corrections suggested by @Costas.