Previously, the light-meter was creating a new HTTP request to send every new reading. This now
uses a persistant session to reduce the amount of requests made to the server -- and reduce low
on the system.
The extra exceptions listed and expanded on are mostly for testing. At the time of writing, the
system as a whole is hanging at various parts throughout the day and the intention is to monitor
the Light Meter to see if any of the new exceptions are the cause (or contributing) to the
hanging. The current trains-of-thought at the minute are too many requests (system load too
high) and requests not timing out properly.
This file is used to start the program at startup. It, also, restarts the
program if it crashes or throws an exception. The usual scenario which
causes the program to crash is the 'max. requests exceeded' exception in
the 'requests' module (Python). When that happens, this 'restart' service
has a 60 seconds wait period -- which acts as a 'backoff' period.
You will need to copy the .service file to the appropriate systemd
location, 'daemon-reload' systemctl, enable the service and start the
service. You will need to look-up how to do that -- this info. is beyond
the scope of this commmit.
This is a minor change but I thought it was best to document it.
The factory typically shutdowns at 16:00 but for some reason I thought it was 18:00. Because of this, 'factory1' (the light-meter used for testing) was not shutting down properly. The factory's power was cut at the end of the day (again typically 16:00 but not always) and the Pi would have a dirty power-down. This, also, meant the server and its opposite relay [return-to-ritherdon/relay] would think it was still on but sending no new readings.
All of the above has no great effect of the **note** left in the README but I thought I should change it on the off-chance someone copies that line into a part of the system.
I have given the 'mid-point' server a domain name to reduce the need to manually update the IP address if/when the
server needs to be restarted (for whatever reason). The changes here include the new URL.
The base URL uses ritherdon.abbether.net now, in the main part of the
python code. I have added checks to see which device is running the
code and forms a complete URL for the API call.
The way the URL is formed for the API call is not the most elegant
solution but is was quick to write and the code has a limited
life-span. It will not require any further modification when it goes
live. So, the speed it took to write it was a good trade-off in my opinion.
The URL used here is a domain name and not just an IP address. This
should reduce the need to update the IP address in the code if the
server, currently hosted on AWS at time of writing, needs to be
restarted. The servers on AWS do not keep the same IP address if you
stop and start them.
The abbether.net domain is a personal one and used as a way to reduce
project costs. I did not use this domain when I first wrote the code
here because I did not own it. Long story short, the Covid-19 malarkey
meant the project was put on hold and I ended up owning abbether.net
during the first lock-down. The decision to use the domain is one of
convince my end. I did not want to keep updating the code manually if
the server on AWS was stopping and starting.
Craig Oates
rtrp@factory1
Return to Ritherdon Project