Using a Stream Deck as a Production Controller, Revisited

One of my first posts on this blog detailed how I wrote software in Node.js to interface with an Elgato Stream Deck to control some of our production equipment, interfacing with the video switchers, router, Ross Dashboard, etc. It’s time to revisit that.

We’ve been using my controller now every week in our control rooms and tech booths for about a year. My team loves it. It integrates into our centralized production workflow, where each deck sends commands to a central Dashboard panel, which runs the command, and then sends out updates to all the connected stream decks.

However, I haven’t had much time to make it a better product for other people. I wrote support for the Stream Deck Mini when that was released, but that’s about it. I haven’t had time or cause to do much else with it. So, for that reason, I wanted to share with you a piece of software that is under constant, active development: Bitfocus Companion.

Screen Shot 2019-02-15 at 10.43.46 AM

 

Companion is written in Node.js and packaged in Electron just like my product, so it can run on Mac, Windows, or Linux. But it can do so much more than my controller! One of the best features is that it has a web-based management interface, so you can add actions to buttons easily and on-the-fly. It supports a ton of production equipment and chances are good that your gear is already on the supported list, or, perhaps someone can create a module for it.

I was asked to join the development team recently for Companion, so I’ve started making some modules for Companion to integrate with software and gear that we have. I’ve created a module for Interactive Technologies’ CueServer, which we have in a couple of our venues here.

Screen Shot 2019-02-15 at 10.54.05 AM
Here are some actions you can perform on a CueServer now with the module I created for Companion.
Screen Shot 2019-02-15 at 10.53.53 AM
An example of a key down action for triggering a CueServer macro in Companion.

If you use ProTally, my on-screen tally box notification software, and want to integrate with Companion, I made a module for that too! Make sure to go download the latest ProTally release which supports this feature! With Companion, in addition to Preview and Program windows, you can also send a Beacon, which flashes at a custom rate and color. Check this video out for a demo:

Both of these modules are available in the bleeding edge builds of Companion and will be included in the next stable release soon.

So, if you’re looking for a great production controller that integrates with the Stream Deck, go check out Companion! It’s only going to get better from here!

 

Using Node.js and a Raspberry Pi to monitor Streaming ACN network for DMX changes and trigger actions

Awhile back, I wrote about the Shade Controller I created using Node.js and a USB relay running on a Raspberry Pi Zero. It works great. We can raise and lower the shade from anywhere on the network. However, I’ve always wanted a way to control this a little more automatically. The lighting volunteer is typically the person who operates the remote for the shade, so I really wanted a way to automate that part of the process for them so the shade can raise and lower exactly when we want it to, without them having to use an extra tool or device.

As I was working on some networking changes to one of our lighting consoles (we use Jands L5 consoles running Chroma-Q’s Vista 3), I had an idea… What if we could monitor the Streaming ACN lighting network for data changes just like any lighting node, and use that to trigger an action?

If you’ve not heard of Streaming ACN (sometimes called sACN or its official name E 1.31), it is an ethernet based protocol for sending DMX address and value information from a lighting console to receiver nodes which then relay the DMX information to lighting fixtures. It uses multicast traffic to send the information so it is very fast and efficient. At my church, we have several DMX universes of lighting information going over the network for each auditorium, controlling all of the light fixtures.

Luckily for me, a base protocol module for E 1.31 was already available for Node.js. So, using that module, I sat down and prototyped a solution and had something working in just a couple of hours. I’m calling my software sACN Translator. I’ve deployed it to a Raspberry Pi for production. It supports a simple REST API to allow you to control which universes it should listen to, as well as the fixtures to run triggers for. I also created a simple web interface which utilizes this API.

Screen Shot 2019-01-20 at 10.28.46 AM.png
Here is the simple web interface which interacts with the REST API.

Here is how I set it up on our system to trigger the shade controller. I started by adding two fixtures to the L5 console on Universe 1 (where I happened to have some spare room in my DMX addresses). I called these fixtures “Shades Up” and “Shades Down”, with DMX Addresses 511 and 512.

screen sharing picture january 20, 2019 at 5.34.39 am est
Here are the two “fixtures” on the layout, with notes attached.
screen sharing picture january 20, 2019 at 5.35.29 am est
I labeled the fixtures as generic “utility” fixtures with 1 DMX address each.

Then, I added entries in sACN Translator to monitor Universe 1 on the network and look for value changes to fixture addresses 511 and 512. I set it to run an HTTP trigger any time the values reaches 255 (100%). So, when I put the Shades Down fixture at 100% on the lighting console, the software sees that value, looks for a match in its list of fixtures, and then runs the corresponding HTTP request on the Raspberry Pi Zero connected to the USB relay to trigger the action which lowers the shade.

Here is a video of it in action:

Pretty cool! I decided to use separate fixture addresses for each trigger action, but I didn’t have to. I could have just one fixture and watch for two separate lighting values.

So now, all the operator has to do is run the cues like normal, and the programming will do the rest! I’ve made this software available for free on my Github repository. Let me know how it works for you!

Using Google Apps Script with user input to automate repetitive tasks in Google Docs

Do you find yourself ever doing repetitive tasks over and over again in Google Docs? (Or any of the Google Suite Apps?) I sure do. At my church, we create a Google Doc every week for all of the “talking points”, the parts of the service that aren’t song or sermon, where we script out what someone needs to say or communicate during that portion.

screen shot 2019-01-13 at 5.48.00 am
Here is a sample document that we use each week.

A couple years ago, I started creating template files to help my team do this every week, because having the template already there with some common headers, the service date, etc. removed the barrier to get down to writing the actual words. Creating the files wasn’t too complicated, and after awhile, I started making them “in bulk”, where I would sit down and just make 3-4 months worth of documents at a time, making copies of my master template, editing the new file and updating the date, etc. Then we added a second auditorium, which doubled the amount of documents I needed to create.

With the new year, it was time to create more documents, so I decided this time around that I would create a script to help automate this task using the framework within Google Apps Script.

If you’ve not heard of or used Google Apps Script (GAS), it’s a scripting language based on Javascript, for light-weight application development. All of the code runs on Google’s servers to interact with your documents. If you’ve ever used an “add-on” in Google Apps, it’s using this scripting framework.

It’s pretty easy to use if you know Javascript, and it’s easy to get started. From any document, just go to Tools > Script Editor. This opens a new tab where you can start writing Apps Script.

Here is my script:


function myFunction()
{
var ui = DocumentApp.getUi();

var templateDocId = '[templateid]'; // put the document ID of the master template file here

var prompt_numberOfDocs = ui.prompt('How many Talking Point Documents do you want to create?');
var prompt_startingDate = ui.prompt('What is the starting date? Please enter in MM/dd/yyyy.');

var numberOfDocs = parseInt(prompt_numberOfDocs.getResponseText());
var startingDate = prompt_startingDate.getResponseText();

var prompt_venueResponse = ui.prompt('Venue', 'Create Documents for both Auditoriums? If no, please type in the Venue Title and click "No".', ui.ButtonSet.YES_NO);

var venueTitle = '';

var bothAuditoriums = true;

if (prompt_venueResponse.getSelectedButton() == ui.Button.NO)
{
venueTitle = prompt_venueResponse.getResponseText();
bothAuditoriums = false;
}

var date = new Date(startingDate);

var htmlOutput = HtmlService
.createHtmlOutput('Creating ' + numberOfDocs + ' documents. Please stand by...

')
.setWidth(300)
.setHeight(100);

ui.showModalDialog(htmlOutput, 'Talking Points - Task Running');

for (var i = 0; i < numberOfDocs; i++)
{
var loopDate = new Date(date.getTime()+ ((i * 7) * 3600000 * 24)); // uses the looping interval to get the starting date and add 7 days to it, creating a new date object
var documentName = 'Talking Points - ' + Utilities.formatDate(loopDate, Session.getScriptTimeZone(), "MMMM dd, yyyy");
var documentDate = Utilities.formatDate(loopDate, Session.getScriptTimeZone(), "MM/dd/yyyy");
if (bothAuditoriums)
{
createNewTalkingPointDocument(templateDocId, documentName + ' (Aud 1)', 'Aud 1', documentDate);
createNewTalkingPointDocument(templateDocId, documentName + ' (Aud 2)', 'Aud 2', documentDate);
}
else
{
documentName += ' (' + venueTitle + ')';
createNewTalkingPointDocument(templateDocId, documentName, venueTitle, documentDate);
}
}

htmlOutput = HtmlService
.createHtmlOutput('google.script.host.close();')
.setWidth(300)
.setHeight(100);
ui.showModalDialog(htmlOutput, 'Talking Points - Task Running');
}

function createNewTalkingPointDocument(templateDocumentId, documentName, venueTitle, documentDate)
{
//Make a copy of the template file
var documentId = DriveApp.getFileById(templateDocumentId).makeCopy().getId();

//Rename the copied file
DriveApp.getFileById(documentId).setName(documentName);

//Get the document body as a variable
var body = DocumentApp.openById(documentId).getBody();

//Insert the entries into the document
body.replaceText('##Venue##', venueTitle);
body.replaceText('##Date##', documentDate);
}

Once you have a script in place, you can choose triggers for when it should run, like when it is opened, or on a schedule, etc.

Here is the new template with the script in action:

screen shot 2019-01-13 at 6.10.10 am

First, I ask how many documents should be created. 1, 5, 500, whatever I need.

screen shot 2019-01-13 at 6.10.29 am

Next, I ask for the starting date. We specifically use these for Sunday services, so I’ve programmed the script to take this starting date and then calculate every 7 days when creating multiple documents.

screen shot 2019-01-13 at 6.10.44 am

Then, I ask the user if they want to create documents for both auditoriums, or if this is for a special service or off-site service, etc. Typically we want them for both auditoriums, but the one-off feature makes things easy for those types of services too.

screen shot 2019-01-13 at 6.10.57 am

As the script runs, it displays this dialog box. Creating that many documents can take awhile, and I wanted the user to be aware of this. The box goes away automatically when the process is completed.

Now that we have this, I can pass the task on to anyone on our team, anytime they need these documents! And it saves a good bit of time. I definitely spent less time creating this script than I would have spent creating the 3-4 months worth of documents manually, and now I never have to do that again!

How can you use Google Apps Script to automate some of your more repetitive tasks?

Server-based countdown clocks with multiple client viewers using Node.js and a Raspberry Pi

A few months back, I shared about the client-side countdown clock script that I created for our team to use. It worked pretty well for its purposes, using Dropbox as the platform to share and update data between the computer creating the clocks and the computer viewing the clocks. The initial goal was to create something that required no backend server and would be easy to run on any computer.

It served us well but we quickly outgrew it with the desire to be able to publish clocks in realtime, not simply relying on the viewer client to refresh itself every 15 seconds to look for new data. So, I created a server based solution using Node.js.

I decided I wanted to run this project on a Raspberry Pi 3 B+, so I picked up this kit on Amazon. I wanted an easy way to spin up a web server that wasn’t tied to any production machine, and this does a great job.

img_7113
Here is the Raspberry Pi 3 B+, neatly installed in one of the video racks. I’m using the HDMI output and converting it to SDI to go into our video system.

Dubbed TimeKeeper, this project runs an Express web server within Node and has a REST API, which allows the user to poll for existing data as well as create new entries. As new entries are added, they are sent out to all connected clients in real time using the socket.io library.

Screen Shot 2018-11-29 at 2.08.23 PM
Here is a screenshot of a web browser client. This is actually running on the same Raspberry Pi that is hosting the Node.js server, with Chromium in kiosk mode.

Rooms:
Rooms allow you to control and specify which timers appear. This is helpful if you are running clocks in multiple venues or instances, and only want certain timers to appear on certain viewer screens.

Timers:
Timers are the objects that TimeKeeper will count down to, based on the viewer’s current local system time.

Messages:
Messages can be sent and displayed on viewer clients.

After implementing the API, I created a Dashboard custom panel to interact with the server. This serves as the primary interface for our volunteers. Because the panel fetches new data from the server on a recurring schedule, multiple computers can have the panel open and all stay in sync about what timer and message objects are currently being displayed.

Screen Shot 2018-11-29 at 2.09.55 PM
Screenshot of the custom panel in Dashboard.

We’ve been using this software for a few months now and it’s working great! I intended to write about it sooner, but with a busy work and family life, finding time to write for this blog can be a challenge!

The next version will support trigger actions when clocks hit a specified time or run out. I also plan to integrate with other clock systems to show time left on video playbacks, Planning Center Online, etc., when I have the time!

If this is useful or helpful to you, I’ve made it available on my Github repository.

Network control of window shades using relays, a Raspberry Pi Zero, and Node JS

At my church, we have a smaller auditorium that has a giant window to let in natural light. We don’t use it much during services because the light can wash out our projection screens, but it’s wonderful to have during the week to let in light. We also like to have it open before services begin and close it right as we get started. It helps to create a nice environment.

Photo Oct 03, 5 08 02 PM.jpg
These are the two big windows. Each one has a motorized shade attached.

These shades came with a very easy to use RF remote. Actually, it came with two remotes. Since we never need or use two, I thought, wouldn’t it be cool to hack one of them and turn it into a network-controlled remote? This would allow us to control the shades from anywhere, not just within the RF range! Plus, I like automation and making things more accessible and efficient and I wanted to try to create something inexpensive rather than just purchasing something already made.

somfy remote
This is the remote we have. We have two shades that we usually open simultaneously, so we have two remotes but don’t need both.

I purchased this USB relay off Amazon:

usbrelay
These relays are pretty cheap and available on a lot of sites. I paid about $12 for one off Amazon. They can work with both low and high voltages.

I figured I could use the relays to electrically “click” the buttons on the remote. So I took the remote apart to see how it looked on the inside. Here is a picture of the remote outside of its shell.

Photo Sep 20, 11 35 45 AM
The first and third buttons are the “up” and “down” controls. The middle button is the “preset level” where the shade can open or close to a preset level, but we don’t use this feature. The very bottom button determines which shade(s) to control.

I knew there was probably a way to use the GPIO pins of a Raspberry Pi and transistors to trigger the button presses, but that’s not my forte. I don’t know a lot about circuity and electronics at that level, but I know how to solder (well, sort of. Don’t look too closely at my work.) So I soldered some wires onto the remote buttons.

Photo Sep 24, 3 52 18 PM

When I touched the wires together, the remote activated! The concept worked, so I hooked it up to the relay to begin the development and testing.

Photo Oct 02, 1 00 27 PM.jpg
Here is the remote, connected to the relay via the NO (normally open) pins.  I bought a small electronics project box to fit all the parts in.

I knew I wanted to control the remote using Node JS. It’s a great lightweight platform that runs on multiple operating systems, including Raspberry Pi’s with Linux. I found control software written in C, C++, Python, shell scripts, etc. for the USB Relay that I had bought, but nothing in Node JS. At least, nothing native without using DLLs and that sort of thing.

It’s been a long time since I wrote in C++ and I’ve never used Python, but I can read both languages enough to learn about the control protocol. I wanted to keep mine running with the least amount of dependencies so it could work on multiple operating systems (not just on the Raspberry Pi, for example).

In about an hour, using the Node-HID library, I had a working script in Node JS to turn my 2-relay device on and off. I decided to make the control code for the relay into a separate Node JS module so that it can be used in other projects. If you want to use it, I’ve made it available on Github as well as published it in the NPM registry.

Once I had the control of the relay that I needed, I whipped up a quick Node JS project running express to host a simple web server that would accept a “shades up” and a “shades down” HTTP request and then trigger the appropriate relay.

const USBRelay = require("./USBRelay.js");
const relay = new USBRelay();

//express API variables
const express = require('express');
const app = express();

//http server variables
const http = require('http').Server(app);
const listenPort = 4400;

//routes

app.get("/shades_up", function (req, res) {
   ShadesUp();
   res.send({returnStatus: "shades-up"});
});

app.get("/shades_down", function (req, res) {
   ShadesDown();
   res.send({returnStatus: "shades-down"});
});

http.listen(listenPort, function () {
    console.log("listening on *:" + listenPort);
});

function ShadesUp()
{
    relay.setState(1, true);

    setTimeout(function () {
        relay.setState(1, false);
    }, 1000);
}

function ShadesDown()
{
    relay.setState(2, true);

    setTimeout(function () {
        relay.setState(2, false);
    }, 1000);
}

And by making an HTTP request like:

http://ipaddress:4400/shades_up

 

I can trigger Relay 1 on my device to turn on for one second, and then turn off, simulating the button press.

Because we use Ross Dashboard as our go-to production interface, I added Up/Down buttons to our FOH custom panels to send those commands to the relay server.

Screen Shot 2018-10-03 at 6.48.16 PM
Even though the remote is easy to use, this works from anywhere on our network!

I then deployed the ShadeController Node JS project to a Raspberry Pi Zero, and put all the parts into my project box. I had our IT department make a DHCP reservation for the Pi so that it would always have the same IP address, making it easier to program around.

Photo Oct 02, 3 24 42 PM
Here is the remote, the USB relay (hot glued to the bottom of the box), and the Pi Zero all in the project box.

So, what does this really gain us, if the remote was already pretty easy to use?

  1. We are no longer limited to RF range of the remote to control the shades. We can control it from anywhere on the network, including our control rooms which are located far away from the receiving end of the RF controller for the shades.
  2. We can use the URLs in the ShadeController program as hooks in other projects to control the shades through automation. Time for the service to start? Just run the appropriate light cue on the light board and it fires a network midi command to a server that then relays the HTTP request needed.

Overall, this was a fairly inexpensive project.

I ended up spending a little bit more because I bought a Raspberry Pi Zero W kit with a case and some other adapters that I didn’t already have, like a mini HDMI to HDMI connector, but if I end up buying another Zero, I’ll take the Pi case out of this project box and use it. I also bought a pack of project boxes for about $8 that were way too small and didn’t fit my parts, but I plan to use them for some other projects down the road.

I hope this gives you some ideas on ways you could automate or more efficiently control your non-networked equipment through the use of relays! I certainly learned a lot during this process and am looking forward to implementing it in other areas.

ProTally 1.3.0 available with support for OBS Studio

If you’ve been looking for ProTally support for OBS Studio, here it is!

On your computer running OBS, you’ll need to download and configure the OBS Websockets to be able to connect.

Screen Shot 2018-09-19 at 4.07.51 PM

Tally address fields are based on sources available in your OBS scenes.

Download the latest release here: https://github.com/josephdadams/ProTally/releases/tag/v1.3.0

I hope this is helpful to you!