(6) Remote Control ... Controlling a train from 'IoT' in "The Cloud"
The Architecture
It's time to start playing with those trains. To prove that we can control the layout remotely, we will be using an Azure IoT hub to send commands to a program linked up with the railway and we'll make things happen. In theory this could be done by someone on the other side of the world!
From previous articles recall how Alexa uses skills to communicate with an endpoint, which in the examples comprised the Amazon Lambda functions. For the model railway interface, we will require that Alexa talks to software that controls the railway, so we could if wished, make the software act as the endpoint and process 'Alexa intents' sent directly from the skill. However, we will be a little more cunning than that.
You will no doubt have come across the term IoT, standing for the Internet of Things. It's the notion that everything that can be controlled will be controllable from the Interweb, and as such everything from light bulbs to your fridge will have a unique ID that enabled control from mobiles Apps, Alexa, a foreign government and anywhere else for that matter. Why not then the railway, it's a thing, it is being controlled from the web, so let's treat it as a device on the Internet of Things.
There are a host of ways to control a device, Amazon, Microsoft, and Google all provide an infrastructure that makes it easy to write code to manage and control devices and for this, we will make use of the Microsoft Azure IoT system. I have previous experience coding with the Microsoft system and like a typical coder, will always migrate for the solution that is most familiar. Us coders are a lazy lot, always looking for the path of least resistance.
The IoT hub sits in the proverbial cloud and acts a message service between, in our case, Alexa and the rail software. Since Azure IoT is very reliable, Alexa is pretty much guaranteed to have a connection with it when it needs to. The railway software will then pick up those messages as when it wants. Well, OK, for this application that should be ASAP as we request a train to start moving we want it to it now and not next week, a notion very familar those accustomed to Southern Rail.
Finally, we come on to the rail software itself. We shall use a system built in-house by the name of the Big Bear Model Rail Controller, I should add that other rail controller software systems are available! Internally the Big Bear (as we'll call it from now on) used text commands to do all its functions. For example, 123/1 will turn a signal ID 123 Green and 123/2 will turn back to Red. There are similar text commands for starting and stopping trains, changing track points and anything else that the system does. You'll see this in action in the everso exciting video attached to this blog.
It just so happens that the Big Bear incorporates an Internet interface that allows external control by sending commands from a remote application. So, rather than make big modifications to the software itself we'll create a simple program that forwards messages from the IoT hub then onwards to the Big Bear as these text commands. This program can also be used as a simple test harness to send commands locally and to monitor messages on their way. Here comes a diagram that shows the route of a message, leaving Alexa on platform 13 and 3 quarters!:
It's important to note that here all the commands are one way. It is entirely possible to have messages sent back from the railway to Alexa so you could ask such questions as 'where is the electric train'. However, for the sake of this demo, we are just concerned with commands from Alexa, besides which, I do not have feedback (train positioning) set up on my model layout because ... it's expensive, and I don't have a magic money tree.
The Test Harness
A windows program acts as the receiver and forwards messages from IoT to Big Bear via TCP (Internet) as command strings that Big Bear understands. Conceivably if you were using some other software, and that software allowed an external input, the test harness could send commands to it, rather than Big Bear. I had to say because I don't want to go to prison for abusing my position of market domination (I wish).
If this were a commercial system, I would package the above program as a Windows service, so that it ran quietly in the background checking for new messages and passing them on to Big Bear. As a Windows application, however, we can give it a nice control panel with the benefit of a panel displaying messages to let us see what's happening. Furthermore, we can add some buttons to send commands to Big Bear directly and even better, to send messages to the IoT hub so as to test that the systems work from the point of view of Azure. This would simulate messages sent from Alexa and verifies the down-link part of the architecture.
Below is a picture of the control panel and, at the end of this blog, a video showing it used to try out messages sent via Azure IoT to switch the lights of a train on and off then to send a train on it's merry way.
One for rail enthusiasts ... can you see the port number I have used!
So there we are for this episode, now we have the ability to send commands from an Azure Hub and see them propagate back to a program that sends them onwards to Big Bear where things happen on the railway in the real-world. For this simple test, that involves switching the lights of a train on and off and making it go. In the next article things get exciting as we move on a notch and create an Alexa skill to perform some basic operations.
At the start I said this could be done by someone across the other side of the world. If anyone reading this is outside the UK, ideally NZ or Australia or somewhere far far away that owns an Alexa, please get in touch so it would be great to get things set up for a long distance model railway control!
