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!

ProTally 1.2.0 with Blackmagic ATEM support available

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!

Screen Shot 2018-09-15 at 12.12.47 AM

Screen Shot 2018-09-15 at 12.13.51 AMScreen Shot 2018-09-15 at 12.13.11 AM

Screen Shot 2018-09-15 at 12.14.08 AM
It now supports more device types!

You can download the binaries for free here: https://github.com/josephdadams/ProTally/releases/tag/v1.2.0

If the software is beneficial to you, drop me a line and let me know!

Using Dropbox to keep ProPresenter Libraries in sync

Dropbox is an excellent tool for production use. We use it for everything, from weekly temporary files just for a particular weekend service, to long term resources that need to be available on a regular basis. It’s great because the files automatically sync to all the devices, and it allows us to collaborate with a lot of people/contributors. The files are stored locally on each device/computer, so they are quickly accessible.

We also like syncing our ProPresenter Libraries in Dropbox, and I thought I would share that method with you. If you haven’t heard of ProPresenter, it is an media presentation software package from a company called Renewed Vision that is designed specifically to make live production easier. In my opinion, it’s the best lyric presenting software out there.

ProPresenter maintains its own internal library/folder system of all of your presentations (songs), background videos, images, etc. This allows you to easily search and re-use songs week to week. The software auto-saves changes when you make them, which is great.

Screen Shot 2018-09-06 at 3.10.53 PM

But what do you do when you have multiple ProPresenter computers in multiple venues and rooms across the campus or ministry? This is where a syncing method comes in very handy.

ProPresenter has two built in options for sync, “local sync” and “cloud sync”. The local sync option is free and you can set it up yourself to sync to a local drive or network share. The cloud sync option uses Renewed Vision servers and costs a small monthly fee.

However, we don’t use either of these options. I tried the local sync option and never got it to reliably work like I expected, and the cloud sync was not something we were interested in paying for at the time.

We use Dropbox instead. We have a shared Dropbox account logged into all production devices. Each computer using ProPresenter is set up with its own library folder in the Dropbox account. This allows that computer to make all the changes it needs while those library files are in use.

screen-shot-2018-09-06-at-3-04-24-pm.png

As changes are made, they are automatically synced to Dropbox and back down to the other devices, into that same folder name/structure. Essentially, every computer has a full backup of all the other computers’ ProPresenter libraries, accurate to within the last time it synced, typically within a couple of minutes at most.

Screen Shot 2018-09-06 at 3.08.47 PM

We have found this to be very helpful, because a volunteer running ProPresenter in one Auditorium can fix or redesign a slide, and the volunteer running ProPresenter in another Auditorium can simply pull up that file on their computer and copy it into their local library.

To sync over mass changes, we create a ProPresenter bundle file of presentations and save it to Dropbox. The other computers see the bundle file almost immediately and they can then be imported to get any new changes needed.

We have been using this workflow for over a year now and it has been great for us. Do you use ProPresenter and Dropbox together? If not, give this a try. Or, if you have a great syncing method that works well for your team, share it! I’d love to hear how you are using technology well to help the church be more efficient.

ProTally Release Build is here!

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!

Screen Shot 2018-08-30 at 4.12.01 PM
Here is an example of it being used with ProPresenter as a border box.
Screen Shot 2018-08-30 at 4.13.11 PM
Here is an example of the filled-in box version, as some people may prefer that instead.
Screen Shot 2018-08-30 at 9.37.21 PM
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.

Tally ho!

Controlling ProPresenter from a Ross Carbonite

I had someone send me an email recently asking how they could set up their Ross Carbonite to control ProPresenter, advancing slides and playlists through a custom control. After writing it out for them, I thought I would share this step-by-step tutorial.

It does require a Communications module license in ProPresenter. If you don’t own one, you can purchase it from RenewedVision.

First of all, in ProPresenter, you need to set up the Communications module to be a RossTalk Device (not a Controller).
  1. Go to Preferences, and choose the Communications module from the menu at the top.

    Screen Shot 2018-08-23 at 10.28.38 PM

  2. Click “Add Device” at the bottom and choose “RossTalk” from the list.
    Screen Shot 2018-08-23 at 10.28.40 PM

  3. Under Behavior, choose “Device”. If you wanted to control your Ross Carbonite from ProPresenter, you would choose “Controller”.

    Screen Shot 2018-08-23 at 10.28.53 PM

  4. Type in the IP address for the Carbonite and the port you wish to use. The default RossTalk port is 7788. I would recommend limiting the traffic to the single network interface that is connected to the same network as your Carbonite.

    Screen Shot 2018-08-23 at 10.29.08 PM

  5. When you are done creating the device, click Connect.

    Screen Shot 2018-08-23 at 10.29.14 PM

  6. If ProPresenter has connected successfully to the Carbonite, the button will turn green.

    Screen Shot 2018-08-23 at 10.29.18 PM

Next, you will want to create a new Device on your Ross Carbonite switcher to connect to the ProPresenter computer.
  1. On the Carbonite, hit Menu, then choose System > Next > Next > Device Config.

    Screen Shot 2018-08-23 at 10.32.19 PM

    Screen Shot 2018-08-23 at 10.33.13 PM

     

  2. If you don’t see Add (new), scroll the far left knob (device select) until that option appears.

    Screen Shot 2018-08-23 at 10.33.38 PM

  3. Turn the far left knob to choose the slot you want to assign it to. For this example, I chose Slot 1.

    Screen Shot 2018-08-23 at 10.34.37 PM

  4. Turn the middle knob to select Type: RossTalk.
  5. Hit Next.
  6. Use the far left knob to change the subtype of the server to xpression_1.0.

    Screen Shot 2018-08-23 at 10.35.30 PM

  7. Hit Next.
  8. Turn the knobs to enter in the IP address of ProPresenter computer.

    Screen Shot 2018-08-23 at 10.36.10 PM

  9. Hit Next.
  10. Turn the far right knob to set the Port if you didn’t use the default of 7788.

    Screen Shot 2018-08-23 at 10.36.22 PM

  11. Tap the far left knob to save the device.
  12. Tap the far left knob again to confirm the new device settings.

    Screen Shot 2018-08-23 at 10.36.57 PM

  13. Now Hit Menu, then choose Config > Input (the far left knob).

    Screen Shot 2018-08-23 at 10.37.55 PM
    Screen Shot 2018-08-23 at 10.37.58 PM

  14. Turn the far left knob to scroll through the inputs until you find the input for your ProPresenter computer. In my example, my ProPresenter input is labeled GFX.

    Screen Shot 2018-08-23 at 10.39.10 PM

  15. Hit Next twice until you see the Device option. It should be unassigned.

    Screen Shot 2018-08-23 at 10.39.24 PM

  16. Tap the center knob to enter the Device assign settings.

    Screen Shot 2018-08-23 at 10.40.13 PM

  17. Turn the far left knob to select the Device Slot you set up earlier in Step 3. I chose Slot 1.

    Screen Shot 2018-08-23 at 10.40.19 PM

  18. Tap the far left knob to add the device, then tap again to confirm.

    Screen Shot 2018-08-23 at 10.40.25 PM

  19. Now any time you bring that ProPresenter input up in Preview or Program on the switcher, it should automatically bring the device settings up on the menu screen of the Carbonite.

    Screen Shot 2018-08-23 at 10.43.25 PM

  20. If you tap the far right knob (NEXT), it will advance to the right in ProPresenter, going to the next slide. If you turn the far left knob (UP/DWN) to the left or right, it will advance up or down in the playlist.
  21. If you hit the NEXT button beside the Menu button on the Carbonite, you can see other options for the device. You can clear the various ProPresenter layers, etc.For your reference, those are:
    • Layer 0: Clear All
    • Layer 1: Clear Live Video
    • Layer 2: Clear Background
    • Layer 3: Clear Slide
    • Layer 4: Clear Props

Now you need to record a Custom Control in order to create a macro for this.

  1. Hit CC, and then select a blank bank/button.
  2. Hit record.
  3. You’ll need to then put the ProPresenter video input in Preview, to bring up the device settings.
  4. Tap the far right knob for “Next”, which will advance the slide.
  5. Then stop recording.
  6. You can edit the CC to remove the step of putting ProPresenter in Preview, as that was only for recording purposes.

I hope this helps!

Controlling a Wifi Plug over the network using TCP Messages

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.

HS100(US)2.0-package_1508143441338j.jpg
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.

Screen Shot 2018-07-25 at 4.06.54 PM.png
The buttons are first disabled when you open the panel until you’ve configured the outlet in the setup tab.
Screen Shot 2018-07-25 at 4.07.00 PM.png
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.
Screen Shot 2018-07-25 at 4.06.42 PM.png
Just click On or Off to toggle the outlet!

The panel is up on my Github repository, if you’d like to download it.