I have a custom thermostat driver that (mostly) works with the thermostat scheduler but has an occasional hiccup. Consequently I want to understand how the scheduler marshals the commands it sends to the driver. In the driver logs it looks like the scheduler issues a command and then waits for the sendEvent update before issuing the next command to the driver. However my thermostat can take a long time to respond and it looks like the scheduler might timeout and kill the driver instance if it doesn't see the sendEvent within a certain time.
Does anyone know if I am correct in the above and, if so, how long does the scheduler wait for the sendEvent? What does it then do with the waiting driver command instance, does it just kill it?
I assume it would send whatever commands it can all at once. If there's a case where it needs the device to be in a certain state (and Thermostat Scheduler commanded something that should result in that state) before sending another command (also by Thermostat Scheduler), I could see it waiting for that event to happen (creating the desired state first) if the device is not already in that state, though I can't think of any examples off the top of my head where Thermostat Scheduler would need to do this--unless I'm not thinking of some specific scenario (but it seems like mostly just sets setpoints and possibly fan mode on your schedule).
This might be clearer if you give a specific example. Since it's your own driver, you can also write output to logs when certain commands are called in case that makes things clearer for you to see what's happening. The "Events" page for your device will also show you what app called what commands, besides actual events.
I'm also not sure what you mean with "kill" a driver. Outside of a parent/child app/driver relation, no app can "kill" another driver in the sense of stopping execution of a currently running method/command, canceling scheduled jobs, etc. An app can, of course, subscribe and unsubscribe to device events or schedule and un-schedule scheduled jobs at will (the "App Status" page shows you a glimpse into this, though it won't all be meaningful unless you wrote the app). But it's not clear to me what you mean is happening in your case.
@bertabcd1234 : Many thanks for the answer.
I have peppered my driver with log outputs and it does appear that the thermostat scheduler waits for one command to end before it issues another one - or the hub OS holds them. In any case I see the next command issued to my driver immediately after the previous one has ended.
The issue I see is occasionally the thermostat takes a long time to respond, up to 15 seconds before I time it out. However on a couple of occasions I have seen the logs just end. It is as if the driver code threw an exception but there was no exception the code just stopped mid-execution. I was wondering if the Thermostat Scheduler killed the process because it was taking too long.
Unfortunately it rarely happens so difficult it is to track down. I will dig some more, maybe deliberately delay the command execution to see what happens.
