Skip to content

Latest commit

 

History

History
66 lines (56 loc) · 3.86 KB

components.rst

File metadata and controls

66 lines (56 loc) · 3.86 KB
Raw

Automate Components

automate.program.Program automate.program.DefaultProgram automate.statusobject.StatusObject automate.statusobject.AbstractSensor automate.statusobject.AbstractActuator automate.callable.AbstractCallable automate.service.AbstractService

Automate system is built of the following components:

  • System (derived by user from ~automate.system.System) binds all parts together into a single state machine
  • Services (subclassed of ~automate.service.AbstractService) provide programming interfaces with user and devices that can be used by SystemObjects.
  • SystemObjects (subclassed of ~automate.systemobject.SystemObject or ~automate.program.ProgrammableSystemObject):
    • Sensors (subclassed on ~automate.statusobject.AbstractSensor) are used as an interface to the (usually read-only) state of device or software.
    • Actuators (subclassed on ~automate.statusobject.AbstractActuator) are used as an interface to set/write the state of device or software.
    • Programs (subclassed on ~automate.program.ProgrammableSystemObject) define the logic between Sensors and Actuators. They are used to control statuses of Actuators, by rules that are programmed by using special Callables (subclasses of ~automate.callable.AbstractCallable) objects that depend on statuses of Sensors and other components. Also Sensors and Actuators are often subclassed from ~automate.program.ProgrammableSystemObject so they also have similar features by themselves. Depending on the application, however, it might (or might not) improve readability if plain ~automate.program.Program component is used.

All Automate components are derived from ~traits.has_traits.HasTraits, provided by Traits library, which provides automatic notification of attribute changes, which is used extensively in Automate. Due to traits, all Automate components are configured by passing attribute names as keyword arguments in object initialization (see for example attributes ~automate.extensions.arduino.AbstractArduinoActuator.pin and ~automate.extensions.arduino.AbstractArduinoActuator.dev traits of ~automate.extensions.arduino.ArduinoDigitalActuator in the example below).

Automate system is written by subclassing ~automate.system.System and adding there desired ~automate.systemobject.SystemObject as its attributes, such as in the following example:

from automate import *
class MySystem(System):
  mysensor = FloatSensor()
  myactuator = ArduinoDigitalActuator(pin=13, dev=0)
  myprogram = Program()
  ...

After defining the system, it can be instantiated. There, services with their necessary arguments can be explicitly defined as follows:

mysys = MySystem(services=[WebService(http_port=8080), ArduinoService(dev='/dev/ttyS0')])

Some services (those that have ~automate.service.AbstractService.autoload atribute set to True) do not need to be explicitly defined. For example, ~automate.extensions.arduino.arduino_service..ArduinoService would be used automatically loaded because of the usage of ~automate.extensions.arduino.arduino_actuator.ArduinoDigitalActuator, with default settings (dev='/dev/ttyUSB0'). Instantiating System will launch IPython shell to access the system internals from the command line. This can be prevented, if necessary, by defining keyword argument ~automate.system.System.exclude_services as ['TextUIService'], which disables autoloading of ~automate.services.textui.TextUIService. For further information about services, see services.