RF 433 Mhz on virtual pin doesn't want to send (with scheduling)


Ehh…?! :thinking: How do I enable dev mode @Costas? Can’t find it anywhere I’m afraid! :confounded: (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! :crazy_face: Take your time!


Stop the project and take a screenshot.


I was looking for some hidden menu or setting that I’d missed :flushed: Now I’m looking for the faceplant emoji :grin:
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.



Feeling kinda stupid now! :grimacing: 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? :smiley: 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 :wink:

Cheap(est) RF 433 Mhz bridge for home automation with both Tx and Rx

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! :smiley:


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! :unamused: For reference, I’m not an early riser :stuck_out_tongue_closed_eyes:

And I still can’t believe I’m the only one with this weird problem hehe.

Time Input Date Picker Problems

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 --/-- ?

Missing something with attempt to understand Advanced Time Input

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 :slight_smile:


Just finished last series of tests:

  1. Time input widget active between 23:50 and 00:05 (0.4.8 / 2.17.0) - working
  2. Time input widget with --:-- and no days selected (0.4.10 / 2.17.1) - working
  3. 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.


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:


Already changed the code on 3 devices, I will do some tests during the day. Thanks, Costas!