Ryp edited this page Aug 5, 2014 · 10 revisions

Module architecture

Leosac is designed to be flexible and maintainable. We chose to split the architecture in several modules, each having a particular role, monitored by the core program that will handle the communication between each one of them.

Here's a list of the different modules:

  • Door
  • Access Point
  • Authentication
  • Logger
  • Monitor

Each one of these modules can be modified or even re-implemented to provide a new set of custom functionality. Multiple instance can be spawned by Leosac, each with its own configuration.

These modules are implemented as Unix shared libraries, and are loaded at run-time. Ex: could be the file containing a led-based monitor module.

When you setup Leosac, a typical configuration should look like this:

<module file="">

See Core configuration basics.


The door module is abstracting the door behavior (obviously).

If we ever want to open, close or read its state, this is the module we want to talk to. However, it could not only be a physical door, but completely different devices, like the lights of a room, or a secured metal case.

The important notion here is that this module represent something that is restricted, that we can unlock for authorized users. 99% of the time, this will effectively be a door, but can be something else, because the underlying system will not care about the real physical device.

Access Point

The access point abstraction is be used to represent a RFID card reader, a mural keypad, an optical scanner or even a combination of the previous devices. Anything that can be used to ask access to open a door can be an access point.

The global idea is that this module provides a identification information that then will be used to tell if the access request is authorized or not.

The default implementation of this module handles a wiegand RFID card reader.


The authentication module handles requests from access point modules. Depending on the implementation, these requests can be sent through the network and processed by an external service, or compared against a user id database locally.

Note: it's the only module that can only appear once in the configuration file.


This optional module can be used to filter events coming from the core program. Everything Leosac does is sent to logger modules, that way its simple to implement custom notification systems, like automatic e-mail alerts for users that were blacklisted. The default implementation simply prints out what is happening on the system in real time.


The monitor module works a little bit like the logger. It can also filter events, but only by type. No further information is held, so when something is sent through the monitor, only a channel is specified. That way the system can tell "hey, something was sent to the authentication module" in a specific channel, or notify that a device is busy on another.

The main goal of this "high-level" notification system is to implement visual feedback when building a Leosac setup. With a few LEDs and the appropriate logic, it is possible to let the user know if the network is up and running, trigger LED blinking when a authentication request is sent through the system, or any information that can be used to verify that Leosac is correctly set up.

Of course, other modules have to provide enough feedback and send events when needed, otherwise the monitor would not have anything to filter.

This advanced module is mainly reserved for debugging purposes, but the abstract nature of the implementation can be used to produce several behaviors and uses.

The default monitor uses a LED for each channel and triggers blinking when an event is sent.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.