[RELEASE] Google Calendar, Task, and Gmail Search and Gmail Notification Device

How do I rename the device switch? I tried renaming it in the trigger/child, but it did not seem to change.

The app doesn’t update the name after creation. You can change name directly in the child device. Update the label attribute.

1 Like

Thank you so much for this app!

I have one question/request-- I have a scenario where I want to search for events frequently (say, once per hour) because an event may be added at the last minute, but I also want to include an event offset (+60 minutes). The issue I'm having is that if a poll happens after the calendar event is over, but before the +60 minute offset has expired, my switch gets turned off. I would expect it to stay on in this scenario-- essentially, I want the event offset to add +60 minutes to the end time, regardless of when the next poll event happens.

Is this the expected behavior?

Just thinking out loud here, hoping not to copy anything said earlier (but with 223 posts, I may have missed a bit), but I'd like to give my vote to a formal "app/driver adoption process" whereby excellent community-driven projects like this eventually make their way into native integrations.

Hear me through: I've watched innumerable codebases rise through the ranks from an avid DIY coder's basement, to a 0.1 release to his forum friends, then expanding via github and a flurry of 1.x fanfare, only to get mired in a 2.0.1 stasis when (a) the original author leaves, or (b) changes to hub firmware hinder progress, or (c) well-meaning users fork the app to add in features for themselves, etc.

I would just love to see Hubitat be among the first HA companies to take the App Marketplace concept seriously enough that good apps can, at some point, perhaps by vote of the community members, be taken aboard as an "official" plug-in. This could benefit the dev, sure, with a little pocket change. But it would also guarantee the far more important principle of sustainability while thwarting code rot long-term.

Let's face it: Things change. Platforms move from open RESTful API's to un/pw to OAuth to who-knows-what in the future, making upkeep a hassle. Whereas apps under the company umbrella stand a stronger chance of keeping with the times as consumers demand evolution. In turn, that evolution drives wider adoption by prospective Hubitat customers. Which allows the suits to monetize something that might have fallen fallow otherwise.

Thoughts?

P.S. In the meantime, I can't wait to try the GCS app. We had a similar 3rd party plug-in back on the Vera platform, and I dare say it worked like a charm, but never really reached a wide audience. Now, 10+ years later, the author (like so many former Vera users) has moved on.

1 Like

@andrewL To be honest the offset functionality was put in place based on a use case to have an advanced reminder of an upcoming event - for example trash reminder. While I was coding that use case I decided to add an end offset too but never considered your use case.

I took a look at the code and your use case and uploaded v2.5.0 to a Beta folder if you don't mind testing it before I release it via HPM and to everyone else. While adjusting this code I also realized I had never implemented the "Expand end date for sequential events?" feature when Google Matching was enabled so I also fixed that too.

Anyone else is welcome to test the Beta version too. You will need to manually update the GCal Search parent app and the GCal Search Trigger app. The child driver remains the same. v2.5.0 Beta code can be found here:

I am traveling this week so I won't be updating the main branch until next week when I return as I don't want to potentially cause anyone issues while I am away from my computer. Assuming beta testing is OK, I will update the main branch and remove the beta. Once I update the main branch, those of you that use HPM to install the app will be notified of a new v2.5.X version.

Thanks in advance to anyone willing to test!

3 Likes

@LibraSun thank you for the feedback. This app started on the SmartThings platform and was ported over to HE. I then expanded and refactored much of it since I use it quite extensively at my home and other HE Community users requested new features. It has been a fun project to work on and I am hoping others will contribute ideas and pull requests with new features.

I have been using HE since the very beginning, over 2.5 years, and some community driver functionality has made it into the stock firmware but not any apps that I am aware of. I would suggest creating a new topic in the Features Request category and voice this idea so that the HE Staff can comment as they will likely not see your post buried within this topic.

3 Likes

This has been discussed previously in the forum. While I understand your concerns about developers who move on and abandon their code, and I’ve been bit by that but am able to maintain and modify for my own use such code, some of the more talented developers here have indicated that they do not want their code merged into the official distribution, and I can understand that reasoning, too.

There’s also a third consideration. I certainly can’t and don’t speak for Hubitat, but, if I were Hubitat, I would be extremely hesitant to absorb outside code that might embody trade secrets of another entity or that might have copyright issues, thereby exposing Hubitat to vexatious litigation. Better to write new code to a design spec in a clean room environment by an uninfected programmer who hasn’t viewed the original code so that copyright issues can’t arise, because no copying would occur. Copyright does not protect ideas, only the tangible expression.

But, your post above, and mine here, are a hijacking of this thread, better taken to a separate thread if responses occur.

3 Likes

All true, and done! Thx guys.

1 Like

Seems to work perfectly so far! I'll let you know if I run into any issues. Thanks for such a quick update!

3 Likes

v2.5.1 has been uploaded to Github that includes:

  • New Feature: If Event End Offset is entered, this amount of time will be included when querying for new calendar events. For example if you entered an offset of 30 minutes so the switch stays on 30 additional minutes, during a calendar search an additional -30 minutes is added to the query so that any events that just ended 30 minutes ago are still included so the switch will not turn off. This is useful for frequent periodic queries.
  • Bug Fix: The "Expand end date for sequential events" included in v2.X only worked for HE based event matching. Corrected the code to also work when Google Query Matching is enabled.

For those of you using HPM, you will be prompted for the update.

3 Likes

I'm having trouble getting my search to trigger. I often work night shifts 6:30 PM to 6:30 AM. I want to query at 6 AM so that I can check the temperature outside and start my truck if needed. My calendar entry is as below...
Night Shift
Can I search the previous day? I would probably trigger on "PHY 6:30 PM" but how do I make this search trigger?

Unfortunately no. When the app wakes up to search the calendar is searches for events from the current time to the end span specified. You can set it to search as often as you want and if a match is found in the future scheduled jobs are set to toggle the switch based on the calendar start and end times within Google Calendar.

What I don’t understand is your calendar entry screenshot. Is the an event in Google Calendar with defined start of 630 PM and end time of 630 AM? Or is that an all day event?

I'm not exactly sure either. It is a calendar entry that starts at 6:30 PM and ends at 6:30 AM the following morning, spanning midnight of course. So technically, I should be able to start my search at 6 AM in the morning (near the end of my night shift) and still be able to trigger on that event. Correct?

Would you mind explaining the use case a bit more? So far I understand you work until 630 AM on some mornings and you want to check 30 minutes before at 6 to know whether to turn on your truck.

By default this app will toggle a switch (turn on or off based on your preference) the entire span of a calendar entry. So the switch could be in the On state from 630 PM to 630 AM and then Off the rest of the day. Then your other automation could check to see if the GCal Switch is On at 6AM and do whatever. Or you could set an end offset of -30 to turn off the switch 30 minutes early which could then trigger a rule too that checks the weather. Many options. But the main thing is that this app can query this Google Calendar and that the entry has defined start and end time stamps vs being an all day event.

Good info and suggestions. Let me play with it. Thanks.

Michael - not sure why one of my calendar setups did not work. I had 2 "Holiday" events set up (one for Thanksgiving Day and one for the day after Thanksgiving). The Thanksgiving day entry worked but the one for the next day did nothing.

Here are some screenshots of the setup and the event log:

Setup 1:


Setup 2:

Setup 3:

App Setup:

Event Log:


Google Calendar:
Screen Shot 2021-11-26 at 7.18.16 AM

Any idea what could have happened?

1 Like

It’s because you have it query at 11:55 PM. When it ran it still found Thanksgiving Day since there was 5 minutes left of its event and then the scheduled job turned it off at 11:59:59. I have my daily searches run after midnight to prevent this. Mine run at 12:30, 12:31, etc. but anything after midnight should work since the all day events end at 11:59:59.

2 Likes

Hmmm - should it not have found the event for the next day? My search covers that...

@rakeshg When I re-read your post with screenshots I thought that the sequential events setting should have covered this use case. I did a little debugging by setting up my test calendar with your two All Day holidays. Unfortunately sequential events won't work with All Day Events because:
item.eventEndTime(Sat Nov 27 23:59:59 EST 2021) >= newItem.eventStartTime(Sat Nov 27 00:00:00 EST 2021)

Notice they are a second apart. But I can see how this would be useful so I did upload a new version to address this by checking for all day events and if both are, I add a second to the time to see if they match.

v2.5.2 has been uploaded to Github and HPM has been updated.

1 Like

Thanks - will update. I saw today that it found the holiday (Day after Thanksgiving) when it ran at 11:55 PM on November 26. It flipped the switch and then turned it off again at 11:59 PM.

I guess the other workaround would have been to schedule it to run more frequently! Many thanks for the quick response and fix :pray:t3:

2 Likes