1
0
Fork 0
A Python based project for controlling a set of lights via relay switches -- based on the light meter readings made available via the "Midpoint" project.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
This repo is archived. You can view files and clone it, but cannot push or open issues/pull-requests.

73 lines
2.5 KiB

#!/usr/bin/python3
import RPi.GPIO as GPIO
import time
import requests
import platform
import datetime
relay_pin = 11
#GPIO.setmode(GPIO.BCM) # GPIO numbers instead of board numbers.
GPIO.setmode(GPIO.BOARD)
GPIO.setup(relay_pin, GPIO.OUT)
device_id = platform.node() # For servers logs.
def get_api_url():
# Yes, I know I could do this better. Stop moaning.
if (device_id == "gallery1"):
return "http://ritherdon.abbether.net/api/readings/latest/1"
elif (device_id == "gallery2"):
return "http://ritherdon.abbether.net/api/readings/latest/2"
# Make sure this is valid.
# api_url = "http://ritherdon.abbether.net/api/readings/add/1"
api_url = get_api_url() # Saves having to do the if-check every call.
def main():
try:
while True:
# Make sure the U.R.L. is valid.
s = requests.Session()
r = s.get(api_url, timeout=5)
# print(r.status_code) # For testing.
data = r.json()
# print(data) # For testing.
the_reading = data.get("reading")
# print(the_reading) # For testing.
if (device_id == "gallery1"):
if (the_reading > 38):
# print(f"[INFO: FACTORY1] Light is on -- {the_reading}.")
GPIO.output(relay_pin, GPIO.HIGH)
else:
# print(f"[INFO: FACTORY1] Light is off -- {the_reading}.")
GPIO.output(relay_pin, GPIO.LOW)
elif (device_id == "gallery2"):
if (the_reading > 48):
# print(f"[INFO: FACTORY2] Light is on -- {the_reading}.")
GPIO.output(relay_pin, GPIO.HIGH)
else:
# print(f"[INFO: FACTORY2] Light is off -- {the_reading}.")
GPIO.output(relay_pin, GPIO.LOW)
except KeyboardInterrupt:
remove 60 sec. delay at startup and add add new (cli) exception message. 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.
3 years ago
print("[INFO] KEYBOARD INTERRUPT: quitting program.")
except requests.exceptions.ConnectionError:
pause = 60
time.sleep(60)
print(f"[WARNING] MAX. REQUESTS EXCEEDED: Pausing requests for {pause} seconds...")
pass
except requests.exceptions.Timeout:
t_stamp = datetime.datetime.now()
print(f"[WARNING] TIMEOUT EXCEPTION: Request timed-out at {t_stamp}.")
time.sleep(60)
pass
remove 60 sec. delay at startup and add add new (cli) exception message. 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.
3 years ago
except Exception as e:
print(f"[ERROR] GENERAL EXCEPTION: {e}")
finally:
remove 60 sec. delay at startup and add add new (cli) exception message. 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.
3 years ago
print("[INFO] Terminating relay.py...")
print("[INFO] Cleaning up GPIO before closing...")
GPIO.cleanup()
if __name__ == "__main__" :
main()