Is "unschedule" still expensive?

🚧 Developers
1

In the ST docs, they note (see:
Scheduling — SmartThings Developer Documentation):

You can remove scheduled executions using the unschedule() method. [ … ]

Note
Due to the way that the scheduling service is currently implemented, unschedule() is a fairly expensive operation, and may take many seconds to execute.

Does this still apply in Hubitat? I’m trying to port my last remaining lighting automation from Home Assistant/AppDaemon (Python) to Hubitat, and I can convert my logic more easily if I don’t need to feel bad about using unschedule() every time (for example) motion is detected again. The alternative is to do what I’ve done on ST and just use runIn() and write the handler so that it does the checking and uses runIn() to check again later if not, rather than being able to cancel these scheduled executions and assuming that it’s actually OK to proceed when the handler is called.

On a related note, the ST docs also don’t make it clear if it’s just unschedule() with no arguments that’s expensive or if it’s any call to unschedule() (since it also allows passing the name of a specific handler to cancel all scheduled executions for that particular handler—and if that’s the case, I guess I really didn’t need to avoid this on ST in the first place). In any case, I’m assuming the implementation in Hubitat is different, so I’m wondering if anyone can speak to how it works.

Thanks!

1 Like
2

There is no reason that unschedule() should be particularly “expensive”. It certainly should not take “many seconds” to execute.

One advantage of our local execution model is that you have a dedicated scheduler, not one shared by thousands… Makes things considerably more straight forward.

1 Like
3

That’s what I was hoping to hear! I’m also going to assume that I can ignore the part in ST’s docs where scheduling is only “guaranteed” to execute within the same minute as it is scheduled and not necessarily at the exact time (to whatever extent anything in ST is guaranteed to execute at all :slight_smile:) since the scheduler is both local and all mine.

Thanks!

4

You can schedule things to the second and expect them to happen then. It may be possible to load up a hub to the point where that might not always happen. But, for normal operations this is to be expected. We even added a method runInMillis() that allows things to be scheduled in milliseconds from now. These hubs are not CPU limited.

5 Likes
5

I didn’t expect these were CPU limited, but someone on the ST forum posted that they thought it was, because it was a streaming media box.

Out of curiosity, how high have you guys gotten these, cpu/ram usage wise, and what did it take to get them there?

I don’t have all 300+ devices (with VS’s) moved yet, but I have over half, and haven’t had any lag that I would attribute to the device itself.