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.
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.
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.
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.