I had a go at porting this over. I never used the original so I don't know what most of the other functions do, but I wanted to be able to read calendar events in Hubitat
It works for showing the next event (with optional filter) using the Contact/Event sensor type.
I didn't test any of the notification stuff (would prefer to do this via Rule Machine myself, unless there is some reason it's built into the app itself?), and didn't test the Presence sensor type either.
But it's a start - feel free to modify as necessary!
Note: The connecting to Google part is a little clunky, as you'll have to go out to a separate tab and enter a code, but you'll only have to do the linking once.
(Couldn't get the original web flow to work with Hubitat because both Google and Hubitat wanted to use the access_token parameter when returning the callback to the app).
If anyone downloaded this to try, I suggest updating all 4 (2x driver code, 2x app code) with the update I just posted, and then turn off the new toggle for Logging in the GCal Search app.
The original ST app has an extreme amount of logging... unnecessary if you're not experiencing an issue.
I just tested this as I am moving from ST to Hubitat. I detected 2 major issues which causes the GCal Search app to be impossible to use for now :
The Contact/Event sensor type finds the next event when created, but when a new event is added in Google Calendar, the sensor does not update rightly to the new event. Indeed, only the "eventTime" will update accordingly to the new event, but everything else stays locked to the previous event's values. Even when pushing "refresh" this does not correct itself.
The offset notify function is not working. I set some offsets in the app, but no offset works at the expected time, nor any of the offset values in the sensor are filled with good values (such as startMsg, or endMsgTime).
Do you think you could look into this ? I will keep my ST hub while this is not working, and will use IFTTT in order to transmit the values needed into Hubitat, but this is not optimal at all.
Hi @hgozilla, I just tested this and did not see the issue you described.
I had a GCal Event sensor that had picked up an event... I then added a new event before that one, and when the sensor next refreshed, all the values had updated correctly, not just the eventTime. Can you give me the exact steps on how to reproduce this?
I did note that I hadn't tested any of the notification parts of the original app. I use Hubitat's Rule Machine for notifications instead. Could you set a delay in RM to achieve the same thing...?
@cometfish thank you very much for porting over this solution from ST! I have enjoyed using it over the past many months since you posted the code. I have been able to automate my home based on school holidays, family member being sick, parent traveling, and guest staying.
I wanted to post my version in case anyone is interested. My use case is much simpler and I removed some of the complexity from the ST/ported version to address the following features and use case:
Simpler solution using a switch instead of presence and other sensor
Ability to set a default value of the switch that is used when there is no calendar entry and the switch will toggle from that value if there is a calendar match. This is useful if you prefer the switch to be of a certain value in dependent rules and apps or viewing on a dashboard.
Moved the processing of the search string match to the calendar title to HE. I had problems depending on Google's search to match the search string to the calendar title. Many times a wrong calendar entry was matched.
Ability to enter multiple search strings separated by commas for the same switch
By default the search string entered will be matched to the google calendar title using a starts with match - calendar enter starting with search string will match
A contains search can be entered by inserting an asterisk within the search string. For example to match both Kids No School and Kids Late School, simply enter Kids*School
Caching of the day's calendar entries for a set period of time. This is useful when you have many switches checking the calendar for entries that run near the same time. For example I have 5 different search trigger apps that I set to run at 1 AM so instead of querying the calendar 5 times, the first one will cache the results so the others can leverage the cache. Default cache is 5 minutes.
I ran into an issue that I don't know how to solve with Google when trying to set this up.
I don't have Gsuite, so I have to select "external use" app and verify my app with Google. I don't have a domain (that I know of) for the verification process, and Google claims it may take "weeks" to verify my app...
So I guess you need a business account to use this?
Sounds great! There was definitely a LOT of unnecessary complexity in the original ST app... and I'd noticed it loaded the calendar once for each switch instead of load once and cache - that was one of the items on my list to look at one day.
I'll take a look at your upgraded version
Very strange - I see in the docs that Internal says it's restricted to G Suite, but I definitely don't have one (used to have one but made a totally new account to get away from the G Suite restrictions on everything else!)
I found a discussion here, looks like you might just be able to use the credentials from an External app without submitting for review...?
I suspect it's something that has changed on Google's side recently - as the other post I found referencing that error message was also recent (Jan 2020), and was also a case of following a set of instructions that had previously worked for others.
Interesting I don’t have Gsuite either. I did setup an API to my contacts years ago and added my calendar to it when I set this up so maybe that’s why I didn’t have any issues. Very sorry to hear they have locked this down very unfortunate.
Nevermind...i got it....had to look in the logs. Not completely clear that that is where to get the code.
Since it hasn't been verified by google you just have to give consent and "proceed to unsafe" or whatever it's called in chrome.
I do have one question though...I set the offset time in the app to 45 minutes but I still see an "open time" of the start of the event. Is the offset not used? I can work it in if it hasn't been but I just wanted to check first.
This shouldn’t happen. Only calls the Google API based on what is defined in the child app. I’d be curious if you try my version and have the same experience. I do cache the calendar entries to help with performance.
Curious did you have any challenges getting the Google API setup like @sburke781?
Yes, several challenges. It wasn't until i realized that the "Device Code" was in the logs that I had to enter into the authorization screen that I was able to get it to work. I also had to click on "Proceed to unsafe" or whatever it is to get to the authorization screen because the app isn't published yet (Google Security). But once I got that done, it was able to get it authorized fine.
I was able to get an offset built into the driver which seems to be working well. Also, after un-installing and re-installing it seems to be running much better. I think I ran into a problem when I entered an offset into the app itself. The tip said to use a "-" sign to offset before the event start time but I think it treated that as a string instead of a negative number and that REALLY screwed the pooch.
So, everything is sorted out at this point. The one question I had was in regards to Ignoring all day events. Is there any way using the event filter to ignore all day events and only return ones with a start and end time? Thanks!!