This is the issue. Basically you have it set to query for an event on the current day but remind you 24 hours in advance of that, which would be yesterday and unfortunately not possible . Set it to end of next day and this should fix the issue.
That is based upon your setting. You can see specifically by clicking the gear within the gcal trigger and scroll to the scheduled jobs to see.
This is exactly why @halfrican.ak requested "End of Next Day" to be added so queries are performed in advance. And also why I expanded that to include N number of hours too. Again setting this in your trigger should solve the issue. Please let me know.
There might be confusion about the offiset as that is speficially tied to the event start and end time that is gathered from the scheduled calendar query and nothing to do with the calendar query itself. It was added because @gertjan.deprez wanted a switch to turn on an hour before the event scheduled time for reminder.
Hmmm, the name of this option ("End Time Preference") was misleading for me (but now the description in fact makes this clear). How about "Search Range"?
But than... how do I toggle a switch e.g one week before? Is there a limit for the hours option?
BTW: I've tried "Number of Hours from Current Time" but I see no entry box?
BTW2: Would it be possible to enter the offsets in 3 boxes (days, hours, minutes)?
Edit:
Hmmm, maybe the Search Range could even be automatically calculated from the offsets?
I will consider making it clearer in the next release
I haven't tried a very large range of time but it should work. Basically there is code that adds the set amount of time to the current time in hours.
Hum you are right, just tried it and the box isn't showing. At last minute I did change the wording of the dropdown and missed updating line 87 of the GCal search trigger app. Should be:
I will fix that in the next release, sorry about that.
This is really not the intent of the offset. Again offset is if you want the switch toggled in advance or after the calendar start/end times. Nothing to do with the actual query of the calendar and its settings as these do need to be separate. Use case is that you want to be reminded of an event N number of hours in advance of the start time of the calendar event. Lets say you have a calender event to go to work at 8 AM and you want your bedroom lights to turn on at 6AM, you would enter an offset of -120 and the switch will turn on at 6 AM yet the eventStartTime value on the switch will still remain 8 AM.
Great, but it doesn't hurry.
And there is nothing to be sorry for! We are happy that you offer such a great tool!
I'm still missing something...
To use this feature as intended IMHO a certain minimum "pre search range" - sorry - is necessary, isn't it? To realize an offset of -120 (i.e 2 hours in advance) the query must be done at least 2 hours before the calendar event starts.
Correct but most folks thus far are setting up periodic scheduling and the default "End Time Preference" is the end of the current day so if a query is done say at midnight, an event at say 4 PM would be found, added to the switch, and the offset would kick in. It will be very hard to automate the "pre-search range" as you call it/the scheduling of this trigger based on the offset setting because HE has no awareness of the events on your calendar until it queries it. Establishing the appropriate schedule to query the calendar is important to capture what you need. The wording/description of this feature could probably be cleaner and I am definitely open to suggestions on making this as clear as possible.
Yes, that's of course true - and IMHO in fact the fundamental problem of a fixed Search Range. That's why the App could calc the necessary "pre delay" and do the query in time...
I have to admit that I don't know how much it costs to do such queries... Till now I haven't read the Google Calendar API - does one query return all the events of a given range?
As I'm already a bit biased it's hard to say...
Of course I could live with that!
Maybe you could add a Search Range of "One Week"? (This should handle 99%...)
Or is the performance hit to big?
BTW: I see in your example that you've not set the Event End Offset. Doesn't this mean, that in this case the switch is toggled for 48 hours (given that the calendar event is a whole day event)?
Correct. Start time is set to the current time of tap when the calendar query is about to happen and end time is set to the preference set in the app (current time plus that amount of time) and it will return all events within that range. There isn’t a huge cost with performance unless of course there are tons of events. But this said most people’s calendars are pretty “fluid” and appointments change all the time where some are added, others rescheduled, and some removed. This is why many have chosen to do a periodic query instead to pick up these changes as they happen and adjust the switch accordingly. Your example of Birthdays and mine for Mail holidays are different because those are fixed dates. Regardless this should accommodate both scenarios which it does in current form.
I could but I took the easy path of allowing a set number of hours instead. My concern adding a week is others will want 2 weeks, 3 weeks and so on when doing simple math of computing the hours is basically the same.
I would expect the End offset to hardly ever be used. I added it since it wasn’t much more effort when adding start offset. An example of when you would use this is if say you had a “Reading Time” calendar event for the kids where they must read and have no electronics. You could set notification rules to announce this via TTS speaker. A 10 minute start offset could be entered so the switch turns on 10 minutes early and the rule would fire announcing to the child that in 10 minutes you need finish up with your electronics and start reading. Then a 5 minute end off set could be entered so the switch turns off 5 minutes early and announces to the child you may stop reading in 5 minutes.
This offset feature seems to have caused confusion and definitely open to another way of describing this feature. I used those words to be consistent with other apps within HE where you can have switches turned on say 90 minutes before sunset via offset setting. This is honestly the same where switch toggle will behave based on these settings and again nothing to do with the actual calendar query.
Correct a scheduled job is added to toggle the switch at the calendar event end time regardless of offset. End time offset would adjust this if that is needed, which I don’t expect many to use.
My apologies for the confusion around the offset feature. Based on what you have said thus far I don’t think you need it. So please ignore it.
I will admit this is the first time that I had to change something major with the preferences and I hope that there are no errors. This release will require you to open search trigger child app and click done to set a state variable for the caching preferences.
I just went through the steps and activated the API etc, installed the app and configured it. I am seeing the following error in the log: app:6192021-06-08 05:26:16.241 pm errorjava.lang.NullPointerException: Cannot get property 'endTimePref' on null object on line 320 (getNextEvents) app:6192021-06-08 05:21:51.292 pm errorgetToken - something went wrong: groovyx.net.http.HttpResponseException: Forbidden, [error:slow_down, error_description:Forbidden] --- Loading Past Logs... ---
Any idea what I may have missed?
EDIT: I am seeing the info in the "Current States" though...
No worries - it's working perfectly after that initial hiccup. One request/ask - is there any reason you did not put in the option to "Enable description text logging"? I did not see it in the child app or the virtual device, just saw the option for "debug logging".
@rakeshg I believe I fixed the error you mentioned above in v2.2.2. HPM has been updated if you want to install it from there or you can do it manually as well.
Description text logging doesn't exist in apps only drivers. But this said this is a feature of the stock drivers and typically not custom drivers.
Thanks for the quick response. Will update tomorrow.. So far, it's been working great!
Ah - I guess I was just used to seeing log entries and it was mostly from drivers. I guess the only true "custom" app that I'm using is HPM and I've seen log entries so just thought that it was standard. Not a biggie at all - thanks again for a great solution. I was looking for something that would let me trigger automations based on Google calendar (I tried various solutions in Node-RED) but alll ran into some issue or the other. This is perfect for my use case!
One quick question - if I was to "manually" set the switch created by the app, would the app override it at some point?
Eg: the default of the switch is "off" and it is set to "on" by the calendar event start. If I forgot to create a calendar event and I manually turned the switch on, would the app restore it to the default "off" state if it did not see an event?
. Set it to end of next day and this should fix the issue.
- is necessary, isn't it? To realize an offset of -120 (i.e 2 hours in advance) the query must be done at least 2 hours before the calendar event starts.
