On Sun, 9 Dec 2018 23:43:58 +0000, Adrian  declaimed
the following:


>
>The sensor in question (currently only one) is a Bluetooth low energy
>beacon.  The Python (using the Pi's onboard Bluetooth) is looking to see
>what (if any) beacons are active.  It doesn't look for specific beacons,
>so I would expect it to behave the same whether there are zero or a
>dozen visible.  It prints (to stdout) the details of any beacon it finds
>(which seems to be a combination of something looking like a MAC
>address, a HEX string and some numbers which I think refer to the signal
>strength), and it can see the same beacon several times during the scan,
>hence the sort -u above.  As you can see above, I've got a redirect from
>stdout to a file. Obviously, the more beacons present, the longer it
>will take to complete, and so far as I'm aware nothing else is using the
>onboard Bluetooth, so there shouldn't be contention.
>

 I would strongly recommend you study the documentation for the Python
logging module, and incorporate it into the Python script, along with the
parsing of the state information... The only thing the cron job should then
be responsible for is kicking off the Python script -- nothing else.

 Right now you have half a dozen places where data is appended to your
log, with a separate process invoked midway to scan, and another series of
operations doing a scan of scan results. Possible chase conditions -- IF
the Python script runs long, it is possible that, between the end of the
Python script and the start of your parsing loop, a second run could start
and overwrite the Python output file. At the least, replace /tmp/scan.txt
with a file name unique to the run (maybe obtain the process ID and add
that to the file name).

 Having the Python script collect the beacons into an internal structure
would allow one to avoid duplicates in the data, so no need for the sort
operation after-the-fact. How does the Python script determine it has
completed a scan for beacons? You state that it is possible for one beacon
to be seen multiple times, so is the search based on time?

 You might also have a chase conditions on your incrementer script along
with other temporary (or long term) files. All scratch files should have
names unique to the execution/run to avoid conflicts should the job be
started before a previous run has completed.

 Heck: I don't recall if this has been tried but... What happens if you
change the cron job to only run every 10 minutes? Do you ever see this
"mistime" happen then? Five minutes? Three?

 Maybe create a lock-file to indicate if a prior version of the script
is still running?


--
 Wulfraed                 Dennis Lee Bieber         AF6VN
 wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

--- SoupGate-Win32 v1.05