@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.
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.
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.
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.
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)
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
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.
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.
@Madhukesh I’ve found a solution for this one on a firmware level. I will write code to handle the machine operations based on ON/OFF/AUTO switch. In ON mode, machine will be permanently switched ON in OFF machine will be shut down and timers will be used just in case of AUTO mode selected. Not a pretty solution but it will work I guess.
The new Blynk version 2.0 does not have the Eventor widget. How do we use it in the new version.
Second how can we use timer in our home automation system.
Its all carried through the new automation option. No need to use Time input or code anything on the hardware side… just upload the basic sketch with few digitalWrite function. And the rest will be taken care by the Blynk server. Internet required !!!
I want to turn OFF or ON my devices within a certain time. In the old version I used to do this with timer widget or Eventor. The new version of blynk 2.0 does not have a timer widget or Eventor option.
I don’t see automations option anywhere plz guide how can i use this option as a timer to devices ON or OFF for specific time interval using virtual pins.
.
