@Dmitriy Both reasons. But only in applying automations to this workaround for a lack of the time input widget. It’s just not as easy from a UI perspective as the time input widget. Dare I say clumsy. Or in my day we called it piggy if the UI was awkward 
As I say Automations in their own right are good and the UI for them is OK. But not to replace the interactiveness of the time input widget as I use it.
1 Like
@Dmitriy not compared to the UI workaround. Coding in the device would be OK. Possibly better. I can see how the automation directing a 0/1 to a pin could then just point to my code (using IF or SWITCH) that would using the old blynk have to look at the now() and work out what to do with an if statement on the start and stop times obtained from para o and para 1.
You can see how easy it is for me to change start and stop times within the project dashboard.
That would require 8 automations. and I change the times quite a lot.
2 Likes
First of all, the main improvement for automation is coming. which is specifying END/Stop/OFF time within the same automation card. This is already a trending request.
Secondly, I can see @koaiwi ‘s point. Potentially, we can think of an Automation widget, which will create an automation from device view. Like a shortcut to automations.
And in the settings, this automation will be somewhat pre-defined by developer. Like: timer on/off for this device. Users will only need to input time and days.
Just a quick idea.
1 Like
Yes @Pavel & @Dmitriy . I think a combo of a dedicated time input widget that uses the automation functionality will be brilliant. I like the day/time selection UI of automation. Better than the current time input UI. And if the automation server when triggered flicks some predefined parameters (could be a simple 0/1 or more) to the connected VPin then this will make the code much easier. It will be a simple switch statement on the para then off to the relevant main code that does the business. My existing device code for the old blynk version that does all the conditional if/then on the widget time paras with result of the now() function will not be needed.
One use case I have needs to work across a 24 hr period. For instance I turn heating on at 10pm and off at 3am the next day. This is tricky with the current widget. I need to work out if start time is greater than finish time and if so add seconds from 1970 to the start and finish time and then 24 hours to the finish time time then update both the derived calculation by 24 hrs every day. I think the automation will handle this nicely with no intervention in the code.
If you understand the use case and have some ideas I’m sure you will crack it. But for now it’s a no go for me to convert to the current workaround…
Sorry I was away for a long weekend. Grant thank you so much for your support on this one and stating a case for the Timer Widget, you managed to articulate my frustration at the lack of it a lot better than I could. I spent quite a bit of time on the weekend wondering how to convince @Dmitriy when I got back 
The Timer Input in my opinion is one of the pivotal Blynk 1.0 widgets, and once you master the code (which is not that difficult or hard) it is super easy to implement. Besides my Geyser Timer project (Time Scheduler and Power Energy Monitor) I use the Timer function extensively in an irrigation project where I have several timers running schedules. I also use it to pre-program a RTC with the schedules as in some cases I do not have WiFi connectivity and use my phone as a hotspot to update the changes.
The implementation of the Timer Widget in 1.0 is elegant and neat and I find it difficult to understand why the change! I sincerely hope that we see it back as a widget rather than in its current form of implementation. It looks like the topic is taking traction and look forward to the idea of an Automation widget from a device viewpoint.
Les
2 Likes
Hello. This omission/change of functionality of the timer input is an interesting one. I’m not sure how it wasn’t picked up in the migration use case testing. There are a number of other changes that don’t work for me too. It’s mostly down to the more awkward navigation methodology of tiles. I quite like tiles for a small menu of options but when you have loads of options a hierarchical menu/tab system works best for me.
Maybe the hobbyist user has different use case requirements compared to the commercial users which understandably now are the focus of Blynk.
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