==========================

Doorbot Package for Farset Labs

Basic structure of package is

--- doorbot
  \ doorbot.py
  \ version.py
  \ interfaces.py
  \ jsonify.py
  \ views.py
--- tests
  \ tests_helper.py
  --- unit    # Unit Tests
  --- helpers # Test Helpers
\ Doorbot.apache.conf
\ doorbot.wsgi
\ requirements.txt
\ setup.py

Package requirements are handled using pip. To install them do

pip install -r requirements.txt

Doorbot is designed to be setup under /opt/, where Doorbot.apache.conf is copied into the Apache sites-available directory (usually /etc/apache2/sites-available)

Then, enable the site with sudo a2ensite Doorbot.apache.conf; sudo service apache2 reload

Doorbot is configured using three JSON dotfiles in the operating-users home directory (/var/www/ for default apache config)

Contains authentication information of the form:

  { "username": "PassWord", "otheruser":"otherPass" }

These are 'authorised accounts' that can perform admin tasks, specifically opening the doors.

The intention is not for this file to be populated with each and every member or user of the system, but rather that authentication responsibility is delegated to secondary systems, eg a web front end, RFID reader, etc. Muliple usernames are enabled to support service-based monitoring (as in the RFID would have it's own username, etc.)

Multiple doors can be configured based on the available interfaces. There is also a dummy interface that provides logging-based debugging.

In the case of the piface interface, the interfaceopt is the output port which triggers the doors opening/unlocking.

For 'doors' that are just 'virtual endpoints' and not locally connected to the doorbot server, use the dummy interface

  {
      'doors':[
          {'door_name':"Front Door",
           'doorid':"front",
          'interface': "piface",
          'interfaceopt':0},

          {'door_name':"Workshop",
           'doorid':"<device_id>",
           'interface': "dummy"
          },
      ]
  }

This file defines the ID card authentication method (i.e. BasicAuth where the 'username' is the device id and the 'password' is an ID string from a RFID card or similar

  {
    "Default":[
      "IDSTRING",
      ...
      "IDSTRINGN"
    ],
    "Workshop":[
      "TRAINEDIDS"
    ],
    "Pod Space":[
       "SPECIALIDS"
    ]
    
  }

'Authentication' is currently handled by BasicAuth, and there are two 'verification' methods;

1. Standard Username:Password from the .doorbot_users file, which have access to all 'doors'
2. <device_id>:<card_id> defined between the .doorbot_config and .dootbot_cards files.

Dummy 'Hello World', shuold probably be populated with an api catalogue

Authenticated route: opens the given doorid based on the doorbot_config

Currently Authenticated but doesn't need to be; returns a list of the doorids

Inside the enclosure above the network rack in the co-working space, the piface as as wired up as it needs to be for the foreseeable.

IF ANYONE WANTS TO INTERFACE WITH OR EVEN CONSIDER OPENING THE ENCLOSURE, RECORDED DIRECTOR CONFIRMATION IS REQUIRED IN ADVANCE AND THE ENCLOSURE MUST BE RESEALED BY A DIRECTOR OR DI NEM AFTERWARDS

There are 12 interface lines wired up to the terminal strip in the top lid of the enclosure; they are split into two 'sectors' of 6, which represent the two proposed 'door' controls, with the front door on the 'left' and the currently unpopulated back door on the right.

Testing is set up using pytest and coverage is handled with the pytest-cov plugin.

Run your tests with py.test in the root directory.

Coverage is ran by default and is set in the pytest.ini file. To see an html output of coverage open htmlcov/index.html after running the tests.

There are no currently valid tests yet.

There is a .travis.yml file that is set up to run your tests for python 2.7 and python 3.2, should you choose to use it.

Released under the MIT License: http://www.opensource.org/licenses/mit-license.php