Editing SmartPlug Technical

Jump to navigation Jump to search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Latest revision Your text
Line 7: Line 7:
 
Before modifying the code it is best to understand how it works. Here is an overview of the general plan, details can be filled out by reading the code.
 
Before modifying the code it is best to understand how it works. Here is an overview of the general plan, details can be filled out by reading the code.
  
The "Application" is really two different applications, each with its own main program and GUI, but sharing a lot of the other code.  At one point I though I might merge them into one application, but 2 apps seems better.
+
Currently the "Application" is really two different applications, each with its own main program and gui, but sharing a lot of the other code.  I may merge them latter into one application.
The two applications are: SmartPlugGraph ( in smart_plug_graph.py ) and SmartPlug ( in smart_plug.py ).  The apps are very similar so I will explain them in a combined document: generally what is said about SmartPlug also applies to SmartPlugGraph ( the significant difference is that SmartPlugGraph is single threaded, so ignore content, for it, that refers to multi threaded..
+
The two applications are: SmartPlugGraph ( in smart_plug_graph.py ) and SmartPlug ( in smart_plug.py ).  The apps are very similar so I will explain them in a combined document: generally what is said about SmartPlug also applies to SmartPlugGraph.
  
  
 
The overall architecture is called the model view controller or MVC. The class SmartPlug can be viewed as the main class.  To run the program run its file smart_plug.py ( see code at end of file).  SmartPlug  is the controller in MVC it is responsible for all overall control, it directly or indirectly creates all other program objects.
 
The overall architecture is called the model view controller or MVC. The class SmartPlug can be viewed as the main class.  To run the program run its file smart_plug.py ( see code at end of file).  SmartPlug  is the controller in MVC it is responsible for all overall control, it directly or indirectly creates all other program objects.
  
The view component is called GUI ( in gui.py and for SmartPlugGraph is called also GUI but is in GUI_for_graph.py ). It creates all the visible components, and relays user input to the controller.
+
The view component is called GUI ( in gui.py and for SmartPlugGraph is called also GUI but is in gui_for_graph.py ). It creates all the visible components, and relays user input to the controller.
 
You can unplug the GUI object from the application and plug in new components. Don't like the GUI? You could modify mine, or you could make a modification and choose which one to use. This is sort of like a skin for an application.  
 
You can unplug the GUI object from the application and plug in new components. Don't like the GUI? You could modify mine, or you could make a modification and choose which one to use. This is sort of like a skin for an application.  
  
 
Two other important components are called Logger ( in logger.py ) and Parameters ( in parameters.py ). The controller creates one of each, and make them available to the other components. The other components can interact with them, and uses them respectively for logging events, and getting access to parameters ( those aspects of the application that are particularly easy to change ).  I describe more of this in [[My Python Coding Conventions]]
 
Two other important components are called Logger ( in logger.py ) and Parameters ( in parameters.py ). The controller creates one of each, and make them available to the other components. The other components can interact with them, and uses them respectively for logging events, and getting access to parameters ( those aspects of the application that are particularly easy to change ).  I describe more of this in [[My Python Coding Conventions]]
  
The application has a main thread running in a Tkinter mainloop.  There is also a second thread called a "helper" running which makes some processing much easier.  To make GUI mainloop responsive to both the GUI and its own processing it uses a pseudo event loop or a polling subroutine that is implemented in xxxxx. The frequency which polling occurs is set in parameters, the relatively low rate of 100 ms between calls ( .1 sec ) seems to give a perfectly responsive application in most cases.  I have run it as fast as once every 10 ms.  Have not tried to find a limit.
+
The application has a main thread running in a Tkinter mainloop.  There is also a second thread called a "helper" running which makes some processing much easier.  To make gui mainloop responsive to both the GUI and its own processing it uses a pseudo event loop or a polling subroutine that is implemented in xxxxx. The frequency which polling occurs is set in parameters, the relatively low rate of 100 ms between calls ( .1 sec ) seems to give a perfectly responsive application in most cases.  I have run it as fast as once every 10 ms.  Have not tried to find a limit.
 +
 
  
 
== Development Environment ==
 
== Development Environment ==
Line 25: Line 26:
 
*Anaconda Spyder 3.x
 
*Anaconda Spyder 3.x
 
*Python 3.7
 
*Python 3.7
 +
  
 
== Runtime Environments ==
 
== Runtime Environments ==
Line 38: Line 40:
  
 
* Tkinter for the GUI
 
* Tkinter for the GUI
 +
* pySerial for serial communications
 
* pyLogging for logging
 
* pyLogging for logging
 
* SmartTerminal a model-view-controller controller with some modifications  ( '''[https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model–view–controller - Wikipedia ]'''  or perhaps closer to '''[https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter Model–view–presenter - Wikipedia ]''' )
 
* SmartTerminal a model-view-controller controller with some modifications  ( '''[https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Model–view–controller - Wikipedia ]'''  or perhaps closer to '''[https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter Model–view–presenter - Wikipedia ]''' )
 
* Second thread for processing without being blocked by/blocking the GUI
 
* Second thread for processing without being blocked by/blocking the GUI
 
* Global Singleton for app cohesion.  
 
* Global Singleton for app cohesion.  
* Parameter file for easy customization.
 
* Mathplotlib for graphing.
 
* SQLLite for the database.
 
  
 
== The Controllers for Smart Plug ==  
 
== The Controllers for Smart Plug ==  
  
The class for the MVC controller is also the class you create to run the application: see the code at the bottom of the file, just run the file.  Similar code is at the bottom of some of the other source files to make it convenient to run from those files, this is just to make it easier in development, the code in smart_plug.py is the model for what should be used.  Sometimes the code at the bottom of other file may have code for testing objects in the file, it may not be maintained, may not work as intended.
+
 +
 
 +
This is the class you create to run the application see the code at the bottom of the file, just run the file.  Similar code is at the bottom of some of the other source files to make it convenient to run from those files, this is just to make it easier in development, the code in smart_terminal is the model for what should be used.  Sometimes the code at the bottom of the file may have code for testing objects in the file, it may not be maintained, may not work as intended.
  
 
The __init__ method is the initialization and "run" method for the application.  Much of the code that would normally be in it has been moved to .restart which is used to restart the application when just the parameters have been changed.  See the docstring there.
 
The __init__ method is the initialization and "run" method for the application.  Much of the code that would normally be in it has been moved to .restart which is used to restart the application when just the parameters have been changed.  See the docstring there.
Line 55: Line 57:
  
 
Yes I know that globals are bad, but they can be useful.  For example many class instances need to access the parameter file.  This can be done using the singleton class AppGlobal.
 
Yes I know that globals are bad, but they can be useful.  For example many class instances need to access the parameter file.  This can be done using the singleton class AppGlobal.
It has values at the class level ( not instance ) that are available simply by importing the class.  Most values are originally defaulted to None, and are set to valid values as the application initializes and runs.
+
It has values at the class level ( not instance ) that are available simply by importing the class.  Most values are defaulted to None, and are set to valid values as the application initializes.
  
 
== Threads ==
 
== Threads ==
  
The application runs two threads, one for the GUI and one where processing can occur ( HelperThread ) with out locking up the GUI.  There are 2 queues that allow the threads to communicate.  Multithreading is not used in the graphing application as of now.
+
The application runs two threads, one for the GUI and one where processing can occur ( HelperThread ) with out locking up the GUI.  There are 2 queues that allow the threads to communicate.
  
 
=== The Tkinker Thread ===
 
=== The Tkinker Thread ===
Line 67: Line 69:
 
=== HelperThread ===
 
=== HelperThread ===
  
Refers to similar but different program !! Will update for this program soon.
+
Refers to similar but different program !!
  
 
HelperThread in smart_terminal_helper.py  This class provides the support for a second thread of execution that does not block the main thread being run by Tinker.  I call the two threads the GUI Thread (gt) and the Helper Thread ( ht ).  It can get confusing keeping track of which method is running in which thread, I sometimes annotate them with gt and ht.  The helper thread is started by running HelperThread.run() which pretty much just runs a polling task in HelperThread.polling().  HelperThread.polling() is an infinite loop, it uses sleep to set the polling rate.  When used with the green house processing module, it may call a function there that is its own infinite loop.  There are a lot of details here, I should write some more about it.
 
HelperThread in smart_terminal_helper.py  This class provides the support for a second thread of execution that does not block the main thread being run by Tinker.  I call the two threads the GUI Thread (gt) and the Helper Thread ( ht ).  It can get confusing keeping track of which method is running in which thread, I sometimes annotate them with gt and ht.  The helper thread is started by running HelperThread.run() which pretty much just runs a polling task in HelperThread.polling().  HelperThread.polling() is an infinite loop, it uses sleep to set the polling rate.  When used with the green house processing module, it may call a function there that is its own infinite loop.  There are a lot of details here, I should write some more about it.
Line 77: Line 79:
 
The standard gui has a button to kick off editing of this file, the application may then be restarted ( another button ) with the new values.
 
The standard gui has a button to kick off editing of this file, the application may then be restarted ( another button ) with the new values.
  
There are a couple of meta parameters, including os_win, mode and computername which then may be used in conditionals later in parameters.py.  Except for this sort of thing there is really not much "code" in parameters.  You can change this code pretty much as much as you like, as long as you end up setting up values for the required parameters.
+
There are a couple of meta parameters, the most important of which is mode which is then used in conditionals later in parameters.  Except for this sort of thing there is really not much "code" in parameters.  You can change this code pretty much as much as you like, as long as you end up setting up values for the required parameters.
  
 
The code is extensively commented: use that for documentation.
 
The code is extensively commented: use that for documentation.
Line 84: Line 86:
  
 
For more info see:  [[Configuration Files For Python]]
 
For more info see:  [[Configuration Files For Python]]
 
== DataBase ==
 
 
The database is SQLLite.  So far it seems adequate to the task.  Access is via string of SQL and variables bound to those statements.  Look for the code in .......
 
  
 
== Polling ==
 
== Polling ==
Line 93: Line 91:
  
 
== Logging ==
 
== Logging ==
This uses the standard Python logging class.  Logging level and other logging details are controlled using the parameter file.
+
This uses the standard Python logging class.  Logging level and other logging details are set up using the parameter file.
  
 
== Other Classes ==
 
== Other Classes ==
Line 117: Line 115:
  
  
[[Category:Python SmartPlug]]  [[Category:Python]]
+
[[Category:Python SmartPlug]]  [category:Python]]

Please note that all contributions to OpenCircuits may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see OpenCircuits:Copyrights for details). Do not submit copyrighted work without permission!

Cancel Editing help (opens in new window)