Has Anyone Looked At "Scheduled Jobs" In Logs?

🛎️ Get Help
1

I just started perusing Scheduled Jobs, and I have to say it begs a few questions from me.
Like, for one, what are all those doCheckIn's for the Zooz plugs? @jtp10181 ?

Then, there's stuff that seems to be hub centric, since there's no app or device driver link. Some of them are obvious, but others not so. Stuff like hourlyCleanupJob, ZWaveNodeStatisticsJob, sunJob, timeAdjustmentJob, appCleanupJob, ZipRssiGetJob, nightlyCleanupJob,sunriseEvent, sunsetEvent, cloudJob,

Then there is the "refresh" method used by some basic simple automation motion rules. What's with that?

Anyway, my main bit of wondering is whether there could be anything in these Scheduled Jobs log that could affect hub performance.

I could do some snip and pastes of the logs, if anyone wants.

Thanks.

2

That function in my driver is scheduled to run every 24 hours, is about 5 lines of code and probably runs in less that a second. If you must know what it does, it simply pings a gateway URL which gives me an idea of how many unique users are using it. All I get is the day over day count and model/code version that check in. It is actually very nice to be able to see, I can see that for the drivers that have that check in, the Plugs driver is by far the most popular with around 150 users (growing by the day). The ZEN04 is the most popular followed by the ZEN15.

2 Likes
3

The schedule per se isn't really how I'd approach this; it is, of course, the job that runs that really matters. Some of these may happen on a schedule, others may just happen in response to event subscriptions, manual actions, or anything else that can make app or driver code run. So, that's really the angle I'd look at. If there are problems there, they are likely to come up if you look at App Stats or Device Stats. Then, you could figure out where it's coming from and why.

So, unless you see anything odd here (like a scheduled job every few seconds, hundreds or thousands of scheduled jobs, or something else ridiculous), I'd basically look at things the other way around -- via the app or driver, if anything.

Or for the short answer: no, this alone is unlikely to be so. :smiley:

4

Thanks. I just never paid attention to it.

@jtp10181 , what does pinging a gateway URL mean? Does that mean it is pinging a URL on the internet? That's wouldn't really be local, would it? It kind of smacks of reporting to the mothership, kind of.

5

Nope not local, it goes to the internet, there are other drivers I have seen that do version checks to a private web server, also HPM for example hits multiple GitHub URLs every day. If GitHub had some sort of download tracking I could just use that. This scarf gateway basically just gives me download tracking that is lacking in GitHub.

The hub itself also connects to the cloud and checks in on a regular basis.

None of this prevents or inhibits local control of the devices.

If you want to disable it, there are two lines of code in the updateLastCheckIn() that could be commented out, like this below. Then after the next run it will not schedule any more.

void updateLastCheckIn() {
	def nowDate = new Date()
	state.lastCheckInDate = convertToLocalTimeString(nowDate)

	Long lastExecuted = state.lastCheckInTime ?: 0
	Long allowedMil = 24 * 60 * 60 * 1000   //24 Hours
	if (lastExecuted + allowedMil <= nowDate.time) {
		state.lastCheckInTime = nowDate.time
		//if (lastExecuted) runIn(4, doCheckIn)
		//scheduleCheckIn()
	}
}

Hmm... actually I think I have it scheduled as a reoccurring task, so you may need to also switch to the "Device" driver and then use the unschedule command to fully get rid of it. (Or use the delete button on the Schedule Jobs screen to remove them)

If its that big of a deal I could start adding an option to disable it on the settings.

2 Likes
6

Would the trash can in the right column of the scheduled jobs log only get rid of one scheduled job?

7

I didn’t realize that trash can was there. If you only did that the driver would eventually schedule it again. Would need to modify the code prevent it from coming back.

1 Like
8

I trashed them, but they did in fact come back.

9

As @jtp10181 explained earlier, all that does with respect to his drivers is give him a count as to the number of installations/users of his drivers.

He isn’t tracking anyone, and it isn’t preventing the driver/hub from controlling the device locally.

Community developers like him put a lot of effort and time into developing and maintaining custom/advanced drivers. Information, such as the number of users, provides the impetus to indicate that these efforts are worth the time commitment and investment.

Years ago, when I maintained my own versions of KA9Q NOS and FSUUCP, I did something similar - new installs would send me an email.

3 Likes
10

Understood. Still not crazy about it.
Wouldn't a one-time scheduled job do the trick, rather than recurring?

11

The solution is simple - comment out the lines indicated by @jtp10181, and use the Device driver to delete previously scheduled jobs.

1 Like
12

So, every time I install a new version of the driver I have to remember to do this stuff as well? A check box would be easier.

13

About the reoccurring scheduled task itself or about the driver hitting a web URL?

A one time task would just give me one point and only when a new device is installed or however it is triggered. I tried doing it with just the HPM download at first and I could see a big spike if a new version came out and then just random stuff here and there. Seemed to be consistent a couple hits every day which seemed odd. The daily check gives me a total number of people actively using it on a device. Also many people get my drivers directly from the Zooz site linked to the raw github URL, and never see it on the forums or use HPM. That was sort of why I added that community link at the top, to drive people to the forums a little.

Yes, but I am not updating them that often. I will consider adding an option to disable it.

I probably could use a shared variable so that if there are multiple devices of the same model only one would check in each day, but they would still all need the scheduled task. I purposefully made the check in as quick and simple as possible so it is not causing any issues. I had thought about having it grab a json file with version info and do a version check every day as well. Then people not using HPM would possibly see if there are updates. Decided against that, not really worth the effort and it puts more unnecessary work on the driver.

Here is what I get. Blue is total hits (total devices) and black is unique hits (unique users).

image
image752Ă—393 24.1 KB

And also a breakdown of device models, the numbers are aggregate for the time window selected so not really relevant but the height of each one compared to the others is telling.

image
image975Ă—427 2.11 KB

1 Like
14

What’s your concern about this scheduled job?

4 Likes
15

As background I have 17 ZEN04's and 5 ZEN15's using @jtp10181 's excellent driver.
It's so much better than the driver Hubitat provides.

I personally would like to have that option.

16

And all I ask for in return it to tally up how many people are using it. :wink:

I bet Hubitat has metrics on how many peoples hubs check in to the cloud server every day. Not really a direct option to turn that off either.

4 Likes
17

Yeah, if this is helpful info for Jeff, I consider it the very least I could do to help him out.

Almost all of my ZW devices are Zooz, and that's 100% because they work so well thanks to Jeff's awesome drivers.

Without his drivers, I know I would not be as invested in Zooz (and subsequently HE itself).

Jeff is a good steward of this info; why not just leave it and help him out? It costs you nothing.

5 Likes
18

I learned how to add an Emojii to the settings title just so I could mock this up.

How does this look?
image

Oh wait... I wonder if I could change it based on the setting....

4 Likes
19

So, this would have to be disabled for every device.

20

:rofl: :rofl: This is awesome, I may add this just because it is funny.

image

image

It could maybe be a global per-driver setting using a shared variable. Hmm.. but those are not persistent across code updates or reboots.

The best way to disable it per driver might be some sort of variable or flag at the top of the code that can be easily commented / uncommented. Then once that is done each device would see that and un-schedule the check in. It would have to be set again any time to the code was updated.

4 Likes