Introduction
This is my idea to develop a smart device, using the Arduino MKR WAN 1300 Board, which will help make access to communal spaces smarter. The reason for this blog was to put forward a proposal for the "Build a Smarter World" contest.
Problem to be addressed
There has always been a dilemma on how to manage public amenities effectively. One the one hand, if amenities have open access and are not monitored then anti-social problems tend to arise. While on the other hand, if access control is introduced then there is always a cost associated with operations and maintenance and in many cases there is no business case to provide supervised monitoring services, or it is operationally or technically not viable to introduce more advanced access control solutions. So a padlock and key or a simple keypad ends up being used which has its limitations and drawbacks.
Proposed solution
My proposal is to develop an access control device using LoRa, which is a free to use local wireless area network, as the means to handle event messaging between the remote device and the central connected gateway, which can then be managed remotely by the community responsible for the local amenity.
The proposed project will also repurpose and will certainly enhance an idea I had originally developed earlier and published on Hackster.io (an Element14 sister company), which I called “Grovey Slocks” (as it used grove modules and was attempting to be a smart lock).
My new “LoRaSlocks” solution, aims to use a similar data flow topology I had developed for GroveySlocks where the person wanting access to a particular amenity requires a smartphone which can connect to the Internet using the 3/4G mobile data network.
In this case, the cellular connected smartphone will first connect with the lock locally using Bluetooth low energy (in my opinion, BLE removes the necessity for keypads and provides a much better peer-to-peer data exchange or communication platform than NFC can provide). This connection simply verifies the legitimacy of mobile app being used on the smartphone. This connection process also wakes up the LoRaSlocks device and causes the device to send a message to the gateway saying “someone wants access”. This message is then relayed either locally via a local gateway interface or via the Internet to someone in the community, which will receive a notification via a messaging app such as Messenger or Slack, for example.
All sorts of design options are then opened up from either providing an automated response or a manual access approval response, which would be required from someone in the community linked via say a Slack or Messenger group. You could even have it that someone in the community could then chat with the person wanting access etc. to obtain further verification via the messaging system. No doubt there are trade-offs between levels of validation and latency or length of time the person has to wait before access is given.
The approval process will then send an encrypted access code to the person via their mobile app and the LoRaSlock’s device will then also receive a code via the LoRa wireless connection. The smartphone app then decrypts the code received and then sends an access code via the BLE connection. When the codes match the LoRaSlocks device releases the locking mechanism and allows access.
The device itself will use the relay to activate a solenoid based electromagnetic lock release mechanism, once the correct data has been received and matches the authorisation rules defined in the system. The design for the device will also have tamper protection and could include other sensors such as gate/door open and closed detection. These events can all be relayed back to the gateway via LoRa wireless.
Top Comments