In message , R.Wieser
 writes

Thanks for the detailed reply.

>You need to re-think that:  If I may take the "minute tick" entries as
>correct than those "change of state entries" come a few minutes *too early*
>( "06:38:01" is 8 minutes *later* than the "0630" directly following it)
>
>And as that is not possible (it would involve time-travel) it makes me think
>that maybe the "change of state entries" are correct, and the "minute tick"
>entries too late.
>
>... Which might be caused by buffered (text)file writes.
>
>

I am able to tail -f the log file, so I can see that the minute ticks
are correct.

I know when the change of state takes place.  I know that in the case of
Thursday morning example (see original post), it was between 0629 and
0630 (I witnessed it, and my watch is only a few seconds out).  So the
log file ought to have a change of state recorded at 0630.

Unfortunately, what I'm not able to do is observe the log file (in real
time) at the time the state changes, I have to rely on what is written
to it as being accurate.

I suppose buffering could be possible, but I can't see how it can happen
in this case.  Each set of data is generated by a script triggered by
cron, so if one instance took 8 minutes to complete, then I would expect
that the following instances (taking seconds to complete) would add to
the log file (stdout redirecting, rather than an explicit file write
operation) as they are written, with the long running entry adding its
entry at the appropriate point in the log file.

>Also, what have you done in regard to finding more info about what happens ?
>Have eou already tried to enclose the "change of state entries" lines by a
>pair of  "date +%H%M" (maybe even "date +Start%H%M" and "date +End%H%M"
>lines ?
>

I've now altered the script to that it adds additional timestamps to
every run to show when the script starts, when the sensor check
completes, and when the script completes.  It will be interesting to see
what the logs show next time there is a state change.

>I could even imagine adding an incrementing number (taken from a single
>source/program!) to both the "minute tick" and "change of state entry"
>lines.      If those do not appear in sequence ...
>

That could be a next step.

Adrian
--
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.

--- SoupGate-Win32 v1.05