C7 with some zigbee and C8 with some zigbee, Zwave and all rules. Problem started when zse41 malfunctioned, was connected to C8 as the C7 has no zwave devices. Replaced it with a zigbee contact sensor, put it on the C7. Used device swap. Hub mesh shares it to my C8. No problems with any functions in the rules or anything except it has a scheduled job that shows on the C8 and gives an error every day around 1PM. Looking at scheduled jobs on the logs page on the C8 I only see my Zwave devices that have them, no zigbee. Have swapped to the device driver and cleared every thing but it still does it.
Switch to the "Device" driver, run the "Delete Scheduled Jobs" command, then switch back to this one (it's probably where you're looking somewhere, too, but this would get it for sure).
This is leftover from a previous driver and causing the error, though the only consequence is the log entry, so if you have other problems still, they are unrelated.
Some recent 2.4.2 builds might delete these when you switch on their own, but I can't remember anymore what parts of that feature we or weren't kept in the current public release...
Are you sure the device ID matches? If you're looking at Past Logs in particular, you'll need to go by the ID (also works for live logs) and not the name. That is the device you should try looking at.
This is the hub-assigned device ID like you'll see in the URL, not the DNI or other device data.
ID's are matching. Also deleted scheduled jobs with device driver again. No luck yet. I will be replacing it with another zse41 when it arrives so should not have this problem then. I'm sure it's not a big deal but I have an OCD problem and don't know enough to fix it. Errors and Warnings drive me nuts.
Hey Robert, you probably know but if I create a virtual contact sensor and use swap app to replace my zigbee sensor with it the pending docheckin scheduled job is gone for the zigbee contact sensor. Didn't know if thats worth mentioning. Just looked and the virtual device now has it.
Yeah, I think that's a piece that has always come over with swaps (not clear that it should, but I suppose there could be cases where it's actually desired). Does deleting it still work?
Sorry this is my fault from my driver. My updated code base prevents this by making it a single run job that re-schedules itself so it would only error once then stop.
Are you sure you are tracking this back to the right device? Does not make any sense. You removed the device from the C8 and then put a new device on the C7 and shared it back to the C8 with Hub Mesh? How could a scheduled job have carried over from the original device to the new hub mesh device?
Unless you use Swap on the C8 and Swap Device will swap from real -> Mesh virtual? And also copies scheduled jobs? Why does it? And then since you cannot normally have scheduled jobs on the Mesh device, and cannot change the driver, it is now stuck there??? @gopher.ny
FOUND IT: Try this endpoint.
Replace XYZ with the device ID found in the URL of the device page (or in the heading of the pop over window). Also can be found to the left of the log entries.
http://HUB.IP/hub/advanced/deleteDeviceJobs/XYZ
Example of where to see the device ID http://HUB.IP/device/edit/XYZ
Original Idea for solution:
First, update to the latest 2.4.2 platform. There is some clean up logic that will wipe scheduled jobs when you switch drivers.
Then, create a new virtual device, swap from the hub mesh device with the stuck job to the virtual. Then either use the Logs to find and delete the job, or switch to the "Device" driver and run the command to delete the scheduled jobs.
