MudPi consists of multiple workers that are each responsible for a certain set of actions. MudPi takes advantage of multi threading to prevent blocking sensor reads or long processing cycles. Each worker will run on its own thread and uses threading events to communicate internally. This is why redis is used to utilize its Pub/Sub capabilities for externally interacting with threads such as telling the system to turn on the relay to power the pump.
Currently there are several workers included in MudPi, they are as follows:
Responsible for checking if the relay should be on. Listens on a channel for a
switch event to respond. The channel the relay listens on is defined by the set
topic in the relay configuration. A relay worker will be loaded for each relay configured. If you have 3 relays there will be 3 relay workers.
Runs any sensors attached to the raspberry pi and stores their readings to redis every 30 seconds by default. Publishes any new sensor readings over redis. One sensor worker runs all the sensors attached to the pi.
Runs any controls attached to the raspberry pi and triggers any linked actions to the controls. Controls are buttons, switches, latches etc. Controls can have zero to many linked actions when they change state.
Controls the connection between an Arduino and the pi. Also responsible for loading control and sensor workers if configurations are present. This worker will handle both wireless and hardwired connections.
Controls any Arduino(s) attached to the raspberry pi over serial connection and stores sensor readings attached to the Aquino GPIO every 15 seconds by default. One node worker will be loaded per node and run all the sensors attached to that node.
Runs any controls attached to the arduino and triggers any linked actions to the controls. Controls are buttons, switches, latches etc. Controls can have zero to many linked actions when they change state.
The camera worker controls the attached camera and will capture photos per the specified
delay. New images will be saved and their path gets published in an event.
The purpose of the workers is to control a section of MudPi and offload that process through multi-threading to prevent long read chains. One of the core tasks a worker provides is gathering an publishing events on the event system. Workers are also where sleep intervals are set to help keep the system from burning too much power.
Sometimes errors happen in electronics. More often than anticipated, however MudPi is fairly resilient to errors and will usually eat minor ones. In the event there is a breaking error on a worker, MudPi can keep running all the other workers currently loaded. A worker can not be restarted by itself in the event of an error, the whole system should be rebooted.
Worker settings can be customized in MudPi through their configuration in the
mudpi.config file. You can learn more about the available options on the worker configuration page.