Hubitat scheduler seems to stop working after a few days

🛎️ Get Help
1

I have a few devices with scheduled tasks. These scheduled tasks on each device use http request to fetch data for automation systems and update its state in hubitat.

I configured a few Basic rules (less then 10) to turn off light switches in 15 minutes. (one rule per switch)

I notice that after a few days the lights would remain turned on after the time configured in the rules had elapsed.

after some more investigation, I noticed that if I switched the lights without using hubitat (from the wall switch) the dashboard tiles would not catch-up to the actual state of the switches. However, if i then clicked the switch tiles in hubitat it would send the switch command to the automation system.

I enabled the debug logs on the hubitat driver (which write the log entries for all requests and responses). In normal operation, there should be a http request every 7 seconds per device, as per its configured schedules "0/7 * * ? * *" and soon after a response. These requests are the state update I reported above

The issue it that no such entries were logged .
this is how the scheduled task looks in normal operation:

image
image1178Ă—126 6.83 KB

this observation together with the Basic rules not working makes me believe that the scheduler functionality might have a glitch.... (I don't discard the idea that the driver might not be using it correctly)

btw, all requests and rules start working correctly again once I restart hubitat and remains working for a few days.

I am new to Hubitat, the drivers I have are custom and built by myself. I am a professional sw developer. I have been using hubitat for a little over a month.

2

You might need to provide a few more details about what the devices are and a little about how they operate. Are they smart switches, what protocol (Zigbee, Zwave, Lan - I'm assuming Lan if you are using a HTTP call)...

Also, just to confirm, the refreshStatus scheduled job, does that reappear automatically in the device edit page like you showed in the screenshot after a HE hub reboot, or is it missing until you interact with the device in some way?

3

Sorry, I do see you answered my last question in your post...

4

no problem, thank you @sburke781 for taking the time and reading my question.
I built this lan driver for hubitat to talk to my local custom home automation controller server. (which I know works, after years without a fault)

The scheduled task is set on device installation and remains there. I did not build code to remove the scheduler after installation. as far as i understood, the refreshStatus function does not get called by hubitat after a few days. (that's why I think there might be a glitch on the backend of the scheduler)

5

I know you confirmed the behaviour of the refreshStatus schedule reappearing after a reboot, but may be just worth confirming the method you use to set it up initially. The schedules may persist beyond a reboot, so I may be going down the wrong path....

Separate to that theory, perhaps include some additional logging around / inside the refreshStatus method to see if it is failing in some way, which may contribute to it dropping off... Not too confident with this, but worth a try...

6

to set it up it calls the following from the installed() method:

schedule("0/7 * * ? * *", "refreshStatus")

as a curiosity this is it:

def refreshStatus() {
    writeLog "refreshStatus called"
    if (reconnectIfDisconnected()) {
        return
    }

    asynchttpGet("refreshStatusResponse", [
        uri: "http://${ipAddress}/api/status",
        headers: [
            "Authorization": getDataValue("token")
        ],
        requestContentType: 'application/json'
    ])
}

and this writeLog only write logs if the input boolean debugMode is true :

def writeLog(logLine){
    if (!debugMode){
        return
    }

    log.debug logLine
}

after a few days, the message "refreshStatus called" stops appearing

7

Nice, some very similar approaches to some of the code I have written as well :slight_smile:

My only thought originally was whether the hub reboot cleared the schedule. There are methods that get called when the hub reboots, I believe initialize() is one. Perhaps you could add the schedule() call into that method, including a call to unschedule("refreshStatus") beforehand to clear any existing schedule?

8

when I reboot the hub, all works fine, for a few days...

I saw dman2306 has published a driver to provide the hub with a reboot function. I might just use it with a basic daily task to work around this issue.

2 Likes
9

At 9 times a minute (:00,:07,:14,:21,:28,:35,:42,:49,:56) it’s a wonder that the async call completes every time. Another consideration is that you lose a tiny bit of memory with each http call, so at some point you may be running too low on memory - are you tracking your free memory by chance?

2 Likes
10

The tracking combined with the restarts would be a good thing to try, maybe even hold off on the restarts while you assess the memory consumption....

11

are you saying hubitat is know to not be fast enough for a 7s polling interval? I would be quite disappointed if that is the case.
if the http request locks memory on every request this would be a know "memory leak", which for a device like this demands a reboot....

I might look for a resource monitoring driver/app as yourself and sburke have suggested to verify this is the case.

my local server (which is behind this endpoint hubtat is calling) replies with very low latency in less then 30ms (and averaging 10) every request it receives.

12

Hub can do every 7 seconds but if there is any latency in the return you may end up having multiple calls in process (shouldn’t be a problem with 10-30ms response though). There is a driver that returns that information and can be set up for periodic polling

but you can also roll your own using a call to

http://hubIpAddress:8080/hub/advanced/freeOSMemory

if you prefer.

3 Likes
13

Nice! you got me worried for a few minutes.

I used this advanced/freeOSMemory over the last 20 mins and it seems the amount of free memory is slowly decreasing... I might use your app together with the reboot driver to trigger a reboot when the free memory is less then a threshold (tba).

Thank you for the very helpful info!

1 Like
14

Operational threshold seems to be in the neighborhood of ~195K based on ancedotal evidence, but YMMV

1 Like
15

I would put any 'reset' code in updated(). installed() is only run on initial install of the device.

updated() runs anytime you hit save on the device.

I would add an unschedule() first in updated() if it is reseting your schedules/runIns.

16

I'm pretty sure that if you add capability Initialize, the initialize() method is called on hub startup. But, you'd still have the issues discussed above about what to actually do in that case.