[Support WITHDRAWN] GCal-Search: Google Calendar Event contact sensor/switch

You mean I need to remove the newlines in the text?

Ok, that’s kind of where I figured it was going. Thanks!

Correct…as long as it doesn’t go into a 3rd line the text seems to scale properly. Very weird.

Hello Mike,

Thank you for your answer. It’s not something I can solve with RM, it’s the refresh of the calendar event. The problem is coming from ST.

Edit : I checked the Events list, and most of the days, I don’t get open/close event.

I just pushed an update to change the scheduling to happen in the child app instead of the device. This appears to be more stable for me. Please let me know if this breaks anything for all of you. It’s not the cleanest code as I did this to test it so I’ll clean it up in a few days.

This also lets you see in the IDE when the scheduled events are going to happen and I assume with the new scheduler should fix any other schedule related issues. One can hope at least.

@bravenel put a TON of hard work into Rule Machine and the continued issues we’ve all had are beyond frustrating. I can’t get the scheduling working correctly here either so I’m following his example. Rule machine - as per the app developer, this app is no longer available for new installs, distribution, or support

You may continue to use GCal-Search if you installed it but I will not longer support it. Feel free to distribute the code if you feel the need to.


Ack…my favorite toy :wink:

Why is it that both applications I use and have contributed to are now withdrawn??? (rhetorical question).


Hey Mike,

I haven’t seen the problem with scheduling yet. Is the problem you are seeing with the scheduling and updating of the calendar search, or the individual open/close things?


All of it is unreliable for me. I’ve tried doing scheduling a few ways and thought I had it licked the final update but it failed after a few hours. So after seeing RM bailing out I’m giving up.

Are you talking about the poll (which, after about 6 hours for me stopped firing), or the actual schedule?

Also, would you be open to another project that is less about scheduling and more about API calls (I will PM with details if you are interested).

All of it. I’m not really interested in spending anymore time on ST. Actually looking to purchase a usb stick and running some other automation platform completely local and not rely on a company or their hosting.

Understood…while not the best place for it, please let folks know what success you have with a local platform…I think that a backup (local) is a great idea…

1 Like

My issues are even worse than just scheduling. My switches and stuff aren’t actually being told to change their state. It takes me a few tries with the App to get them to switch. Even my mini remote buttons are having this issue. It’s just gotten so completely unstable and the only reason I’m not pulling out my hair is that I shave it. :slight_smile:

From everything I have read, ST did identify the issue and they should be implementing a fix. I have my fingers crossed.

Thanks Mike,

I love this program you wrote. :wink: It really is quite amazing. I understand your disillusionment and frustration. It happens to all of us from time to time. You either tough it out, or you move on to the next adventure…both ways are perfectly fine. Sometimes its hard to let go and move on to the next adventure…but eventually i do.

I did change the copy of the program I run, to get rid of runIn() since the ST guys say over and over that chained runIn’s can fail and when the chain breaks, things stop polling. I switched in a cron schedule(,) (built-in 2-parameters) and didn’t touch the runIn logic, so it unschedules and re-schedules a cron job every poll. (probably not necessary to unschedule and schedule, but I wanted to keep changes really simple to make it easy for me to replace them when you upgrade your software)

The thing is, if a cron job fails to run, there are other mechanisms in it to get it to run, unlike runIn(), including just running it in the next time slot…so it can recover. I notice that you have a subroutine schedule(,,*) with 3 parameters defined in search trigger. I think groovy handles them as two separate procedures, but I changed the name of the 3 parameter subroutine definition and where it calls it for open and close in Event Sensor. Just so I could keep track of it. (I’m old.)

Here’s the main thing I changed.

def schedulePoll() {
try { unschedule(poll) } catch (e) { log.debug “unscheduled poll” }

log.debug "Setting poll for 5 minutes"
def sched = "0 0/5 * * * ? *"   // forget what the user asked for, check every five minutes for testing
schedule(sched, poll)
//def device = getDevice()
//def refreshTime = device.currentState("refreshTime").value.toInteger() * 60
//log.trace "Setting poll: ${refreshTime}"
//runIn(refreshTime, poll)


Awesome program Mike. Good luck what ever you decide.


I did change on my side to use runEvery15Minutes() and it lasted a bit longer. There were no more chains except for the runEvery… calling runOnce() to setup the open call and the open call settings up the close call.

1 Like

Do you feel that instead of giving the user the ability to change the polling time that a Cron or runevery… would be a better alternative and more reliable? I still have faith the ST will get their act together but also feel there are some workarounds that might get this to work better…

I am hoping for one more push of this app from you Mike :slight_smile:

1 Like

I still have my backup analog clock / magnet / door-sensor poller running … the only polls it’s ever missed have been when I took it apart to upgrade to a smaller magnet on the hand. :wink:

1 Like

Connect a Raspberry Pi and a bit of programming and we can use that as our timer :slight_smile:

1 Like