This post is the 2nd part in my Arduino Entryphone project, which has expanded somewhat since first planned.

I’d always intended for this to be a learning project, and the number of things I want to learn from it has grown, covering the electronics side, programming languages and tools I’d not used before. Whilst my original intention was to build a web front-end that could be hosted, and therefore updated, externally and look better than a basic submit button, this has now grown to include microservices, serverless and message queues.

Whilst it would be best in most projects to come up with a list of requirements and then choose the tools to fit around these, for this project I’m adding requirements to specifically try out new tools. I attended Devoxx London 2019 last month and came away with quite a few ideas, especially from the Capgemini IoT stand.

HTTP POST Implementation

Before last weekend, I’d got a basic page and an externally hosted page up and running, and aside from the issues discussed here (HSTS), working. This didn’t use any user authentication other than the user having to be on the Wi-Fi network to be able to send the request. I really need to be able to give individual users access and log any actions which they take. I’d initially planned to do this through a database (sticking to what I know with PHP, Javascript, jQuery UI and MySQL), but thought it would be a good opportunity to learn more about other web frameworks and cloud service offerings.

Minimum Viable Product

I hit my first issue during the PoC of this when I found that hosting externally and trying to POST to an internal IP gave me a cross origin scripting error. I managed to get around this by setting the Access-Control-Allow-Origin header in the HTTP response from the Arduino to allow posts from anywhere. If I decided to go forward with this I’d restrict it to be the domain I serve the page from.

The next issue that I hit was that I appear to have the HSTS Policy for my domain set to Strict-Transport-Security, meaning that https applies to all subdomains too. This was problematic, because I didn’t have HTTPS set up on the Arduino, and therefore got another error when trying to POST:
Mixed Content: The page was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint. This request has been blocked; the content must be served over HTTPS.

I’m still trying to work out where the HSTS policy is being set; either through WordPress on my website or by Apache, so that I can exclude it for the subdomain I’m using for the door controller. In the interim, I’m able to get around it by using incognito mode.

First QA Testing

I shared the PoC link with my housemate, who immediately found a flaw with using jQuery load() when the connection drops: Requests are queued up and then keep running on the Arduino once re-connected. I was planning to fix this, but then thought I’d move over from HTTP POST requests to MQTT, and would be able to handle this with QoS.

The web page was in a state though where I was happy to share it, and the next day a friend who is habitually late (her record is 4 hours) turned up to mine on time, whilst I was still out shopping. I sent her the Wi-Fi code and URL and she was able to let herself in.

MQTT Implementation

Over last week’s bank holiday weekend I worked on moving over to message queues, using Docker to host mosquitto on my Mac. I seemed to have a few problems with websockets when using it directly on Mac, but the docker container worked fine. I used the HiveMQ MQTT Websocket Demo App to get up and running and check everything was able to connect. Yesterday I got Node-RED running under Docker on my Mac, allowing me to incorporate IFTTT Maker Webhooks for push notifications and limit the number of requests within a five-second period.

There is a limitation in the library I’m using, that it can only publish QoS 0 messages, which shouldn’t be too much of a problem, although means that providing feedback to the user could be challenging.

Since the first round of testing, I’ve moved all of the code over to Bitbucket and added a Trello Board, which my flatmate is using for feature requests and me for bug fixes. Maybe at some point I’ll open up the repo and board rather than adding to additional lists. The roadmap for my project now includes the following:

Software Roadmap

• Build out a progressive web app allowing logins, push notifications and user provisioning (depending on access level)
• Add Alexa support so the door can be opened by voice (ignoring the obvious security issue of somebody shouting loudly from outside).

Alexa Integration

For the Alexa integration, I considered a few options:

• Going down the developer route and building a skill
• Using IFTT / Maker webhooks and AWS IoT MQTT connected to my internal mosquitto message broker to relay messages
• Using a tool like Home Assistant – Hass.io to relay messages (I’m currently also trying this out in Docker)

Hardware Roadmap

• Detect when the buzzer outside is pressed, to allow notifications to be sent to those who have subscribed.
• Detect when the door is opened (for no particular reason)
• Detect motion in the hallway (again, not sure what the use case for this yet).

First Pass

It seems to be a May Spring Bank Holiday tradition that I decide to pick up Arduino projects. When I looked back at my WhatsApp history with my flatmate to find the photo that I’d sent to him showing what I’d started it was the 28th May 2018. At the time, I had an Arduino Uno microcontroller board (based on the Microchip ATmega328P) that I’d had since my University days, along with a relay, which I decided to put to use to make a tool to allow us to unlock our front door from our smartphones. Continue reading “Arduino Entryphone”