m3h/loadshedding

Automatic hibernate during loadshedding

loadshedding's Issues

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.

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"

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

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.

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.

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 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)

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

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.

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.

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)

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.

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

Windows support

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

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.