If you have the means, you can use these .stl files to 3D print an
enclosure for the Raspberry Pi and the circuitry connected to
it. These models where used for the exhibition.
I, commented out print statements and changed formating out print strings -- they were used for
testing.
Having ran the relays for a sustained period of time. It became apparent, the threshold for the light
levels in gallery1 was too low. What ended up happening was the light would remain on for long periods
of time through out the day but the light levels (Light Wave and Eyes and Ears) would show no welding
was occuring. What made this a little tricky to pick it apart, though, was some days the light levels
would rest at 38 and others at 39. Because it fluctuates, I couldn't tell if gallery1 would miss some
'welding triggers'. I decided to increase it to 39 in the end because the charts produced by Light Wave
suggests the change in light brought on by the welding increases the light levels by at least 2 -- most
of the time. So, by increasing the threshold to 39, the light levels must pass it which means the light
level must now hit 40+ effectively (not worrying about decimal values). This is still reachable on days
when the natural light level is at 38. The tradeoff is the system might miss the very short welding
bursts but the charts produced by Light Wave suggests they are too rare to interfere with the intended
effect/outcome of the system in a significant way. I say all this but I wouldn't be surprised if I
backtrack on everything I said here in a future commit.
With both Light-Meters installed in Ritheron, it is now apparent, each
booth has different levels on light in them. This means each Relay (linked
to its factory counterpart) needs to adjust to match. The branching logic
is implemented in a sloppy way here so it will need to be refactored at
some point but this is just a quick change to test the code.
At the time of writing, I would find the relay.service wouldn't crash so it
couldn't be restarted. Instead, it would hang and I think it's to do with
the HTTP request not timing out properly. I can't confirm this yet so I've
added in an exception case to help with monitoring the issue.
This is a 'work-in-progress' commit.
This is so the program can run unattended. It is a move away from the
'@reboot' cronjob used previously. Note this will need to be copied into
the appropriate loction of the system if you have just cloned the
repository. Search for Systemd docuementation on the interwebs or in the
repositories README (hopefully it's been added after this commmit).
The removal of the delay is in preparation of moving the program to a
Systemd service -- instead of a '@reboot' cronjob. By doing that, the need
to wait for the network stack on the Raspberry Pi to start is a built-in
feature.
The change to Systemd is becuase the program would terminate when it hits
the 'max. requests exceeded' exception in the 'requests' module (Python).
Having spoke to Nic (lead artist), she has stated she has a preference for
the program to be requesting the latest light readings or nothing at all.
The 'backoff' features which come with the 'requests' module will stop the
program from crashing but at the possibility of the having the Relays be
out-of-sync -- whilst still looking like it's working -- with the latest
light readings produced by the Light Meters in the factory and what's been
delivered to the server (Midpoint).
To be fair, this problem only arose when I ran the two gallery Relays, one
Light Meter and one instance of Eyes and Ears from the same location (my
flat). This wouldn't be the case in the when the exhibiton is live. Either
way, Systemd it is.
The natural process of waiting for the program to restart (with added delay
in Systemd service file if wanted) naturally allows the system to 'backoff'
but it keeps the all-or-nothing aspect Nic prefers.
The exception message is a minor change. It's there just to make it easier
to determine if the program is terminating because of the 'max. requests
exceeded' exception. I added it to the generic exception for ease more than
anything else. I can catch other exceptions whilst expecting the 'max.
requests' one. This is not the best approach to programming but the
trade-off between project goals and budget make me think this is ok (for
now). It is what it is.
The light meter readings changed when new a Light Meter (factory2) was installed (new components). The change produces different light levels (don't know why but probably different components). This change accounts for the new levels and the light which is controlled by this code now turns on when it receives a reading greater than 48. This seems to be the baseline light level in the welding booth (in Ritherdon, the factory) -- after monitoring the readings for a period of time.
The URL before was for adding a light reading -- not getting a reading. This URL change fixes that. This is what happens when you copy-and-paste code from the Light Meter project into this one.
The module is used to help determine which device is running the program. The device name allows the rest of the system to know what this device needs when I makes it RESTAPI calls.
The device/host names for the devices running this program should be using 'galleryX' ('X' denotes the device number). I put 'factory' instead of gallery because I'm an idiot. 'factory' are the device names for the Light Meter project.
This adds a check to determine which relay the system is (hostname/device name). When name is determined,the URL the program will use for the RESTAPI call is then set. At the time of writing, the system is expecting two relays. Hence the if-else statement. If more devices are to be added, this approach will need to be reconsidered.
The API calls now go to rither.abbether.net instead of the designated IP
address assigned the server (AWS). This change makes it easier to access the
RestAPI (see midpoint repo.) server. The URL will remain constant and if the
server needs to be powered-down/restarted for anything, the new IP address
Amazon (web services) assigns to it will no longer matter. And, the code used
to make the RestAPI call will no longer need changing manually.
Craig Oates
gallery1
gallery2
Return to Ritherdon Project