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
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.
Over last week’s bank holiday weekend I worked on moving over to message queues, using Docker to host
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:
- 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).
- Going down the developer route and building a skill
- Using IFTT / Maker webhooks and AWS IoT MQTT connected to my internal
mosquittomessage broker to relay messages
- Using a tool like Home Assistant – Hass.io to relay messages (I’m currently also trying this out in Docker)
- 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)