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.
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.
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.
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.
Every year, my church has a “night of worship”, a worship service in the heart of the city at an outdoor stage, where we sing songs for a couple of hours. Because it doesn’t get dark enough to use projectors for lyrics until the service is almost over, in the past we have relied on using small flat screen TVs to try to show some words for people to follow along. Big white letters on a black background, nothing fancy. Of course, it’d be great if we could just rent an LED video wall, but the cost to do that has been too expensive for us to do in the past.
You can see the screens we rented here. Pretty small (60″) for such a large crowd.
So, I had an idea: What if we could somehow send the lyrics out of ProPresenter to everyone’s phones, in real time, and let them use their own screens to follow along?
I gave myself a couple of limitations:
It needed to work in the standard phone browser so there was no barrier of installing a particular app
It needed to be real time or as close to it as possible
Awhile back, I started tinkering around with the undocumented ProPresenter API. I say undocumented because it is not officially offered as a way to access ProPresenter data and control it. Some people have done a great job at figuring out how ProPresenter sends data over the network between their apps which allows us to extend the software to meet unique needs. Basically, by using websockets, we can interact with ProPresenter which will return JSON-formatted data reflecting information about songs in the library, playlist, the index of the current song, the current slide and next slide information, etc.
I created a local Node.js project and in just a few hours, I had something ready to alpha test! My approach was to have a web browser open on the local network that could poll and listen to changes from ProPresenter, and then relay that new data to a web server. That web server would then relay those changes to all of the connected clients, much like a chat server would send a message to everyone.
I showed it to my team, but the idea was tabled for awhile because we thought it through and didn’t want people buried in their phones while singing. However, as we got closer to the event, we realized that the two TV screens we rented might not be sufficient, and I was asked to work on this again.
As I was preparing this for production, I discussed briefly with our IT team about setting up an internal server running Node.js that could be accessed on port 80 (the default HTTP port) outside the firewall, but bandwidth, security and performance for hundreds of clients connecting through the Internet all at the same time was a concern. With that in mind, I turned to Amazon EC2.
If you haven’t heard of it, Amazon Elastic Cloud Computing (EC2) is basically virtual servers “in the cloud” (i.e. remotely and accessible from the internet). It’s not too hard to set up, and they even have a free tier available for 12 months, so you can try it out for free! I had never used it before this project, so I actually followed a tutorial to help me get it going.
This is my EC2 instance. It’s running Ubuntu linux.
Once I had my Linux server set up on Amazon EC2, I assigned an “Elastic IP” (Amazon’s term for a type of static IP), and then I bought a domain name, fglyrics.com, for $12 and tied it to that IP. It was up and online in minutes. I installed Node.js on my new server, copied over my code, and started it running.
About the software:
I call the software Presentation Bridge, because it acts as a “bridge” or connector between the presentation software and all of the clients.
The initial Bridge page.
When you first load the Bridge page, you have two options: Configuring your ProPresenter connection, and Connecting to a Bridge. In order to connect to ProPresenter, you have to enable the network settings. It relies on both the “remote” and “stage display” controls to get all of the data needed.
You need to enable the network, ProPresenter Remote, and Stage Display App. Be sure to assign a control password. The Network Port is the port we will use in Presentation Bridge. The Stage Display App port is not needed.
When connecting to ProPresenter in Presentation Bridge, you’ll need to supply the local ProPresenter IP address and port, as well as the control password and local library path. This is what allows the Bridge to pull all of the slide images and other information. This is standardized across all of our ProPresenter installs at our church, so it’s always the same path for us. It should be the full, absolute path from the root of your drive.
When you’ve successfully connected, the gray dot at the top of the ProPresenter config box will turn green. If there’s an error, it will turn red. Status information is displayed in a log area further down the screen.
To connect to a bridge, choose one from the dropdown list. If it is configured to have a control password, you’ll have to enter that in order to connect. Adding bridges and making changes to existing bridges can be managed by clicking the settings wheel. It supports multiple bridges, which I added as a feature since we have multiple auditoriums and may want to use more than one simultaneously.
This is what the page can look like when connected to both ProPresenter and to a Bridge room.
As the operator runs ProPresenter, the slides will be displayed on the Bridge screen with the currently selected slide showing a blinking red border, so it is clear which slide is currently being displayed. You can browse the playlists and items in the playlist. You have the option to send the current data from ProPresenter to the server (or turn it off), turn on a logo (configured in Bridge settings, useful if you’re currently not connected to ProPresenter, etc.). I also implemented the NoSleep.js library which will attempt to keep any connected mobile devices awake.
On the viewer/client side, I implemented three types of “listeners”:
Text Listener – just gets text data and displays it as big as possible on the screen
Image Listener – displays the actual slide image by using a base64 encoding of the slide
Stage Display – recreates the current slide/next slide layout
This is the default “text listener” option, and what we used for our night of worship.This is the image listener. It uses a base64 encoded image pulled from ProPresenter at the time it connects. The quality is based on the slider value set in the config options for the ProPresenter connection. It does not include any background or other layers.This is the stage display, with the current slide and the next slide, and any notes attached.
All three listeners can be accessed through the browser. The data is relayed from the server using the socket.io library. I tested it on my iOS devices, Android devices, and even my Amazon Fire TV stick on multiple browsers and they all work really well. Across an internet connection, the moment a slide is clicked in ProPresenter, that slide is visible on the listener devices.
We used it during our Night of Worship this year and it worked great! I used a hotspot for the Bridge connection and then everyone connected to the Text Listener using the internet connection on their own phones. It uses very little data since it is just a text stream, which is really nice!
Overall, I enjoyed creating this software for our unique need. I plan to extend the functionality down the road as I have time, including attaching “triggers” to specific slides as they are activated, to send RossTalk messages, fire HTTP cues, etc. on the local production network.
If you’d like to try Presentation Bridge out for yourself, the code is freely available on my Github repository. You can also request to demo it using my live site running on Amazon EC2. I wrote the software to support multiple bridges at a time, in case you have multiple meeting spaces or venues that need to run simultaneously. When more than one Bridge is enabled and running, any users that connect are presented with a drop-down list and can select the Bridge they want to join.
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.
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.
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:
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.
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.
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.
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.
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.
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?
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.
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.
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.
I spent some time this past week writing and testing support for ProTally with Blackmagic ATEM switchers. I didn’t have one to develop with, and after posting on a discussion group about the software, a new friend sent me a unit to work on. Thanks again, Kyle!
Version 1.2.0 now supports:
Blackmagic ATEM switchers – it will auto discover any ATEM switchers on the network, or you can manually type in an IP Address as well
Ross Carbonite Black, Carbonite Black Solo, and Graphite switchers
And I now have a Windows release build in addition to a MacOS release build!
Awhile back, I wrote about the on-screen tally software I recently developed. We needed a way for our CG operators to know when their source was on-air or about to be on-air. I won’t rehash the definitions or inner-workings again, so if you didn’t read that first post, I recommend you read that before this.
I had hoped to give a release build much sooner but lost time waiting on some other people to test it in their environments. We’ve been running it in our environments for almost 2 months now with no issues, so I finally gave it some final polishing and bug squashing to get it ready for release. The interface has changed some, and for now, you can choose between a generic TSL 3.1 device or, specifically, a Ross Carbonite. (Not a Carbonite Black, Solo, or any of the other models.) Why specifically that model? Because I have two of them, and that’s what I know and use!
Here is an example of it being used with ProPresenter as a border box.Here is an example of the filled-in box version, as some people may prefer that instead.Here is what it could look like in ProVideoServer.
I hope to add support for the Blackmagic ATEM protocol soon. I need to connect with someone who has one, so if that’s you and you’re interested in testing with me, drop me a line!
If you’d like to download either the source code or a release build for the Mac platform, I’ve made both available on my Github repository here:https://github.com/josephdadams/ProTally/
And this should go without saying, but even though I’ve made software to augment your use of software like Renewed Vision’s ProPresenter and other products, it is in no way associated with any company or product. This is distributed under the MIT license and is available for anyone to use without cost.
We recently purchased some TP-Link HS100 Kasa Smart Wi-Fi Plugs to allow us to remotely turn on speaker amps to support our outdoor speaker systems. Turning the amps on each time by going to the physical amp location in the racks located all across the campus was very inconvenient, so this was a great upgrade.
This is what the plug looks like.
It pairs with an app called Kasa to allow you to turn the outlets on and off pretty easily, however in our testing, we couldn’t get it to work with more than one smartphone. Plus, we didn’t want volunteers to have to install this app on their phone, or provide a phone just to run this app.
The TP-Link protocol has been reverse engineered pretty well, so I had hopes that this would be a quick and easy project, and it was! The core protocol uses JSON to communicate, however it is obfuscated heavily to the user and you have to send a hexadecimal payload to it in the end in order to trigger an action.
Once we set up the devices as recommended through the app to use our internal network WiFi, I had our IT department create IP address reservations based on the MAC addresses of the outlets, so that they would always have the same IP address. If you use these plugs, I recommend doing that in your setup as well.
Then, I researched the protocol and figured out what the hexadecimal payloads needed to be to power it on and off. I didn’t really care about any of the other status settings. Just a simple on and off.
Here is the function needed to do that, written in ogScript for Ross Dashboard:
function tellOutlet(address, port, protocol, command)
{
var enabled = ogscript.getObject('outletEnabled');
if (enabled)
{
switch(protocol)
{
case "TPLINK-HS100":
var payload_on_hex = "0000002AD0F281F88BFF9AF7D5EF94B6C5A0D48BF99CF091E8B7C4B0D1A5C0E2D8A381F286E793F6D4EEDFA2DFA2";
var payload_off_hex = "0000002AD0F281F88BFF9AF7D5EF94B6C5A0D48BF99CF091E8B7C4B0D1A5C0E2D8A381F286E793F6D4EEDEA3DEA3";
var sendCommand = "";
if (command == "on")
{
sendCommand = payload_on_hex;
}
else if (command == "off")
{
sendCommand = payload_off_hex;
}
rosstalk.sendAsBytes(address, port, sendCommand, callback);
ogscript.debug("Outlet turned " + command + ".");
break;
default:
break;
}
}
}
The key function here is the RossTalk SendAsBytes command which sends the TCP message as hexadecimal data.
Once I did a test and was satisfied it was working properly, I built out custom panels that use our master production control system, so now volunteers can easily turn the amps on or off by just clicking a button!
I also built a stand-alone version in case anyone else could benefit from it.
The buttons are first disabled when you open the panel until you’ve configured the outlet in the setup tab.In the setup tab, you can configure the outlet IP address, the port (the default is 9999), and choose the protocol. Currently, the panel only supports the TP-Link HS100/101 models.Just click On or Off to toggle the outlet!
The panel is up on my Github repository, if you’d like to download it.
