 | An Open-Source platform to create digital devices and interactive objects that sense and control physical devices. | Arduino Tutorials |
| Arduino Projects |
Introduction
This is the follow up to my previous blog "Smarter Access Control using Arduino MKR WAN 1300 boards" which forms part of my entry to the Arduino “MAKE A SMARTER WORLD COMPETITION”.
Let me start by saying that my overall objective for this project is to showcase the breadth of the Arduino ecosystem, whilst using the Arduino MRK WAN 1300 as the centre piece. My objective therefore is not to deep dive into LoRa and work out how to optimise my wireless design to achieve good data transmission performance at maximum possible distances. That in my view comes later, once proof of concept has been established.
As mentioned in the previous blog, this phase 2 of the project covers the community aspect, which aims to demonstrate one of many possible logic flows that can help make access to communal spaces smarter through the use of connectivity and wireless technology, such as LoRa.
So, phase 2 will introduce the concept of a LoRa gateway, which acts as the interface between the Internet and the LoRa wireless network. In my case this gateway will be a very simple single channel private gateway as I plan to connect a WIFI module to the MKR 1300 board. However, with the MKR 1300 board I could also link into a public LoRaWAN network and use a public gateway to communicate to a cloud server.
The logic flow I used covers the “right of way” scenario, which allows any person (anonymous) access to a specific public (or private) space, but for various reasons you would still want or need to have control over that access and you would want to have knowledge that such access was gained.
So, for this scenario, the anonymous person has to remain anonymous and thus cannot be expected to download an app or use a smartphone to gain access. As such, the simple push-button is used to make the access request. I included a keypad to ensure that the user still has to enter a one-off key code to gain entry. The removes the scenario of random passersby pressing the button and moving off – as so often happens in apartment blocks etc.
To provide an overview of how it works, here is the top level data/messaging flow for the application:
As highlighted in the diagram, the architecture can be split into two halves.
The device level side was all developed using the Arduino ecosystem. In my case, this involved developing firmware for 4 x micro-controllers with 2 x MKR 1300's forming the important link between the remote Access Control Panel and the Central Control Unit / Gateway. For the WiFi Bridge I used a NodeMCU ESP8266 as this provided the simplest connectivity option and I also just happened to have one on my desk. The NodeMCU could readily be swapped out and an MKR 1000 or MKR 1010 could be used instead with minimal changes to the code. This is the power behind the Arduino IDE and library architecture.
To provide a communal aspect requires a cloud service. For this project, I wanted to use Slack as this web service is ideal for creating groups or channels where you can assign specific members. Slack also has an API allowing you to create your own notification and response applications. I then chose PubNub as my cloud platform as this provided me with the best option going forward for the messaging broker side, and they just happen to have an Arduino library to get you started and they also offer serverless functions, which is the real power behind developing specific business rules the access control application.
Now, before I dive into the details...
Let’s start with some Working Demos
The first working demo was taken indoors:
The second demo is a more exciting distance test where the Gate Access Control Panel is +100 metres away (line of site) from the Central Control Unit and happily communicating with the central control unit. I find this quite remarkable as my programs are using all the default settings and I am not using optimised LoRa antennae:
For testing, I decided to attach an ePaper display to my single channel MKR1300 LoRa module + NodeMCU/ESP8266 gateway to capture the LoRa RSSI and SNR values. Here are two results for the 100 to 105 metre range:
| {gallery:autoplay=false} My Distance Test Results |
|---|
|
|
There are two values shown. The first data log is when the one MKR 1300 is powered up (designated P). The second is when a open gate request is sent and this message is acknowledged as being received (designated A). The data is timestamped as minutes and seconds from bootup. The first value is RSSI and the second value logged is SNR (which is multiplied by 10 and shown as integer).
I also performed a slightly longer test at 125 metres, which was successful too, but only just. At longer distances it failed, which is not the fault of LoRa but indicates to me that I would need to adjust the default LoRa settings and test my antenna etc.
Still, I am very happy that by simply using the LoRa library default settings and GSM antennae, with frequency set at 868MHz (for EU), I was getting resilient communication performance at circa 100 metres using single message packages. There are so many options to play with to improve matters, for example, increasing preamble message length (ok for peer to peer), sending a duplicate short message package (if total package length, including 13byte preamble, is < 20 bytes, for example, this is doable and I believe will still satisfy duty cycle rules), or changing frequency slightly etc.
Anyhow, I am not a LoRa expert so I may be wrong here on the exact details. My view is to learn by doing and make sure you comply with the rules.
Dissecting the embedded side
As mentioned all firmware was developed using the Arduino IDE. There are four microcontrollers, which are numbered in the diagram below. I will now walk through each module separately.
Starting with the Gate Access Control Panel first.
1. Gate Access Control Panel
1.a Adafruit Feather 32u4 Bluefruit LE
I decided to use this board simply because it uses one of the original Arduino chipsets, namely the Atmel 32u4, which you would find on the Arduino Leonardo boards. However the Adafruit Feather version operates only off 3.3V rather than 5V. The Adafruit Feather board also includes a Bluetooth Low Energy module. The idea here, although not implemented for this write-up, is that Bluetooth Low Energy can be used for parameter configuration and customisation. Another option is to allow for users to connect via a custom app. This would create a different use case altogether.
Another good thing about basing the development off the Arduino IDE is that if the 32u4 proved insufficient for the purposes of the application, I could readily swap this out and replace it with the Adafruit Feather M0 Bluefruit LE board, which would provide more capability.
The functionality handled by the Adafruit Feather includes the LCD test display, keypad digit entry, random 4-digit pin codes, and serial communication with the Arduino MKR WAN 1300 board. The code developed for the Feather 32u4 board is provided in the github repository: https://github.com/Gerriko/LoRasLocks-MKR1300
b. Arduino MKR WAN 1300 Board
The purpose of the Arduino MKR WAN 1300 board is to provide LoRa wireless communication with the central control unit and to handle the instruction given by the access control panel to activate the relays to unlock the gate and trigger the buzzer.
As the Feather 32u4 is handling the UI, there is also plenty of GPIO’s free for future enhancements, such as including a light sensor (mentioned in blog 1) and for including sensors that can monitor whether the gate is closed or not. The code developed for this Arduino MKR WAN 1300 Board is provided in the github repository: https://github.com/Gerriko/LoRasLocks-MKR1300
2. Central Control Unit
The Central Control unit and LoRa gateway acts as the interface between the Internet and the LoRa wireless network. In my case this gateway will be a very simple single channel private gateway as I plan to connect a WIFI module to the MKR 1300 board. However, with the MKR 1300 board I could also link into a public LoRaWAN network and use a public gateway to communicate to a cloud server. So I have plenty of options to play with.
| {gallery:autoplay=false} My Gallery Title |
|---|
|
|
a. Arduino MKR WAN 1300 Board
The purpose of the Arduino MKR WAN 1300 board within the central control unit is to receive and respond to the LoRa wireless communication coming from the access control panel. It is also used to generate a chime using I2S generated tones and handling the pushbutton and wifi module interrupts via GPIO’s. For debugging purposes it communicates with an ePaper display using SPI bus and communicates with the NodeMCU using UART to handle the pub-sub communication protocol with PubNub via Internet. The code developed for this Arduino MKR WAN 1300 Board is provided in the github repository: https://github.com/Gerriko/LoRasLocks-MKR1300
b. NodeMCU ESP8266 board
The purpose of the NodeMCU board is to manage WiFi connectivity with the local wireless router and for handling messaging between the NodeMCU and the PubNub gateway using the PubNub library. The code developed for the Node MCU is provided in the github repository: https://github.com/Gerriko/LoRasLocks-MKR1300
Communication via the Cloud
What got me started with PubNub was this blog, which solved all the difficult parts for me. So for all the cloud communication handling, it really was just a case of following their example code (why reinvent the wheel).
https://www.pubnub.com/blog/secure-remote-door-control-with-typeform-pubnub-functions-slack/
I made another video which focuses on my testing of the messaging services:
The Slack messaging is basically a notification asking a question:
And when someone responses it changes the messaging context so you know the action taken. Here are the two cases:
And that is it. When someone responds the Slack API responds back to Pubnub which in turn publishes a response which is picked up by the NodeMCU board. What's quite pleasing with this process is the speed of the PubNub serverless pubsub handling. As you may have noticed in the demos it takes about 3-6 secs for the slack channel notification to hit the smartphone or computer but no more than a second for the slack response to arrive back at LoRa gateway and transmitted back to access panel. Note that in the video demos, the smartphone is used for demo purposes only – or it is a way, as a member of the Slack channel community to let yourself through the gate. A smartphone is not required by the general public to gain access. They simply want right of way.
Summary
The standalone side of the project was something I have toyed with over the years, but was missing an important link to deliver what I had in mind. Hence, I want to thank element14 and Arduino for providing the MKR WAN 1300 which delivered everything I needed to make a prototype and spark some imagination in developing this idea. The key take away for me is that with the breadth of the Arduino ecosystem so much more is possible and LoRa is just one element of the puzzle.
Top Comments