Difference between revisions of "Python Scheduling Application"

From OpenCircuits
Jump to navigation Jump to search
Line 25: Line 25:
 
* Edit the parameter file ( parameters.py ) to activate and schedule your the activity.
 
* Edit the parameter file ( parameters.py ) to activate and schedule your the activity.
  
== Explaining an Example ==
+
== Explaining an Example Setup ==
  
Reading the section on architecture may help understand this section.
+
Reading the section on design as well may help understand this section.
  
 +
Each scheduling activity may have its own ( but sharable ) set of parameters for that activity.  These are stored in a dictionary, which is in turn stored in a master dictionary of all activity parameters.  It is set up in parameters.py and is called: AppGlobal.parameter_dicts.  When an event related function is called it is passed the name of the dictionary ( a string ) in AppGlobal.parameter_dicts and it gets out the correct dictionary it needs as in:
  
 +
  a_dict    = AppGlobal.parameter_dicts[ a_dict_name ]
  
 +
then individual elements are fetched as in:
 +
 +
  my_count  = a_dict["failed_connect_count"]
  
 
= Install =
 
= Install =

Revision as of 07:25, 22 March 2018

Introduction

Such an early draft not ready for reading!!

Note that this is an article started by Russ Hensel, see "http://www.opencircuits.com/index.php?title=Russ_hensel#About My Articles" About My Articles

The purpose of this program is to give an all python application for scheduling activities on all platforms: win, mac, linux, raspberry pi. I wrote it because I did not find a suitable program ( with good documentation ) after a not too exhaustive search. So here it is, let me know if useful.

Features

  • Python 3.6.
  • Extensible.
  • All Python, cross platform.
  • Some examples code/configurations in the download.
  • Parameter file allows some customization without programming.
  • Intended for Python programmers, not python naive uses ( sorry ).
  • Can email if special circumstances encountered.
  • Sleep tolerant ( but becomes inactive ).
  • GUI tracks recent events.
  • Maintains log file.
  • GUI runs in one thread, events ( now one at a time ) in another thread.

Use

There are 2 steps to creating a scheduling activity.

  • Create a new type of activity by programming ups it actions. This may not be necessary if an appropriate bit of code has already be written.
  • Edit the parameter file ( parameters.py ) to activate and schedule your the activity.

Explaining an Example Setup

Reading the section on design as well may help understand this section.

Each scheduling activity may have its own ( but sharable ) set of parameters for that activity. These are stored in a dictionary, which is in turn stored in a master dictionary of all activity parameters. It is set up in parameters.py and is called: AppGlobal.parameter_dicts. When an event related function is called it is passed the name of the dictionary ( a string ) in AppGlobal.parameter_dicts and it gets out the correct dictionary it needs as in:

 a_dict     = AppGlobal.parameter_dicts[ a_dict_name ]

then individual elements are fetched as in:

 my_count   = a_dict["failed_connect_count"]

Install

Get code from github, put where you put your python code, run. .... a bit more info later

Design

Some Big Ideas

The things that "happen" are events, they are set up in the parameter file in the method init_from_helper( ) using another method add_event_next_given_time() (more methods of this time may be added in the future if needed ). The components of an event are the following:

  • A name for the event, to help you track it.
  • A function that is run when the event is due.
  • A time to first run the event ( minute, hour, day )
  • A name ( string ) to be used to access supplementray data/parameters related to the event.
  • A time delta for the next occurence after the specified when the event will be run again.
  • A count for the number of times to run/rerun the event, -1 = "forever" .
  • A function that is run after the event is run that is intended to reschedule the event in some way.
  • Most of the design is similar to Python Smart Terminal Technical except for the plug in processing modules.

The GUI

The graphical user interface runs in a separate thread from the events ( on thread for the gui, one thread for all the events )

The purpose of the GUI is to:

  • Give notice of each event as it is run and typically notes any exceptional conditions. Since this could take an almost unlimited amount of memory old events may be truncated.
  • Allow the user to interact with the system. At a later time I will post a screenshot and describe the function of the different components.

Logging

Standard Python logging, see: Python Smart Terminal Technical

Parameters

Basically the same way as in the Smart Terminal, some more details will follow, see: Python Smart Terminal Technical