Getting status of job for device?

Is there a way to get the job information of a command sent to a device? I want to be able to track the job of the command sent to the device to make sure it finished successfully.

I thought:


was the way to go but it does nothing when I issue a zwave command and use the job# as it always reports -1. I also tried getting the status of the device using:


but it includes more data than I want. Is there something that just provides the status of the job?

  • Garrett


There seem to be two ways to do it, depending on the type of device. I’ve seen exactly the same behavious that you have.

To summarize:

Z-Wave devices don’t seem to use the id=jobstatus call. I think you’re stuck with the id=status call, and fishing for the “Jobs” key. I’m pretty sure it’s what the JavaScript that drives UI4 does. If you use the DataVersion and LoadTime parameters you can get a more targetted list of what’s changed since your last query.

Other devices, such as those you’ve made a plugin for, don’t populate the id=status call. For those you have to use id=jobstatus.

I have no idea why this is so.


Thanks for the info. I guess I’ll have to use the status route. I hate to down load more data then needed! All I wanted is to be able to check the jobid to get the status code and make sure it succeeded. This would help me better judge on when to have my application do an update. e.g. locks have a tendency to have a mind of their own. Either they want to respond to the command and report back right away or they take 5-10+ seconds.

  • Garrett

Did you ever track down the meaning of those status codes in job results…?

From wiki:

job_None=-1, // no icon job_WaitingToStart=0, // gray icon job_InProgress=1, // blue icon job_Error=2, // red icon job_Aborted=3, // red icon job_Done=4, // green icon job_WaitingForCallback=5 // blue icon - Special case used in certain derived classes

If the status is 0, this means the job is queued but hasn’t started. If it’s 1 or 5 the job is being executed right now. Generally both 1 and 5 are presented to the user the same way as a ‘busy’, although technically 1 means Vera is actively talking to the device, and 5 means Vera is waiting for a reply from the device. Status codes 2, 3 and 4 mean the job has finished. 4 means the job went ok, and both 2 and 3 mean it failed. Technically 3 means the job was aborted by another job or an external process, like a user cancelling it, while 2 means it failed due to a problem talking to the device. In both cases this is usually presented the user the same way, as a failure.

  • Garrett

Garrattwp — The amount of data in the status message are quite small … trivial extra effort compared to actually making the http request to see if any data changed.