Skip to content

OpenPod is an open-source access control bridge. OpenPod provides a persistent link between a cloud database and local hardware.

License

Notifications You must be signed in to change notification settings

RecursionSpace/OpenPod

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

OpenPod

CI | E2E Integration   CI | Pylint   CI | Script Check   CI | Build & Test   CI | Installer

What is OpenPod?

The “Pod” is the physical extension of the Recursion.Space system for a facility. The Pod allows for door/egress and equipment control nodes. Additionally, the Pod acts as a local backup in an internet outage for users to continue accessing their facility. The Pod has a direct internet connection then uses a wireless method to communicate with nodes. A single facility can have multiple Pods, but each Pod can only be linked to one facility.

Note: Versioning follows the Semantic Versioning 2.0.0 standard

Installation

OpenPod is designed to communicate with hardware over a local mesh network using XBee module. While OpenPod can be installed on any computer running Ubuntu, most installations are done on a Raspberry Pi. To prepare a Raspbery Pi for OpenPod checkout the Pi Setup Guide.

For convenience, an installation script as been provided that will download OpenPod and make the necessary system changes to get OpenPod running. This script can be run from the command line using the following command:

sudo wget -qO- https://openpod.recursion.space | bash /dev/stdin [options] [arguments]
Option Flag Description Example
-h Help sudo wget -qO- openpod.recursion.space | bash /dev/stdin -h
-d Enable Debug Installation sudo wget -qO- openpod.recursion.space | bash /dev/stdin -d
-b Alternative Branch sudo wget -qO- openpod.recursion.space | bash /dev/stdin -b dev-release
-u Set Custom URL endpoint sudo wget -qO- openpod.recursion.space | bash /dev/stdin -u stage.recursion.space

*No supported arguments are currently supported.

Software Design

The embedded code manages the communication between the API server and the node communication, acting as a middleman. There needs to be minimal factory configuration to make deployable units quickly.

  1. Assume the Pod is plug and play internet connection. (DHCP)
  2. Pods can self-generate ID and register it with the central system.
  3. Users enter an ID to link the physical Pod with the web interface.

Pod communicates to the web API via hook notifications, and a return confirmation is sent back.

  • Records Door/Equipment access
  • Registers new nodes and Pods
  • Pulls info dumps

The web interface communicates with the Pod via MQTT.

  • Alerts for new users
  • User updates
  • Remote control (door unlock)

Each Pod is on its MQTT topic, and the topic is created once the Pod registers with the central system.

Development

Pod software development is done on a DigitalOcean hosted server. It is then transferred to the physical hardware running the system and tested before going into production.

MQTT

The MQTT protocol is used for server to Pod communication, allowing the Pod to listen in real-time for incoming instruction.

Communication to Pods is accomplished from quick commands represented by a hexadecimal number.

Command Number Command
AA (170) Facility ID Available
BA (186) Pull User Dump
CA (202) Update Available
DA(218) Time Zone Change
FA (250) Zip & Send Logs

Updates

The end-user triggers updates via the web server to run them with minimal interruption. An MQTT message is sent to the Pod to initiate the updating process. The update is a zip file downloaded from the server.

  1. Download zip file from server and store in the update folder.
  2. Unzip contents of a zip file
  3. Run Launcher

First, commit and push the latest changes to git to prepare an update. Using WinSCP, download the 0_1_0 folder with the newest code. Rename the downloaded folder to match the latest version number. Zip the folder's CONTENTS, so there is no second directory folder with a matching name inside the zip file folder. Clean up all extra copies of the old folder. Update the latest version name using the recursion admin panel, then update their devices.

Logging

The Recursion System uses several logging points to be used both for troubleshooting as well as security and auditing. There are two log files created for the Pod, RecursionLog.log, and TransactionLog.log; each one is used as follows:

RecursionLog.log is used to record system events.

  • Coming online
  • Updating
  • New Nodes being added
  • Nodes coming online

System.Snapshot file contains a JSON summary of the Pod for debugging purposes. The information available in this file must also be readily accessible from the server for troubleshooting purposes.

{
    "local_ip": "xx.xx.xx.xx",
}

Repository Directory Structure

.
├── .github             # CI/CD using GitHub Actions and other functions.
├── tests               # Contains unit testing files.
└── openpod             # Contains OpenPod functionality.
    └── modules         # Independent core functions.

Deployed Directory Structure

OpenPod/
|--------- Version A/
	|--------- HUB.py
    |--------- HUB_Launcher.py
    |--------- HUB_Updater.py
    |----------settings.py
    |--------- modules/

|--------- logs/
	|--------- RecursionLog.log
	|--------- TransactionLog.log

|--------- data/
	|-------- dump.json
	|-------- owners.json
	|-------- nodes.json
	|---------permissions.json

|--- system.json

Community and Contributing

OpenPod is developed by Recursion.Space and by users like you. We welcome both pull requests and issues on GitHub. Bug fixes and new protocols are encouraged.

Discord Banner 2

About

OpenPod is an open-source access control bridge. OpenPod provides a persistent link between a cloud database and local hardware.

Topics

Resources

License

Stars

Watchers

Forks