Switchboard: Distributed Automation made Easy

Skip the first video and go straight to this one: a quick dive into the anatomy of a Switchboard Module together with a demonstration!

After focusing mostly on fun features for the last few weeks I sat down and did some of the less exciting stuff.

We finally have a 'remove' command which can be used to remove clients or modules.

It is now possible to give clients (but not yet client apps) a poll period in case this particular client doesn't need to be updated all that often, e.g., a room temperature sensor does not need to be read every second.

The updateclient command can be used to change the client poll period at runtime.

Client/device/module statuses are now printed (in colour!) when running the 'list' command.

Significantly improved reliability and error reporting.

If you fancy trying Switchboard out yourself I would be very grateful for any bug reports, crash reports, general feedback or suggestions!

Going over the basics...

InfluxDB (https://www.influxdata.com/) is a time-series database perfectly suited for the storage of sensor values, and because it provides a Python client library I was able to write an IOData agent app. I'm very keen on InfluxDB because it is natively supported by Grafana (https://grafana.com/), a beautiful, flexible data visualisation suite. After installing InfluxDB and Grafana and launching the swb_influxdb_save app all the Switchboard device values are automatically stored. When creating the following dashboard I was able to select the devices I wanted to plot from a drop-down menu:

As usual, a rough guide on how to setup this app can be found in the repo in the apps/swb_influxdb_save/README.md file.

Apps are standalone executables that can be configured, launched and terminated by Switchboard. The only requirement for an app is that it support a "--getconf" argument which prints to stdout a JSON representation of the app input arguments. For example, for the swb_system_info app, "--getconf" would return the following:

{"Client port": {"args": ["--client_port", "-cp"], "kwargs": {"help": "Switchboard client listening port"}}}

This allows Switchboard to know that this app has a "--client_port" argument. Switchboard knows what to do with this specific argument and silently populates it with an unused port number. This is followed by a silent "addclient" command so all the swb_system_info inputs are immediately available.

To make it easier to develop python Switchboard apps there are three classes to help you out: ClientApp (as per last log entry), IODataApp which gets a stream of all device value data, and ClientIODataApp in case you need both sets of functionality. All the app arguments are saved in the Switchboard config so that apps can automatically be launched at startup. Switchboard currently comes with a few apps out of the box, which are swb_system_info, swb_dashboard, swb_io_file_save, and... swb_tradfri!

IKEA Tradfri are cheap wireless lightbulbs for which you can control on/off, brightness and colour temperature (for the more expensive models). To get the lightblubs working you need at least one Tradfri LED bulb, one steering device and one network gateway, and you need to set them up through the IKEA Tradfri app. Install the coap-client (instructions in apps/swb_tradfri/README.md) on your Linux machine and you're ready to go:

Enter the gateway IP, the security code and a client alias and voilà! The app automatically detects all the connected devices and creates outputs to control them: we can power on/off and dim a group of bulbs with the group_<group id>_<action>.o outputs, and control each bulb individually with the bulb_<group id>_<bulb id>_<action>.o outputs. So to turn on a bulb, you only need to type:

set tradfri.bulb_0_0_power 1

Writing a Switchboard client has gotten even easier. The ClientApp class takes care of parsing application arguments and starting the server. "--client_port" is now a mandatory argument, and specifies the port on which the client is listening. As an example, it is now possible to create a client that publishes CPU and memory usage, all within 15 lines:

#!/usr/bin/env python
import psutil
from client_app import ClientApp
from switchboard_client.client import SwitchboardInputDevice

def main():
    app = ClientApp()
    app.add_device(SwitchboardInputDevice('cpu_usage.i', lambda: psutil.cpu_percent()))
    app.add_device(SwitchboardInputDevice('memory_usage.i', lambda: psutil.virtual_memory().percent))
    app.run()

if __name__ == "__main__":
    main()

The latest code changes include a swbc_system_info app very similar to the example. It becomes available as a terminal application after installing Switchboard. To run it type

swb_system_info --client_port <port_number>

localhost:<port_number>/devices_info

This displays the devices that are available from this Switchboard client. To get the values have a look at:

localhost:<port_number>/devices_value

The best thing about ClientApps is that it provides all clients with common functionality we'll be exploiting very shortly!

IoT is not only about controlling but also about measuring. Since Switchboard provides a means to connect many devices in a centralised manner, it would be a shame not to provide some interface through which we can collect the device data and do things with it, such as storing it or displaying it.

To this end I have just added a component to Switchboard called IOData. At every polling cycle IOData receives an update of all the device states. IOData then proceeds to determine what the value differences are between the current and the previous cycles and encodes those differences as an array of updates.

This is where IOData Agents come in. An agent is an app that subscribes to the IOData update stream. What it does with this data is entirely up to the agent. Switchboard currently comes with two agents out of the box:

• IOFileSave: stores the list of updates in a file. Can be configured to only store a maximum number of updates, deleting the oldest entries if we reach this number
• Dashboard: an HTML dashboard that uses websockets to always display the latest device value data:

To launch the Dashboard agent enter the following command:

launchapp swb_dashboard

I managed to fix a bunch of bugs to do with functionality I hadn't run in a while, and have also added a simple example showing the absolute minimum required to get a Switchboard setup working. The example files consist of an input client, an output client, a test module that simply multiplies the input, and a settings file so that everything is ready to go.

The one things missing here is a list of commands (which I shall be adding to the readme shortly), but the command line interface comes with '-help' functionality and tab-completion and is rather simple.

Next steps:

• creating a functional HTML dashboard
• creating a video of the whole thing in action
• adding features and unit tests

I finally got round to uploading the source files to Github. I ran the Switchboard application using python3 on a Linux machine and everything worked as expected. Not fully tested at this stage, so I wouldn't be surprised if some of the more fancy features (e.g., on-the-fly module update) would cause the application to crash.

So far we have the main repository https://github.com/josefschneider/switchboard which contains the framework complete with command line interface, and a switchboard client module to easily instantiate switchboard hosts.

The https://github.com/josefschneider/esp8266switchboardclient repository contains a C++ library that turns an ESP8266 into a Switchboard client using the ESP8266WebServer and ArduinoJson libraries.

Next steps:

• adding example code to the repository
• adding a short tutorial to the readme files
• creating a video of the whole thing in action
• adding features and unit tests