Calendar Event Query Block with End Offset

[Robo Bot]

Hello,

I try to let the Calendar Event Block proceed, "when transition" with negative End Offset (e.g. -2m), but it always proceed at start Event Time. Also tested positive End Offset. But it seems to be ignored completely. 

But the Start Offset Test was successful!

Time accuracy workaround is set to "Alarm clock", I tried "Alarm Clock & native timer", but then I got failure "Native timer workaround failed"

thx

[thomasn...@gmail.com]

The best way to do this is to first let the calendar delay until the start time (as it's already doing) and then use a "time await" block to delay until 2m before the event is over. You'll have to subtract 2m from the event end time and pass that to the time await block.

[Robo Bot]

Hi, thx for the advice. 
That's a good workaround. But this should the "End Offset" argument do also.

Could anybody test it for me? Just 2 Blocks (Calendar event query + e.g. Message or Toast) and an upcoming calendar event needed.

If it's wrong implemented I would tell it to the Llama. 😂

Thx

[Henrik "The Developer" Lindqvist]

I can't see any obvious bug, but the algorithm is quite elaborate. I'll add some debug logging.

It should be impossible for it to "ignore" the offsets, since they're always added to the events times when read from the Calendar database, so the bug must with the selection or alarm time code.

How may Event URIs does/should it match, maybe is fail to match some events, or maybe the bug occur when it match more than one?

[Robo Bot]

Hi,

Thanks for the quick reply. I would like to take this opportunity to tell you how great I think your app is. I was already a fan of your Llama app! I've had the premium version of the app for a long time and I'm hardly ever as happy with an app as I am with this one. 

Back to the topic:

"How may Event URIs does/should it match, maybe is fail to match some events, or maybe the bug occur when it match more than one?"

I have created an Automate "Event Offset" test calendar.There is only one upcoming event which I change accordingly.

The event data is entered via the Google Calendar App. 

Proceed: "When transition"

Input argument: "content://com.android.calendar/calendars/18" (selected from choice)

Min. timestamp: "not changed"

Max. timestamp: "not changed"

Start Offset: "not changed" (test was successful with behaviour as expected)

End offset: "-0h 2m" ("function=-120") (As I said, I also tested positive values.

The other input arguments were not changed.

I test by starting the flow. Then I create an appointment with 5 min. start in the future and 5 min. duration. It should proceed when end time + (-2 min.) end offset, right?

It proceeds at event start time.

I would be very happy if you could find the bug and fix it.

I have several application scenarios where I could use this feature. For example, if I have a train or bus journey event entered by the train app and want to be reminded to get off, etc., I can use this feature.

Thanks in advance

Translated with www.DeepL.com/Translator (free version)

[Robo Bot]

"I was already a fan of your Llama app!"

Sorry, It seems that the app Llama is from a different developer.

[Robo Bot]

Hello Henrik,

maybe I determined the bug.
What I didn't mention is that I set a short circuit at the "calendar event query block", at the "no path", back to the input of the "calendar event query block". I noticed in the log that a "calendar event query" appears at the start time of the event and then again at the expected "end offset" time.  After I noticed this, I retested the whole thing.
So, if a calendar event has already started and the "event query block" is waiting with "when transition", then indeed the "end offset" is triggered at the expected time, but via the "no path".
Finally, apart from passing through the "no path", I assume that if an "end offset" value is set, the "start offset" value is set to zero instead of ignoring it. Because the false triggering at the start time of the calender event passes through the "yes path", as when setting a "start offset" value. That makes sense to my guess. Would be a possibility.
Maybe I brought you a little closer to the solution.
For me, in any case, a simple workaround is possible, in which I put two "calendar event query blocks" one after the other. The first one passes the "yes path" at the start time of the calendar event, the second one passes the "no path" at the expected "end offset" time.

Thx

Translated with www.DeepL.com/Translator (free version)

[Henrik "The Developer" Lindqvist]

For every event the block should proceed at the start of it going thought the YES path, then again at the end going through the NO path.