I'll start with that, what a way of curbing ESP8266_RTOS_SDK, and this is the path I chose for myself, doesn't come easily. The latest victory was the optimization of the card reader RFID library from STM to ESP. How did the story of this smart lock project continue?, part-time and call.

This article is not a tutorial.. I only describe in it my open source device and its operation.. so that you can get some ideas or implementations for your projects.

Technical descriptions will be presented in the project repositories, and here I will briefly describe the principles and resources.

The “brain” of the device is the controller ESP8266 acting as a card validator, lock control, a call and a module connecting with the outside world. They help him with this:

• RFID tag reader board – MFRC522 connected via SPI
• module touch button working at a distance 5 mm
• any managed electronic lock

Everything is not perfect in the source code of the firmware, but i try to improve. All parts of the firmware are located in different components and are independent. This means, what are the components:

• lock_access - Responsible for granting card access
• lock_connect – responsible for connecting the lock to the network and server
• lock_hardware - is responsible for controlling the iron part of the lock (the door, if it makes more sense)
• rc522 – optimized for the target SDK library for communication with the RFID tag reader module

We figured out the name and purpose. More about independence.. Each of the components starts and runs in parallel, and data is exchanged through the RTOS functionality. So the lock won't stop working, in case there is a problem with Wi-Fi. And get home, if the card reader module fails, it will be possible through the phone and the MQTT server by giving the module a signal to open the door.

Now, for lack of practice, the iron part of the lock is not calibrated for real tasks, but the functions of opening and closing the lock are provided, although now most locks work on the principle of opening and snapping, but I do not have the financial ability to organize a field for practical application. In the future there will be improvements based on real events so to speak.

Let's look at some of the features of the components

Each component has a minimum 1 function - initialization function. It eventually runs a task with the component's request processing logic. The task is done for, to easily add new components without changing old ones.

lock_access

This component initializes the card reader module and its task is to poll the presence of a card in a loop and read its UID for identification. When the correct card is identified, the module writes to the general group of events (RTOS capabilities) a signal about obtaining access by card, otherwise - a signal about blocking access by card.

In order not to “tease” the reader, cycle has a delay of 100 ms. which does not significantly affect the response.

lock_connect

In this component 2 provisioning functions for Wi-FI and MQTT.

In the Wi-Fi initialization, the firmware tries to connect to the access point, whose name and password , at the moment, are written when compiling the firmware. With luck, writes a connection bit to a separate event group.

MQTT creates a task, in which it is waiting for a connection with an access point. After connecting, an attempt is made to connect to an MQTT broker.

When the castle receives a message, the firmware sends the corresponding bit to the event group of the entire firmware. For example: if you want to open the lock from your phone, a message will be sent to the castle and will be included in the group.

Also the MQTT task is waiting for the event, which must be processed. These are the events of obtaining / denying access by card and the event of pressing the call. Accordingly, your phone or other part of the “smart home” will receive notifications about this event..

lock_hardware

Currently responsible for 2 devices: the lock itself and the bell (button). The corresponding outputs of the module are included in the initialization.

In the task, the component waits for an event from the component lock_access about gaining access or a component lock_connect about the request to open the door via MQTT.

It also handles the button click event., by which the component leaves the corresponding bit in the event group.

rc522

The operation of this component will be described in the wiki page corresponding to its repository.

Scheme

The reader is connected via the SPI interface. Pin to control the latch (electronic lock) is now D1, and to track the pressing of the call key, a pin is used D2.

Conclusion

In conclusion, I will say, that this is the start of a bigger project, work on which will continue without the support of the site Ardino Geek

Further development will focus on smart lighting and appliances, and cheap network, managing them.

Sources

• Lock Firmware Sources
• Communication component with MFRC522

---

Thank you for your attention! Do not be ill.