I am developing a product using Blink to control a motor at scheduled times.
As shown in the screenshot, when a schedule for motor operation is entered, the motor operates for approximately 5 seconds at the set time.
This product also includes a feature that displays the next motor operation time through the app.
However, there is an issue. The task of calculating the next motor operation time based on the entered schedule is handled by the firmware.
As a result, there is a delay in updating the next motor operation time after modifying the schedule, and if the device is disconnected, the next motor operation time isn’t updated at all.
I hope to modify this so that the app calculates the next motor operation time. If this is not feasible, I would at least like the server to handle this calculation.
I have three questions:
I recently noticed that something called the Rule Engine was added. Can the Rule Engine be used to implement the feature I want?
I am currently on the PRO plan. Can the Rule Engine be added as an add-on in this plan?
If it can be added as an add-on, I would also like to know the cost. If sharing the cost in the community is difficult, I would appreciate it if you could send the cost details via email.
That sounds like a coding issue. How are you handling this calculation?
Presumably the device controls the motor? If so, then if the device is offline the next schedule won’t execute anyway.
Wouldn’t users find it problematic if they believed that the motor would run again at x time when this is incorrect because the device is down?
There is no functionality to do server-side calculations.
I’ll let Blynk reply regarding the rule engine, but this is an Enterprise feature, so I’d expect that the answer will be that an Enterprise subscription is required to use this feature.
The schedule supports up to 6 entries and uses a linear search algorithm as follows:
If there is a schedule with the same weekday as today, it returns the one with the smallest time that is still later than the current time.
If no such schedule is found for today, it searches for the earliest schedule on the same weekday as tomorrow.
If that also fails, it repeats the process for the day after tomorrow, continuing up to 6 days ahead.
If still nothing is found, it returns the earliest schedule with the same weekday as today in the next week.
If none exist, it returns that there is no upcoming schedule.
This calculation takes approximately 10ms to execute.
You raise a valid point. However, in my product, only up to 6 schedules can be set, meaning the motor can only operate up to 6 times a day. This usually results in relatively large time intervals between operations. Therefore, if a user modifies the schedule when device is offline, there’s a high chance that the device will come back online before the next scheduled motor operation.
That’s why I’ve decided to handle the next motor operation time on the app side. While this means that if the device is offline, the app might show a time when the motor won’t actually operate, I think such cases will be rare. On the other hand, if a user updates the schedule and the next operation time doesn’t change in the app, they may think the app is malfunctioning—which could lead to more confusion or complaints.
Is that a typo?
Personally, I think I’d take a simpler approach.
Use a variable to hold the UNIX time when each of the 6 timers next upstate, and compare that to the current UNIX time. This gives you the time in seconds until the next timer and it’s a simple calculation to convert this to days/hours/minutes & seconds.
When the pump kicks-in you recalculate the timer.
If any of the 6 timers are edited it will trigger the corresponding BLYNK_WRITE(vPin) function, and you then recalculate that timer.
That’s a dangerous assumption to make, it depends why the device went offline. It might stay offline permanently until some user intervention takes place.
I’d prefer to know that the device is offline and we don’t know if the next timer will execute.
I appreciate your suggestion regarding the algorithm. Your approach definitely looks simpler and more straightforward. It helped clarify some things for me.
Also, thanks for pointing out the issue with assuming the device will come back online. I hadn’t really thought about it from that angle. After reading your comment, I realize it would be a good idea to include a widget to show the device’s connection status. That way, users won’t be misled about upcoming motor operations if the device is offline.
That said, I still feel that ideally, the next motor operation time should be calculated on the app or server side, if possible.
I’d expected you to reply saying it took 10 seconds.
If it’s taking such a short time to execute I don’t understand the context of this comment…
If a delay of 10us or even 10ms is unacceptable then I think you’re expectation of Blynknare too high, as there’s a maximum of 10 writes per second, or 100ms per write.
This still seems like a strange approach to me. You’d be providing conflicting info to the user - the device is offline, but the motor will run in x minutes. Personally I’d replace the x minutes with something like “???” using data invalidation rules when the device goes offline, to avoid any confusion.
I think I may have caused some confusion by not fully explaining the situation in detail.
The delay I was referring to isn’t about how long it takes to calculate the next motor operation time (which, as mentioned, only takes around 10μs), but rather the delay in data transmission.
When a user updates the schedule in the app, the data is sent through the app → cloud server → device firmware. The firmware receives the schedule, calculates the next motor operation time, then sends it back to the cloud server, which the app then reads and displays. This whole round trip takes about 1 second.
If the app were to calculate the next motor operation time itself, this delay wouldn’t exist, and the new time could be reflected immediately after the schedule is changed.
To clarify, the value I want to display in the app is not the remaining time until the next motor operation, but the exact time at which the next operation is scheduled.
Do you still think this would be confusing to users, even if the value shown is the scheduled time of the next operation rather than a countdown? I’d really appreciate your thoughts if you think that’s still a UX concern.
