m3h/loadshedding

Automatic hibernate during loadshedding

loadshedding

Automatic hibernate during loadshedding

Virtual Environment

loadshedding has been tested using a virtual environment. The instructions below show how to setup such an environment.

Create the Python3 virtual environment using

python3 -m venv .env

and activate

source .env/bin/activate

Upgrade pip and install some dependencies

pip  install --upgrade pip wheel setuptools

Install wheel before installing the dependencies in requirements.txt prevents some non-fatal errors when installing the dependences in requirements.txt.

Install the remaining dependencies from the requirements.txt

pip install -r requirements.txt

loadshedding's Issues

Move configuration out of `loadshedding.py`

Currently the user configuration is inside the primary code file, loadshedding.py. This hinders collaboration on the code between developers in different regions.

This feature should move all user configuration out of the primary code files, either in some standard format like JSON or YAML files, or simply in Python configuration files.

The code snippets below show some of the parameters that will be moved to user configuration files:

AREA='8B'
MIN_OFFSET = 4 # minutes
MAX_OFFSET = 17 # minutes

NOTIFICATION_TIMEOUT = 120
CMD = "sudo /usr/sbin/s2disk"

and

SCHEDULE_CSV = '/home/reece/scripts/loadshedding/load_shedding_cp.csv'

The snippets below can potentially be moved to application configuration files:

API_URL = "http://loadshedding.eskom.co.za/LoadShedding/GetStatus"

and

LOGSTAGE = "/home/reece/scripts/loadshedding/stagelog.txt"
LOG = "/home/reece/scripts/loadshedding/log.log"

Add testing framework

Add a testing framework for the core logic:

• Based on the current loadshedding stage and the provided schedule, will it loadshed soon

This framework should also specifically check for the more difficult cases, e.g. behaviour around midnight, end of month.

For each schedule, we can provide the framework with tuples of (query_time, loadshedding_stage, expected output)

Add requirements.txt

Add a requirements.txt for easy setup of virtual environment etc.

Most of the dependencies are included with Python, but at the very least we require

pandas

These seem related to the notification functionality, might be moved to a separate requirements.txt (see #4)

from gi.repository import Gtk
import notify2

Flag to disable gtk notification

Add a flag to disable the gtk notification and control

This will help in two respects:

• We can disable this on headless systems where this functionality is not required
• I have some difficulty importing the gi dependency in virtual environments. This will enable development of the core functionality in virtual environments while this issue is address (also see #3 )

Add other areas (CPT, Tshwane)

Only "City Power" is currently included. Other areas, along with a readme.md describing the porting procedure and any relevant scripts used for porting to this repo's format, would be great.

integrate EskomSePush API

EskomSePush now have a free (for Personal use) API: https://documenter.getpostman.com/view/1296288/UzQuNk3E#325b0a97-08e5-405b-801a-42e7a79d5ba7

Could be very nice to use it to get

• Stage information for a location
• Loadshedding change times

The API is free to use for 50 API calls a day, so might have to change the current approach of spam-calling the official Eskom endpoint.

Loadshedding check may fail during the early morning (just after midnight)

Between 00:00 and 00:27 the loadshedding check may fail.

if it is currently loadshedding, per the previous day's schedule that runs from 22:00 to 00:30 the next day, the current logic does not infer that it is indeed still loadshedding.

After 00:27 the status is correctly set to False since is not run due to the behavior with the MIN_OFFSET parameter.

An upcoming commit, to address #7, includes a test case under test_loadshedding.py.TestCheckShedding.test_early_morning_yesterday

retry on invalid API return value

Currently, the script will retry hitting the eskom stage API multiple times, if an exception is encountered during the request.

Often, the API returns a negative value - which I think is possibly supposed to represent a 5xx error?
In any case, by hitting the API multiple times until we get a positive value, we should be able to increase the reliability of the script (when using the Eskom API).

I was having issues where sometimes the API would be unreliable, and the script would poll the API 20 times for a valid response. At a 1 minute polling interval, this lead to power loss before the script could fetch the stage successfully.

Support Cape Town lower stage

Commonly the areas under the City of Cape Town operates one stage lower than the rest of the country, especially before 19:00. We either need an additional check for this situation, or if not possible, allow the user to specify this behavior based on a few simple rules, e.g.: if (current_time after 07:00) and (current_time before 19:00) then true_stage = stage - 1

Windows support

I'm not sure if this works on Windows at all.
But that needs to be tested, and changes made if necessary.

script fails if tkinter not installed

This is problematic, as part of the target market of this script is for people running headless, server-like machines (that won't necessarily even have a GUI interface, or useless packages installed)

Hard to cancel when there is no loadshedding

If there is power to the PC, but the schedule and loadshedding status indicates that there shouldn't be, your PC will powerdown/hibernate as soon as you switch it on.

A temporary fix is to disable the internet (and therefore the checking of the loadshedding status) before starting up the PC.

Use timezone aware dates

The checks for loadshedding are invalid if the host systems time are not set to SAST (UTC+2), which may happen on embedded linux systems with pre-configured images.

In recent versions of Python the datetime module supports the timezone aware dates, so without adding additional dependencies, I propose:

• Read the system time along with the timezone data
• Read the loadshedding schedules with timezone data and assume SAST if unspecified.

Such timezones can be compared and the script should function correctly even if the timezones are not the same.

The primary fix should be the user setting the correct timezone for the system, but this may only be realized after data loss or other preventable consequences. We may emit a warning if the system timezone is not SAST.

Remove GTK dependencies

Related to #4

Currently, there are some GTK dependencies in the main loadshedding.py script.

loadshedding/loadshedding.py

Lines 192 to 195 in 7dd5761

	from gi.repository import Gtk
	import notify2
	main()

Now it's been a while since I took a look at this code, but if I recall correctly, the GTK dependency existed purely to be able to cancel the notifications, and cancel the shutdown/script execution.

I just had a look, and the notify2 package is deprecated (https://web.archive.org/web/20210714093727/https://notify2.readthedocs.io/en/latest/), so that dependency also needs to be removed.

But I really liked the ability to cancel the action as a user on GUI systems, so I want to keep it in.

Remove pandas dependency

The pandas dependency is very heavyweight, in my venv it pull 3001 files, and the associated numpy dependency uses 1288 files.

It seems like it can easily be removed, it is only used to read the schedule and for some simple lookups.

switch from YAML to TOML

With the release of Python 3.11 (https://www.python.org/downloads/release/python-3110/), TOML is now in the standard library of Python.

By switching from YAML to TOML config files, we can reduce the requirements.txt to be empty, and only rely on the Python 3.11 std lib