Q: What does this mean "Skip idle timer callback, too early"

I’m sure it’s not a problem, but as the title says: just wondering what it means exactly. :slight_smile:

I have plenty of those in the L1 log:
14:01:50:111 Set sensor check interval to 1000 milliseconds

14:02:06:311 Skip idle timer callback, too early: elapsed 522 msec

@de_employees

There is fonction in deconz that check periodically for “sanitary stuff”, for exemple to check if zombie device are back, checks if bind or report are working, ect … there so much action done in this fonction.

But if this fonction is trigger too fast for the same device, it’s ignored.

    // Use extra QElapsedTimer since QTimer seems sometimes to
    // fire in < 1 sec. intervals (after database write?).
    if (d->idleTimer.elapsed() < (IDLE_TIMER_INTERVAL - 50)) // -50 : don't be too strict
    {
        DBG_Printf(DBG_INFO, "Skip idle timer callback, too early: elapsed %lld msec\n", d->idleTimer.elapsed());
        return;
    }

On your log this need to be done every 1000ms, but the fonction is called after 522 ms, too fast, so the code skip the fonction for this time, will be done at least 478 ms later.

Thanks! Makes me wonder: is this info useful for log level “Info”, as is currently the case?

Logs are realy talkative, even just with “info”. I think realy few users pay as much attention to the logs than you ^^ (not a critic).
Logs are enabled on demand, so better to have too much informations than not enought, and yes the choice info/info_l2 is sometime not logic for me too.

I am now having issues again in the docker:

One difference I noticed is that on the Pi4 there is almost exclusively expected “ZCL attribute report…” while on the docker I saw a lot of “Skip idle timer callback, too early: elapsed 660 msec” (I see literally none of those on the Pi4)?

Could this be an indication of an issue with the maintenance taks scheduling or something on docker, or is this just a coincidence I hardly see these on the Pi4?

With the same network ?
I don’t see why you haven’t same logs ! I don’t think the OS or the hardware can have an impact on deconz performance …