Smarthome: [astro] Time drift on positional job

[mhilbush]

The sun elevation is supposed to be calculated at a regular frequency (default is every 300s). However, due to the use of scheduleWithFixedDelay for the positional job, which schedules the job starting from the termination of the previous job to the commencement of the next job, there is a small time drift introduced. This time drift can be anywhere from a few milliseconds to 35-40 milliseconds per execution, depending on the CPU speed.

Example of drift:

2018-04-30 17:36:52.955 [vent.ItemStateChangedEvent] - SunAzimuth changed from 262.15 to 263.18
2018-04-30 17:41:53.000 [vent.ItemStateChangedEvent] - SunAzimuth changed from 263.18 to 264.20
2018-04-30 17:46:53.042 [vent.ItemStateChangedEvent] - SunAzimuth changed from 264.20 to 265.21
2018-04-30 17:51:53.060 [vent.ItemStateChangedEvent] - SunAzimuth changed from 265.21 to 266.22
2018-04-30 17:56:53.093 [vent.ItemStateChangedEvent] - SunAzimuth changed from 266.22 to 267.21
2018-04-30 18:01:53.090 [vent.ItemStateChangedEvent] - SunAzimuth changed from 267.21 to 268.21
2018-04-30 18:06:53.113 [vent.ItemStateChangedEvent] - SunAzimuth changed from 268.21 to 269.19
2018-04-30 18:11:53.211 [vent.ItemStateChangedEvent] - SunAzimuth changed from 269.19 to 270.18
2018-04-30 18:16:53.241 [vent.ItemStateChangedEvent] - SunAzimuth changed from 270.18 to 271.15
2018-04-30 18:21:53.338 [vent.ItemStateChangedEvent] - SunAzimuth changed from 271.15 to 272.13
2018-04-30 18:26:53.378 [vent.ItemStateChangedEvent] - SunAzimuth changed from 272.13 to 273.10
2018-04-30 18:31:53.422 [vent.ItemStateChangedEvent] - SunAzimuth changed from 273.10 to 274.06
2018-04-30 18:36:53.458 [vent.ItemStateChangedEvent] - SunAzimuth changed from 274.06 to 275.03

This drift could be eliminated (or greatly reduced) by the use of scheduleAtFixedRate instead of scheduleWithFixedDelay.

The guidelines indicate scheduleWithFixedDelay is preferred. However, as the astro binding performs accurate calculations, it can be argued that the frequency with which those calculations are performed also should be accurate. Therefore a deviation from the guidelines is warranted.

Reference this forum discussion here

[sjsf]

Very good analysis! Indeed it would make sense using scheduleAtFixedRate(...) in this case.

Would you volunteer to do that change? When doing so it would probably make sense to leave a commend in the code which documents why that is, and also add a suppression to the static code analysis for this class in checkstyle for the AvoidScheduleAtFixedRateCheck.

[mhilbush]

Thanks for the feedback, @sjka. Yes, I can make the change. It will be my first ESH change... :-)

Do you know... Do I need to install the ESH IDE to make the change, or can I use the OH IDE that I already have installed? I already have a signed ECA.

[sjsf]

That's wonderful!

The formatter settings are the same, IIRC. There are simply more dependencies available in the OH2 IDE, but that shouldn't matter. Therefore: As long as it builds, I think you will be fine using the OH2 IDE.