Moving MQTT to the Raspberry Pi

One of the trouble spots with my RV home automation system has been the MQTT server. I know that should be a fairly simple component, but it seems that fairly frequently things will stop working, and the problem is that the MQTT server hung up, or rebooted and didn’t fully restart. I’m currently using an old Mac Mini mounted under my desk, and that’s the problem. Even after experimenting with settings and configuration, I continue to have problems. So I considered and prototyped a couple other options, but each had its own problems. So now I have switch to using a dedicated Raspberry Pi.

Let me clarify that I think that MQTT running on a Mac Mini is awesome, and a very good addition to a home automation system. It’s just that for my RV home automation where the power is constantly being turned on and off as I travel, it tends to be problematic. I’m hoping that a dedicated Raspberry Pi running off the 12 volt system, and doing nothing but running an MQTT broker will be much more robust.

With my recently upgraded cellular modem setup, my internet is pretty reliable and works even when I’m moving down the road. I depend on having a consistent internet connection in order to use Alexa. I’m going to power the Raspberry Pi with a 12v to 5v converter, so the MQTT broker should be always available.

Particle.io Cloud Limits

I would have loved to be able to just switch to using the particle.io cloud for all MQTT messaging, but the number of message permitted on the free plan is only 100k messages per month, which averages out to about 2 messages per minute across all devices. This isn’t enough because I also write timestamp, synchronization, and diagnostic logging messages over MQTT which can greatly exceed this.

Cloud MQTT

I looked at several cloud based MQTT brokers, and most would have some sort of small monthly fee associated with it. These include HiveMQ, Adafruit.io, and Google IoT. But using these didn’t really reduce the complexity of the system, which was a big reason for even exploring this.

Raspberry Pi Zero W

So I decided on using a Raspberry Pi Zero W, and ordered a CanaKit and a 12v to 5v converter for $45 off Amazon. This came with everything I needed, some of which won’t be used once all the software is loaded and configured.

Rapsberry Pi Zero W configured with Mosquitto MQTT broker

So after some simple configuration of the included NOOBs operating system included on the 16 gig SD card, I installed Mosquitto and now have a full-time, dedicated MQTT broker for under $50.

Home Automation Fun

It’s been a fun year playing with creating home automation software, but totally unproductive. I had decided to write my own Mac Mini, Swift based programming to control all my IoT devices. I did this, and then ran into lots of issues trying to interface with all my IoT devices. To make matters worse, the things I was trying to interface with kept changing (eg. new Samsung Smartthings APIs, programming language, etc). So while I think I came up with a pretty powerful code base for automating my home, I hadn’t actually automated anything in the past year. So I’m going to call that a fun learning experience, but I need to change direction if I actually want to automate my RV home.

Home Assistant v0.91

I experimented with using Home Assistant. For me, it actually made things much more complicated. There are no off-the-shelf solutions for automating the 12v lighting system of an RV. So I have to create my own IoT solutions, and integrating that into another system like Home Assistant just adds another layer of complexity.

Rolling My Own

So having experimented with using Home Assistant, SmartThings, and Homekit, I eventually ended up using the Alexa skills I wrote awhile back, along with Patriot custom Photon coding.

Like a Scene from The Big Bang

Ron and his desk lampOk, I feel extremely nerdy. Did you see the episode of The Big Bang where they program an IoT device to turn on a lamp by sending a signal all around the world before it gets back to the lamp to turn it on? Well, I was suddenly struck by the similarity when I got Alexa to turn on the Z-Wave light bulb in my desk lamp last night:

  • “Alexa, turn on desk lamp”
  • The voice command is picked up by the Alexa Show device on my desk and sent to Amazon cloud.
  • Alexa Smart Home converts the audio command to a “turn on desk lamp” intent and routes it to my Alexa Smart Home skill running in an Amazon Lambda in the cloud.
  • My Smart Home skill converts the intent and forwards a “turn on desk lamp” command to Particle.io.
  • Particle.io publishes the command to my Photon IoT controllers, one of which is acting as a bridge from particle.io to MQTT.
  • The Photon bridge reformats the command and publishes it to MQTT.
  • The MQTT broker is running on a Mac Mini, which then forwards it to all other devices subscribing to MQTT.
  • One of these MQTT subscribers is the smartthings-mqtt-bridge app running on the Mac Mini. It then receives the MQTT “turn on desk lamp” command, and forwards it to the Smartthings web hook over the internet.
  • (Should I mention the Wifi to router to … Nah).
  • The Smartthings server receives the command via web hook, routes it through a Groovy program running in Smartthings, and forwards the command to my Smartthings hub over the internet (and router to wifi, etc).
  • My Smartthings hub then transmits the “turn on” command over Z-Wave radio to my desk lamp light bulb.
  • And the light turns on.

Woohoo!

Patriot 4: Swift Programming IoT Home Automation

I’ve turned a corner in my thinking about how best to automate my home. For years now I’ve been trying to integrate and generalize all of the various technologies (MQTT, SmartThings, Particle.io, Alexa, iOS, Raspberry Pi, etc) to provide a simplified interface for controlling everything. The tough part is really describing what I want the system to do; how it behaves. Using an any sort of text or table driven, simplified, abstract programming model always comes up short. By this I mean the sort of approach where I am allowed to specify things such as “if device A is on, and the time is after HH:MM PM, then set device B to XX”. This works great for doing fairly simple things, but doesn’t really handle the more complex types of scenarios I always run into, or if it does handle it, it does so in a manner that gets very complicated and unmaintainable very quickly. As a professional programmer, this situation is very familiar, and describes what happens with poorly written code. So I started thinking about how to solve this problem in a way that would be greatly extensible and very maintainable.

And I got to thinking about how Patriot automatically detects new devices. Well, sort of automatic. If I program a Photon to expose a device, and write the Photon code to implement that device, then Alexa can detect it and control it with voice. That’s very cool, but I’m getting tired of having to tell Alexa which lights to turn on and off every morning and night. I want my home automation system to know when to do that based on the plethora of sensors that I’ve installed.

So then the big ah-ha moment for me. Automatically detecting and installing devices doesn’t provide any automation until I write some sort of specific code to control it. This could be generalized code such as IFTTT, or bare bones custom code like Photon C++ or Python code on a Raspberry Pi.

One of the issues that frustrates me is the large number of different programming languages and platforms I’ve had to work with. So recently I decided to replace my Raspberry Pi with a used Mac Mini in order to reduce the number of different programming languages, environments, and platforms I have to remember and work with. The 2010 Mac Mini is quite powerful and flexible, and I found one on craigslist for $150. It’s now my media center as well as my MQTT broker and home automation controller. And I can program it in Swift, which is my daytime job programming language.

So if I have to write code no matter what, why not do it using the best tools, environment, and clean programming practices? To my mind that means Swift programming on the Mac Mini.

So that’s where I’m going with Patriot 4. I’m writing a Mac app in Swift using clean, TDD code. I’ll be sharing the Swift framework that is evolving out of this, but it’s going to require Swift programming skills in order to use it. I’m excited to see just how far this can go.

Alexa as Home Automation Integration Point

Over the past few months I’ve done a lot of experimenting with getting various home automation technologies to communicate with each other. For example, setup a Raspberry Pi to bridge between SmartThings and Home Assistant using MQTT. SmartThings in turned connected to my Harmony Hub. Then tied in my Patriot custom electronics devices via MQTT. What I ended up with worked, but seemed overly complex. I don’t even want to try to blog about how to reconstruct such a beast.

So that got me thinking about how to simplify things. I realized that the individual pieces are are fairly simple: SmartThings, Patriot, Harmony. Each of these provides their own Alexa smart home skill, and most of what I want to accomplish can be done entirely by Alexa. So it isn’t really necessary to try to bridge between each of those. Instead, I can let Alexa be the common interface to each of them.

So that’s what I’m trying now. I’ve removed the bridging pieces, and will be using Alexa to control everything. Things certainly are simpler now. I’m hoping that the recently announced support for Echo Buttons indicates a direction for Amazon that will allow other inputs to be used with Alexa. Amazon is holding to their “voice first” mantra, but we’ll see where this goes.

In the meantime, I’m investigating whether I can trigger an Alexa skill lambda handler directly from a Patriot device. I think it may be possible…

Switching to Samsung SmartThings

After a frustrating few weeks of unsuccessfully trying to get Home Assistant working with my Patriot Particle.io devices and Z-Wave bulbs, I’ve decided to switch directions and won’t be investing any more time on Home Assistant. While I really appreciate all the hard work that folks have put into Home Assistant, it just isn’t a good fit me.

So I am switching gears and am investigating integrating Patriot with the Samsung SmartThings hub instead. This will give me both Z-Wave and Zigbee control, and some level of operation when disconnected from the internet.

I’ve read through much of the SmartThings developer documentation, which is very good. I like the architecture, and clear descriptions of how to integrate 3rd party hardware.

I ordered a SmartThings Monitoring Kit from Amazon that should be here tomorrow in time to have some of my Holiday time off to play with it. This kit includes the SmartThings hub, a couple door sensors (with vibration and temperature sensing), an a/c switched outlet, and a motion sensor.

In searching the developer forums I’ve located some posts by others that have been successful in integrating SmartThings with the Particle.io cloud, so I’m confident that in no time I’ll have it controlling the plethora of lights, fans, and awnings that I currently control using Particle.io Photons and Patriot.

Teaching Alexa What To Do

In the last post I described combining an Alexa custom skill with an Alexa smart home skill. Well, I got that working this past week and it works great. The combination really has some interesting potential.

Chihuahua and electronics
Just a cute little doggie watching me wire stuff together.

Smart home skills are great because they’re short and simple, and the supported device names can be extended dynamically through the “discovery” process.

Custom skills are great because they’re very flexible, and allow interactive dialog, unless something fits into a lot, isn’t extensible.

Putting the two together can provide the best of both. Here’s what a dialog with Alexa sounds like using both the Patriot smart home skill and the new Patriot custom skill.

Initially the skills don’t know about any activity called “computing”. So when I say:

“Alexa, turn on playing piano”, it responds with “Sorry, I didn’t find playing piano”.

That’s as expected. So let’s teach Alexa what we want it to do when we say “playing piano”. Note that I’ve made the invocation words “my lights”.

“Alexa, tell ‘my lights’ to turn on office when I say playing piano”

Then Alexa responds with:

“Ok, from now on when you say ‘playing piano’ I will set ‘office’ to 100 percent. This is a new activity, so you’ll need to tell me to ‘discover devices’ if you want to use the smart home command ‘start playing piano’.”

How cool is that?

So then saying “Alexa, discover devices” results in “Ok, found one new device ‘playing piano'”.

And then I can say “Alexa, start playing piano” and the office light comes on.

Extending an Alexa Skill to Control Patriot Devices

In the last post I showed how to create an Alexa skill using the Alexa Skill Kit Command Line (ask-cli). In this post I’m going to show how to extend that skill to control the blue LED on a Particle.io Photon.

Prerequisites

This post assumes:

  1. You are already familiar with Photon development using the Particle.io IDE of your choice
  2. You have a particle.io account already setup.
  3. You have completed the previous post to create a starter Alexa skill using the ASK CLI.

Continuing Where We Left Off

By the end of the last post we had a working Alexa skill, although it didn’t really do anything interesting. Let’s change that and add some code to make it talk with a Photon controller using the particle.io API.

Let’s start by adding a couple intents to turn on and off a light:

Alexa, turn on the blue light

Alexa, turn off the blue light

Easy, right? We’ll add the intent first without it doing anything except responding “Ok”, then add the calls the the particle.io after that is working.

Basic Changes

Let’s start by changing the invocationName on line 4 of en-US.json to “my photon”. Now we can say “Alexa, tell my photon to …”.

Adding a New Intent

Copied intent

Adding an intent will require defining it in the en-US.json file, and then creating an intent handler in index.js.

So open en-US.json in your favorite editor, and copy the entire HelloWorldIntent. After the copy, it should look as shown here.

Next edit the two copies to make them be our turn-on and turn-off intents.

Note: we could have used a single intent with a slot for the on/off state, but I’m trying to keep things very simple. Plus this allows you to use slang or fun expressions such as “light me up” or “gee, I feel blue”, etc.

So now we should have a TurnOnIntent and a TurnOffIntent defined. Let’s delete the previous MyNameIsIntent. So the final file should look like this:

Edited en-US.json file

So now we need to handle the two new intents, and remove the deleted intent from the Lambda source. So open the lambda/custom/index.js file and make the following changes (or you can cut/paste the entire thing from the example below):

  1. Delete the ‘SayHelloName’ handler on line 29 through 34.
  2. Edit the ‘SayHello’ function to say something appropriate such as “You can tell me to turn on or turn off the light”. Update the cardRenderer() text similarly.
  3. Copy the same or similar text to the help intent.
  4. Delete the HelloWorldIntent and MyNameIsIntent
  5. Copy the SayHello intent twice
  6. Change the first SayHello copy to ‘TurnOnIntent’, and change the text to something like ‘Ok, the light is now on”, and provide more descriptive text in cardRenderer. The later is the text to be displayed on Show and in the Alexa app.
  7. Similarly, change the second SayHello copy to ‘TurnOffIntent’, and change the response and card text.

The index.js handler’s section should look similar to this after these edits:

Updated index.js

Now deploy the changes by entering “ask deploy” again. Test the updated skill by saying “Alexa, tell my photon to turn light on”. Make sure that you previously enabled testing in the Alexa skill test tab.

Verify that all of the intents work as expected, including:

  • Just launching the skill: “Alexa, open my photon”
  • Asking for help: “Alexa, ask my photon for help”
  • Turning on light: “Alexa, tell my photon turn light on”
  • Turning light off: “Alexa, tell my photon turn off”

If all that is working as desired, let’s move on to sending on/off commands to the Photon via the particle.io and Patriot open source library.

Adding the Particle Javascript SDK to our Project

So now on to the fun part. Alexa can now handle commands to turn something on and off, so we need to forward those requests to the particle.io API.

We’re going to use the particle Javascript SDK. I had posted code to Github a couple years ago called alexaParticleBridge using raw HTML calls, but since then Particle published their SDK that makes this a lot simpler.

So first we need to fetch and add the particle-api-js package to our project.

  • Edit lambda/custom/package.json to add the following line to the dependencies section:particle api dependency
  • Within the lambda/custom directory, run “npm update” to fetch the particle sdk modules.

Now we need to add the Particle object to our code. Include the Particle object in index.js by adding the following line near the top below the line that includes the alexa-sdk:

Code to include particle sdk

Setting Up Alexa Account Linking

Before we can call the methods of the particle object to communicate with our device, we need to give Alexa the credentials needed when calling the Particle API. We could hardcode our Particle account username and password into the skill, but that would be unwise and is totally unnecessary. Both Alexa and Particle.io provide support for using OAuth2.

Without getting into the messy details, what OAuth2 does in this case is to allow the Alexa skill to call a webpage provided by Particle.io. That webpage prompts the user to enter their username and password, and if valid will forward an access token to the Alexa skill that it can use to access the API. The Alexa code never has to know or even see the user’s credentials. How cool is that?

To get Alexa Account Linking working, we don’t really need to understand how OAuth2 works. We just need to know where to get the information needed. I’m going to step us through doing that.

Note: currently it doesn’t appear that the ask-cli supports uploading Account Linking information, so we’re going to need to enter the information directly into the Alexa developer website for the skill.

So open up a browser window to you Alexa developer account, and browse to the skill’s Configuration tab. The Endpoint information should already be filled in. Below that is the scary looking Account Linking radio button. Select Yes and a bunch of cryptic entry fields will appear. Let’s fill then in one-by-one:

  • Authorization URL: https://api.particle.io/oauth/authorize
    This tells Alexa the URL to display to prompt the user for their account login. This is a Particle.io provided website.
  • Client ID: particle
    This is provided to the Particle.io authorization URL. We will generate this in the next step, but for now enter “particle”.
  • Domain List (optional):
    Leave blank. It isn’t needed.
  • Scope: none
    Click on the Add domain button and add the scope ‘none’. It isn’t currently used, but may cause problems if something isn’t entered here.
  • Redirect URLs
    These are filled in for you. We don’t use them, so you can ignore them.
  • Authorization Grant Type: Auth Code Grant
    Select Auth Code Grant
  • Access Token URI: https://api.particle.io/oauth/token
    This provides Alexa with the URI to use when requesting or refreshing an access token. It is provided by Particle.io.
  • Client Secret: particle
    We will generate this in the next step. For now enter “particle”.
  • Client Authentication Scheme: HTTP Basic
    Leave this the recommended default.
  • Permissions:
    Leave these all unchecked.

Save this page. We’ll come back and enter the actual Client ID and Client Secret later.

Make a copy of one of the Redirect URLs. We’ll need it to create the client ID and secret in the next step.

Generate an Oauth Client

We need 2 things to create an oauth client:

  • Your particle.io access token
  • The redirect URL from the previous step

To get your particle.io access token, log into your particle.io account and go to the IDE. Select Settings (the gear icon in the bottom left) and assuming that you are logged in, the Access Token will be displayed near the top left. Make a copy of it for use in a moment.

Now we need to use your access token along with the Redirect URL saved in the previous step to create a valid Oauth client. These instructions assume you are running on a Mac and using the Terminal, but you could use any program capable of issuing Curl commands.

  • Open a Terminal or Command Line window
  • Issue the following command, substituting your redirect url and access token:
    • curl https://api.particle.io/v1/clients -d name=<your-skill-name> -d type=web -d access_token=<your-access-token> -d redirect_uri=<your-redirect-url>.

The response should include an id and secret. Make a not of these.

Warning: This is the only place that the secret will be displayed. Save it carefully. If you lose it and need it again later you will have to repeat the above steps to recreate a new id and secret.

Now go back to the Alexa Configuration page and enter and save the new Client ID and Client Secret you just created.

Whew! That should do it. Save this information, and restart your skill. When your skill is enabled in the Alexa app, it will display the Particle.io login screen where you can enter your user id and password. From then on, Alexa will automatically fetch a Particle.io access token that your code can use to access the Particle.io API.

Using the Access Token

Now that we’ve setup account linking, Alexa will pass an access token to our code with each request. It will be passed in the event session information event.session.user.accesstoken. Let’s update our code to get and save it.

var token = this.event.session.user.accessToken;

Sending Requests to Particle.io

Now all that’s left is to use the Particle object created to to send requests to our Particle devices using the token obtained above.  So lets create a function to call the Particle API Publish function:

publish function

Now we can add calls to this method in our intent handlers, and Publish events to our Particle devices. Here’s the TurnOnIntent and TurnOffIntent will the calls to publish():

TurnOnIntent and TurnOffIntent code

Note that a promise is used, and that emit is only called after the promise resolves. Also, the arrow function is used to allow “this” to continue to point to the response object.

So at this point we have a working Alexa skill that Publishes events to our Particle devices. In this example we used the device name “blue”. This needs to match the name you gave a device or activity in your Patriot code. I’m not going to duplicate the information about using Patriot, since I’ve posted several articles about that already. And of course you can call other particle API methods in addition to publish.

So this example should give you enough information to make function calls, set or read variables, and so forth. The complete project code is on Github. I hope you have as much fun with it as I have.

Caveat: I’m very much an intermediate Javascript programmer at best. I’m working with and learning from some really good Javascript programmers, but I’ve got a long way to go. Please don’t use my code as an example of the correct or best way to do things in Javascript.

Using ASK CLI to Create a Custom Skill

When Amazon announced the ASK CLI a couple months ago, it created a simpler and more powerful way of creating and updating Alexa skills. We’re going to use the ask-cli to create an Alexa custom skill. In the next blog post we’ll extend that skill to interact with a Particle.io Photon using open source Patriot code.

Before the ASK CLI was available, I had to open multiple browser windows and edit data directly in the Amazon Alexa developer portal and AWS Lambda console. As a professional software developer, I’m accustomed to using powerful editors and source code management tools such as Git to track my changes. Being forced to enter data into a web browser page leaves a lot of room for mistakes. And tracking those changes with Git means having to cut/paste from a tracked local file to the browser, again leaving room for more mistakes.

The ask-cli goes beyond just allowing local files to be uploaded to an Alexa skill. It provides a start-to-finish set of commands to create, update, and publish skills.

So let’s see how the ask-cli can be used to create a new Alexa skill from the ground up.

Install and Initialize the ASK CLI

Refer to the Amazon documentation for instructions on installing and setting up the alexa skills kit command line interface (ask-cli). You’ll need to configure it with your Alexa developer account and an AWS account using the “ask init” command.

Create a New Skill

Now create a directory to contain your new skill, and run the “ask new -n <skillname> ” command. For example, I’m naming mine “Patriot”, so the command is “ask new -n Patriot”. This results in the following directory structure:

folder structure created by ask new

In one fell swoop we have created a basic “Hello World” Alexa custom skill. This includes the Alexa intent schema, utterances, and Lambda source and meta data. Pretty cool, eh?

Add Source to Git

If you use Git to track your source changes, now would be a good time to create a repo and add the files to it. This step is completely optional, but recommended.

Run the Skill

At this point, even without having changed anything, the new skill should work. Let’s upload it just to see:

ask deploy

If you’re accounts and ask-cli are setup correctly, then you should receive a series of messages indicating that the skill and lambda have been deployed correctly as shown here:

ask deploy
-------------------- Create Skill Project --------------------
Profile for the deployment: [default]
Skill Id: amzn1.ask.skill.your-new-unique-id...
Skill deployment finished.
Model deployment finished.
Lambda deployment finished.

Now if you check your Amazon Dev Alexa and AWS accounts, you should see that a new Alexa skill with the name you specified on the “ask new” command, and a Lambda  named “ask-custom-<name>-default” have been created. The default invocation word for the skill created by “ask new” is “hello world”.

By default, the new skill is not enabled for testing. Go to the test tab in the developer.amazon.com Alexa console console and enable it, and then you can test “hello world” on your Alexa device (Echo, Dot, EchoSim.io, etc).

Edit the Source Code

Ok, so now that you’ve seen the awesome power of a fully functioning death star, er I mean Alexa skill, we can commence to editing it to do something that we want beside telling us hello.

Now begins the iterative development process:

  1. Updating the source
  2. Deploying the skill
  3. Testing the skill
  4. Repeat

I strongly recommend that you make tiny changes each iteration, and use Git to check in each step of the way. That way you can back up a step if something breaks and you cannot figure out what.

There are 2 main source code files you need to work with. For simple skills, that’s all you need to modify:

  1. models/en-US.json (if you’re in the US, otherwise named for your language)
    contains the intents, slots, and utterances (now called samples)  that Alexa will respond to.
  2. lambda/custom/index.js
    contains the response to each intent.

By default your new skill will say “Hello” in response to launching the skill eg. “Alexa, open hello world”, or “Hello <name>” in response to “Alexa, tell hello world my name is <name>”. I recommend playing with the existing code, making small changes to the skill, redeploying it, and verifying that your changes act as expected.

Here are some things to try:

  1. Change the response to the SayHello intent from “Hello World!” to “Hello whatever your name is”. This should require just a change to line 25 of index.js.
  2. Change the help response. This is on line 43 of index.js.
  3. Add some additional samples to en-US.json for the user to say to invoke the two intents. For example, add “whats up,” between “hello”, and “say hello”,.
  4. Change the invocationName in en-US.json. For example, change “invocationName”:”hello world” to “invocationName”:”ahoy matey”. In addition, change the response in index.js to “Welcome aboard!”

If you don’t include quotes or commas where needed, ask will happily upload the broken code, and you won’t know until you test the skill. This is where a good Javascript editor comes in handy.

I’m not going to try to cover all the details of coding an Alexa skill here. There are lots of tutorials and blog posts in addition to Amazon’s documentation. I leave that as a homework assignment for you.

In the next article I’m going to show how to update this skill to send on and off commands to the LED on a particle.io Photon.

Controlling things in my RV with the ControlEverything boards

Boards mounted behind panel

As described in my previous posts, I now have a pair of 8 relay boards from ControlEverything.com controlled by Alexa, an iOS app, and other Patriot devices. So now its time to get to work and actually install the boards and wire them up to the first control panel.

 

The front control panel in my RV contains the most switches, so I’m going to start there.

The top part contains switches for the vent (open, close, fan) and 5 other lighting switches. So I’m going to need 8 relays.

RV control panel top part

  1. Vent fan
  2. Vent Open
  3. Vent close
  4. High counter lights
  5. Low counter lights
  6. Sink handing lamps
  7. Kitchen ceiling lights
  8. Left side trim lights

RV front control panel

The lower section has a bunch of controls and indicators on it, but I’ll only be automating 7 of the switches:

  1. Ceiling lights
  2. Door side outside floods
  3. Opposite door side outside floods
  4. Front porch floods
  5. Front awning LEDs
  6. Front awning extend and retract

So I pulled each panel to see if there is room behind it for the 3″ x 7″ x 1″ boards. Unfortunately there is a water pipe hidden in the midst of all those wires that prevents pushing them back out of the way.

Front panel removedSo my next step was to pull the entire panel as shown. This requires removing 8 screw covers and screws, and then loosing or removing some of the individual control panel screws because they went all the way through to the wood behind the panel.

This is where having a very supportive wife helps, because it looks pretty scary at this point.

Once removed, I could see that there was a ton of room in the bottom section, and sufficient room in the top section. After positioning the boards various ways in those sections, I realized that the bottom section would easily work, but the wire runs would be pretty long. So I considered  using the top section, then realized that the boards would fit at the top of the 2nd section, simplifying routing of the wires.

Boards mounted behind panelSo here you can see the boards mounted inside the wall behind the panel. The sides angle inward, so I was able to run a few screws through the holes in the corners of the boards to fasten them. Just by luck, the width of the opening is enough that I can get to the wire screw connectors on the boards.

So once the boards were mounted and 12v power applied, I could test the Alexa interface.

So next I just needed to connect the relays to the 15 switches. The screw terminals are easily accessible, so it’s a matter of just connecting the piggyback terminals and hooking up the 15 wire pairs.

So for each switch:

  1. Attach a pair of wires to the normally open (NO) relay terminals
  2. Attach a piggyback connector to each wire
  3. Remove the connector from the switch
  4. Attach the wire that was going to the switch to the piggyback connector that has the relay’s wire connected to it.
  5. Attach the piggyback connector to the switch.

The result is that the relay is connected in parallel to the light switch, and no wires have been cut.

So after attaching the first relay, I did a quick test with Alexa, and nothing happened. What? I could see the LEDs coming on, I could hear the relay flipping, but the light wasn’t coming on. So after about an hour of measuring the relay terminals, trying other relays, scouring the forums, whining and moping around, I finally figured out that the relays are mislabeled on the Photon 8-Relay board. Relay 1 is actually labeled relay 8. They’re backwards right-to-left instead or left-to-right. So I moved the wires from relay 1 to relay 8, and its working now.

Armed with this new information, I completed hooking up the other 14 relays, and now I can control most of the lights in the main room, the powered vent, about half of the outside lights, and the front awning and its LED strip lights.

Now I’m ready to order a couple more ControlEverything boards so I can tackle the smaller, rear control panel.