Naked Redirects

To facilitate external service access to Mediaserver8 which is on a dynamic IP, I set up a domain with dns redirect via duckdns. While this works fine for ww.mydomain.online, plain old mydomain.online was still defaulting to a GoDaddy page as the A record needs an IP address.

Recently I stumbled on this post which outlines a solution using wwwizer.com. Simply point the domain A record to their service IP address and they will 301 redirect it to whatever the www CNAME record is set to - in my case duckdns.org. Now both www.mydomain.online AND mydomain.online reach my server. Magic. And free!

The only caveat is that wwwizer don't do https, http only. I can live with that.

Authentication for Amazon Voice Services

In an effort to have my new Echo Dot announce incoming telephone calls, I would need to have it do push notifications. Sadly, this is not yet available on the echo platform. Happily, there is a workaround via custom skills that relies on leveraging Amazon Voice Services - essentially building parts of an echo in software.

To do so, it's necessary to obtain an access token to facilitate calls to the voice services api. This is not a straightforward process - and it's just a prerequisite for the push notifications themselves. I'm logging the process here for future reference!

Securing Skills

Having got a basic setup working with an Alexa Skill calling to Node-Red on my unRaid server, I was a little worried about the security of this setup long term. I was also unhappy with going through a Lamba function to bypass the HTTPS requirement for Alexa endpoints. I decided to set up better security.

Skilling Up

In anticipation of an Amazon Echo Dot arriving, I've been looking at ways of integrating voice control into home automation. There's a certain amount that Alexa can do by herself but to really tailor things, it's necessary to build custom skills. To get these integrated with my emerging openHAB / Node-RED infrastructure, I set about setting up MediaServer8 to act as a host for the skills logic, thereby allowing me to hook sensors and devices into the skills via Node-RED. (My design objective is to run as much code and services as I can locally to minimise reliances on web services and allow everything to be glued together on my local server).

The idea was to run the core skill logic on my Node-RED install running on my unRAID server. To acheive this, I largely followed this excellent guide which required me to set up an Amazon Developer account. Alexa skills can be configured to process on either the Amazon Lambda service or on a user-defined https endpoint.

unRAID Node-RED Docker with HTTPS

I'm knee-deep in setting up a bunch of automation stuff and was very interested to come across a blog article from Nathan Chantrell outlining how to set up an amazon Echo skill to allow voice commands such as 'Alexa, tell the house to....'. This allows Echo be extended beyond just the basic 'turn on, turn off commands' and permits custom responses as well.

Nathan uses Node-RED at the core of his automation system and I've been gravitating towards this as well, having previously set it up as an unRAID docker for helping openHab communicate with my legacy Comfort controller. It's a very flexible system and, when combined with MQTT, really does offer a great solution for managing automation messaging.

However, to implement this skill, it's necessary to allow Amazon development servers have access to my Node-RED instance running on my unRAID. The first step in this is getting Node-RED running in HTTPS mode.

openHAB debugger

Having previously set up the infrastructure for connecting my legacy Comfort system to openHab, I've started working with openHab items, sitemaps and rules to respond to sensor status updates. In doing so, I've ben working with scripts in openHAB and have been a bit frustrated by the level of debugging available. With MQTT and Node-Red in place, I wrote a simple facility to easily trace code objects and values.