I understand that with Blynk 2.0 there is no longer a timer input widget. It has to be set up like this Automations - Blynk Documentation
From what I see:
You can’t set a Start/Stop/Day Time in one place (only a trigger start time and a Day selection)
Once you selected a Trigger Start time, to carry on you need to select an “Action” by selecting a notification (In my case I don’t want one) and only then can you “Save Automation”
There is also no way of linking the trigger time to a virtual pin that I can then interrogate from my software
The only way I can see an Automation link to a virtual pin is by selecting a “Device State” that you can couple to your project but this then has no start/stop/day time option, and once again you need to have a notification setting to save!
Once you have set up your Automations there is no way of changing the time other than to delete it and start again.
All these settings seem to be divorced from your main app on the phone app (they appear out side the little project block)
I also have no idea how this all links back to the software on your device, and how one would gather data of the Start/Stop/Day schedule as one was able to do on the previous version see code snippet below.
//...........................................................................................................................
//AM_Schedule Start and Stop Times
//...........................................................................................................................
BLYNK_WRITE(V20){
TimeInputParam t(param);
byte day_data[8];
long startTimeInSecs = param[0].asLong();
long stopTimeInSecs = param[1].asLong();
//get the valid dyas
for (int i = 1; i <= 7; i++) day_data[i] = (t.isWeekdaySelected(i)); //get the current day of the week from the Blynk Cloud BLYNK days are 1(MON)----7(SUN)
Serial.print("Start time: ");
Serial.print(startTimeInSecs);
Serial.println();
Serial.print("Stop time: ");
Serial.print(stopTimeInSecs);
Serial.println();
}
I maybe missing the point completely so please bear with me I have been at this a few days now.
This is done, because we have clients with hundreds of datastreams, and choosing all of them in automations is really a pain, so you have to explicitly define such datastreams.
You can do that, by clicking on the time during the automation edit and clicking on “save automation” after the edit.
Please explain the use case. With automation you can do the next:
At 11:00 turn on device datastream. So at 11:00 server will send vrtualWrite command with body==1. So in your code you van just:
BLYNK_WRITE(V20){
param.asInt(); //1
}
or
You can use Sync the pin like in blynk 1.0 to get the latest value from the server that would be 1 in that case as well.
@Badge I’m with you on this one. Automation is very powerful but using it as a work around for the lack of time input is not good. I can see how @Dmitriy suggestions can work with code changes to my existing projects. But the real issue for me (as you point out @Badge) if you want to change the start/stop times for say a heating control (which I use extensively) you need to move from your project interface controlling your device, wade through the various automations to find the start AND stop automations and make the change. @Dmitriy there must be a reason for removing the timer input widget but I’m struggling to find a good reason myself. Timer widget yes OK with automation but the timer input I would have thought no. @Dmitriy any plans to bring it back in?
@koaiwi I see… So you’re saying the main no-go issue with automation is that it’s hard to find exact automation you need? Or that you need 2 automations to control the same device?
@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.
@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.
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.
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.
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
@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.
@Pavlo 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.
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.
