CarontePass: Open Access Control

This is important for a reader on the side of the entrance door and another on the side of the exit.

Code Github

I leave the scheme has finally worked:

PINOUT:

Testing bench:

Here you can find everything you need for mounting hardware part of clients (doors).

Assembly diagram:

PINOUT:

Schema Wemos D1 Mini:

Technical specs

Pin

All IO have interrupt/pwm/I2C/one-wire supported(except D0)

Warnings

All IO is work at 3.3V.

Here's how it works now, now asks username and password to access the info.

But I'm already working on a version with access token and under https.

By raising the project I thought many ways to do it, but the scalability thinking I was left with the option of that clients (doors) to be as "dumb / simple" possible.

To achieve this required a part of the powerful server, so I chose Django and ... How to have N doors? How to make it cheaper-single doors possible?

The easy thing would have been to put a guy Raspberry Pi computer-door, but that was not what I wanted (if it was the easiest).

The best option I found was to make an API, which could use different technologies to clients but to run only need an Internet connection to make inquiries.

How does it work now?

A web request to the url defined in Django project is:

yourdomain/api/1/device/code

Explanation:

1. The client (a door) NFC reader reads and gets the tag.
2. That tag puts it in "code" and makes the previous request.
3. The server parses the url, receives the "code" and searches the table of "devices" where all tag IDs are stored.
4. The tag is an associated usaurio so already has the identidicación.

Here is an example:

There are a user with Tag "123456" of the NFC type. Passing this NFC reader gets the Tag creates the url and makes the web request:

yourdomain/api/1/device/123456

For the answer we will have to authenticate:

If you have access to the API devuleve following the Django framework REST:

Responds to the request in JSON format, we parser on the client to get the data that interests us.

For example, to activate the relay to open the door should be fixed in the "result" field. If the user meets the access requirements will result "True" and the relay will be activated.

Now security is not the maximum possible from my point of view, so I'm studying how to implement HTTPS.

Other forms of access

The project leaves open the possibility to add different forms of access.

One may be for Telegram, having the only Chatid each user could search for it using the "/ open" command Bot Telegram. I like it because it is a safe and smart way to enter a space with any device that has application without any extra hardware card carry any type NFC / RFID, etc ...

I edit the database by adding a table related to the user and the Chatid field that is used by Telegram to identify users.

Improved Admin to see the table Telegram and created the "message_detect_tag" class in the models to detect if the user enters or leaves the space and thus send a personalized greeting or farewell.

This message system is independent of bots Telegram to fall if continue to send these "simple" messages.
Also warns a group of Telegram when the first user (Site Open) enters or exits the last (Closed Site).

Add the Bot Telegram, programmed in python using the TelegramBotApi.

• Know if the space is open or closed by the command "/status".

• Return a list of users who are within the space at that moment in the command "/users_in".
• (Coming soon) Option to open the doors using the command "/open" to persons authorized to do this.

Can you think of a new option?

Today I want to show the "engine" of the project management section Django.

In it you can manage everything related to user management (personal data), user fees, the tags with which they can access the space, the table chatid of Telegram, system messages and access logs ( logs).

It also allows the creation of groups and give special permissions to users, but this for later, so that the member of a group to be allowed access to a restricted space to rest.

The database has the following structure:

Therefore when signing the Django Admin see ...

Then we will see each section separately to have more detail the operation of the system.

Devices: Devices that can be accessed. There may be several types and number per person.

System Logs: View a record with dates of inputs and outputs of users. See also allows simple so that users are in space at that time.

Messages: Topic to manage messages. These can be of various types.

When entering or leaving a user searches for a message of that type (input or ouput) and sent it by Telegram, it is a good way to surprise with the user every time you pass your tag to enter or exit.

He also writes a group of Telegram when entering the first or the last saying out if the site is closed or open.

Payments: As spaces is very crowded, usually have partners who have monthly fees. This is a way to control salt in if the user is aware of your payments.

Telegram: This table is used to store chatid providing users if they want to receive personalized messages.

In the future it will also serve to give physical access to space just write "/ open" to the bot Telergam.

Users: Personal information of usaurios. Nicks, name, email, password, etc ...