Sorry, I meant the "handler method" and not the "callback method" (I was thinking of other cases where something similar is used), but in your case that would be the
refresh() method, the method name you pass to
schedule(). You can see that it is documented as a
String here: Common Methods Object - Hubitat Documentation
So, on line 153 in your code, what I meant was to try
"refresh" instead of
But again, I'm not sure that's really the problem -- just something I like to do since you know it's a String.
I second @ogiewon's suggestion. Looks like you're scheduling things to happen at second 0, every
AutoUpdateInterval minutes, starting at minute 0, and then your scheduled method itself is also un-doing and re-doing this schedule, so it will likely still be second 0 of that minute for several more executions. I'm also not sure exactly how the scheduler works, but it's possible it will fire if scheduled while that second is still the correct second (not necessarily only right at millisecond 0) -- meaning you'll get stuck in somewhat of a loop for a few executions (if this is correct; again, I'm not sure exactly how the scheduler handles this) when run as part of the schedule, but not when run manually since it (probably) wouldn't be at that exact time.
His idea to move your scheduling to
updated() would both (IMHO) make this a bit cleaner and also resolve this issue, if this is indeed it. If this is a driver, your "auto update" setting can't be changed without hitting "Save Preferences," which calls
updated() in your driver code, so there's no reason to check the value each time that code gets run--so it shouldn't matter either way.
PS - Conventionally, Groovy variables are camel cased, starting with a lower case letter, so
autoUpdateInterval would be a more conventional name. Also not the problem, but can't hurt.