If they were to implement it with a restoration of the GUI time input connected to automation I think that would be brilliant. Best of both worlds. Especially if the GUI time input had the new automation time selection interface. And there would be no need for our complex code sorting when to trigger our own time dependent functions.
Yes an interesting “omission/change” indeed, I just hope there is an elegant solution.
My problem is that due to lack of WiFi connectivity for some irrigation control projects located on a friends farm, I have to run a RTC plug in board in the background that I program with the schedule times. These times/days I pick up using a temporary hotspot and save from the information from the Timer Input widget so relying on a simple 1/0 trigger will not work in this case.
We also live in a country where everyday power outages are a part of life and WiFi connectivity is a luxury…so we have to innovate 
2 Likes
@Badge. I agree with you. The Rtc Time Tool should be available and we use it in any condition or condition. I use it a lot when the internet is interrupted, the timer works without the need to connect to the server also when the specified time matches, a specific command is executed and recorded on the terminal. It is a necessary tool and it cannot be replaced by automation unfortunately.
RTC is unrelated to time input, timers, or Automations.
RTC is now provided as API. No widget required.
1 Like
@Pavel We were previously defining the time and setting the time zone from the blynk server. We also use time input to perform the operations. I hope the update is identical to the above. Thank you for your efforts
Ok. But how that differs from the creating an automation? You do the same here, aren’t you?
Or you’re saying that you store it on the hardware side and process it on the hardware, not the server and that’s the main point? If so - we’ll introduce offline automations soon that will be stored/executed on the hardware.
However, that will be fully configurable on the UI, so you don’t have to code anymore.
This is basically what I do as well on my farm based irrigation project where I have no WiFi connectivity. I read the Timer Input widget settings (start/stop times & days) via a hotspot and save these settings to an irrigation schedule to program my hardware RTC. After this the code can execute the schedule without a server connection.
In my case I do have to code in my hardware, without WiFi connectivity/Server I do not have an option, and need to have the Time Input widget settings.
Yes I agree that there is no direct coupling of a hardware based RTC, however in my case I use the Time Input widget to program my RTC with start/stop/day information
The API is of no use to me for the reasons given above.
You seem to indicate that am Automation widget (I presume similar to the Timer widget) is a possibility and that the request for this was trending. I then get a feeling that there is now some resistance for one in following up conversations, but I could be wrong.
@Badge, I think you’re getting confused between the Blynk RTC, which was provided via an RTC widget in Blynk 0.1 and won’t require the a widget in Blynk 2.0, and a hardware RTC.
The Blynk RTC is a method of getting the current time from the server when the device is connected to the server. You can then use this, along with the time library to either set the device’s internal RTC or an external hardware RTC. Presumably this is what you are currently doing when you connect to your device, unless you’re using a call to an NTP service?
The problem at the moment is that the RTC widget has been removed from Blynk and the details of the API call that replaces the previous call to the RTC widget hasn’t yet been published.
My reading of this (and I may be wrong) is that it wouldn’t make sense to have a widget that replaces the Timer/Time Input widgets that doesn’t interact fully with the Automations functionality.
There is clearly a need to simplify the inputting of start/stop times, days of the week, Timezone etc via the device tile UI rather than via the Automations menu, especially when you run multiple timer cycles which may or may not span midnight.
However, this needs to effectively be a front-end for the Automations rules, as you don’t want two time based rules engines running at the same time.
I’d imagine that this is where the issue lies, especially when the plan is to introduce off-line automations too in future.
Blynk need to be clear about what is needed and why, and the water gets muddied when other users come along and start talking about RTC APIs 
My personal view is that the old “Timer” widget (the simple one that sent a 0 or 1) is redundant, as Automations could easily be used instead.
The old “Time Input” widget was extremely useful, and although probably very few people used the Timezone feature, I can see how dropping that functionality would be a backward step, especially trying to sell the product to organisations that have facilities in different timezones.
How exactly the process works once you’ve provided the user with the facility to input star/stop times, active days and timezones is irrelevant at this stage, that can be handled easily in code, but the key issues is that a single app-based UI is what seems to be needed, to simplify the end user experience.
Pete.
No confusion my side 
.
My hardware has a built in RTC, the lack of a Blynk RTC widget is not an issue. Initially I setup my hardware RTC with a NTP service call.
Where it is critical to me is that after setting up my RTC I use the information provided by the Timer Input Widget to get the Start/Stop/Day settings, after that I can go offline and run autonomously. If I want to change the settings I create a hotspot and update the change then go off line again.
Agree.
The old “Time Input” widget was extremely useful, and although probably very few people used the Timezone feature, I can see how dropping that functionality would be a backward step, especially trying to sell the product to organisations that have facilities in different timezones.
How exactly the process works once you’ve provided the user with the facility to input star/stop times, active days and timezones is irrelevant at this stage, that can be handled easily in code, but the key issues is that a single app-based UI is what seems to be needed, to simplify the end user experience.
I think @koaiwi and most certainly I are with you on this one that it would be a step backward. And as you say
@Pavel In summery my only request is to retain the Timer Input Widget, nothing more.
Les
But you need to send the selection of the TimeInput on UI to the hardware, right? So automation will do the same. So it’s totally the same. The only difference you use automation instead of the TimeInput.
We have such clients and they use automations. And offline automations is their requirement.
Yes that is correct I send the Time Input parameters to the hardware, All I want to be able to read the start/stop/day setting in the same manner as I did with the original Time Input Widget. This would simplify things significantly if the the Time Input widget remains even under another name.
However I did ask the question right at the beginning of this thread. See the start for details and the response as I see it that would no longer be possible. You can only get a trigger 1/0 and not read the start/stop/day settings into the hardware
For me hold onto that thought as a starter. But getting the parameters (start/stop time etc) like we can now from the time input widget would be a must as well so we can use them within the code. I too have that requirement.
1 Like
Is there still a plan to sort out the “Time Input Widget” ?
This widget does not even come close to what we had on the original, for all the reasons given in this thread. In its current form it’s a cumbersome mess (sorry for that) 
4 Likes
Ditto for me. It would be the single reason I would not migrate willingly. Unless old blynk became unusable. I’m guessing I could survive on old blynk with the latest version of the app and local server if and when old blynk is put to the sword. @Pavel @Dmitriy
2 Likes
The main reason I choose Blynk over other platforms is the time input. I am managing more than 50 agricultural projects and they are all far from where I live. Using time input in combination with <TimeLib.h>, <WidgetRTC.h> instead of a trigger from the blynk server gives me complete peace of mind that the system will still work even if the internet connection is lost. In fact, I have used it on many devices from different backgrounds (sonoff .etc…). and had a lot of trouble because trigger from sever didn’t work because of internet problem. I advocate keeping the time input.
1 Like
Please stop tagging people without a need. Especially Blynk team. We read every topic.
1 Like
Does anyone know if it’s possible to combine execution of an automation based on time with a condition from a switch in Blynk app? For example I have an ON/OFF/AUTO switch in app. I want to execute automations (based on time and day) only when switch is on AUTO. If it’s ON or OFF I don’t want to use automations.
@spehj
I guess this is not possible. Because all the automation is purely happening on the app n cloud side. There is no code involved. So we cannot read or give input to the automations.
One way i can think of is : to turn on or off the automation card on the app. Anyways you would open the app to select AUTO / ON / OFF … instead just turn on or off the particular automation card. This sounds easy.