Note: I've already solved this issue by removing this device from hub mesh, but I don't understand why it was doing what it was doing.
I had been using this device driver,
GitHub - ke7lvb/Solcast: Hubitat driver for Solcast Solar Estimate API to create a device that pulls solar production estimates from Solcast. When I upgraded to a C-8 Pro and moved web apps to my old C7, I moved the driver and created the device there. I have it set to pull the data once daily at 0400 local, which I configured in the device settings by selecting "daily" and customizing the time in the driver itself (on line 60). The driver schedules a refresh using a cron expression whenever "updated()" is called.
I have a flow in Node Red that listens to each hub's logsocket that writes the logs to InfluxDB. Yesterday I noticed that I was seeing two database updates for the solar forecast each day at different times (0200 and 0400) and I tried to track down the reason for that.
When I had moved the device to the C7, I used hub mesh to share it back to the C8 Pro since I had a rule there that referenced this device. That turned out to be the source of the second refresh event. The device on the C8 Pro showed a scheduled job exactly 2 hours earlier than the one on the C7.
That seems weird for two reasons. First, because I would expect that if the meshed/cloned device is just a copy of the original device, you would only want an original device to run its jobs and just let the cloned device update its values via hub mesh.
Second, why was it refreshing two hours earlier? Both hubs have the same zip code, lat/long, and time zone settings.
The C8 Pro didn't show the custom driver under "drivers code". It had previously been installed on this hub, but I had removed it. It's possible that when the driver existed on this hub, the refresh time could have been 0200, I can't remember - not that it should be using values from a deleted driver anyway.
I moved the rule that uses this device to the C7 and dropped the device from hub mesh, so it isn't causing me any problem now, but this seems like it shouldn't have happened. Is there something wrong with this custom device driver that caused this? Or will any driver with a scheduled job end up creating a scheduled job on the remote end of a hub mesh connection? And how to explain the 2 hour difference between the two hubs? Was it an artifact of the old driver that had previously been on that hub or ???
