Category: Arduino

Posted on

Automation Using the Control Everything Relay Board

ControlEverything.com boards

As I mentioned in the previous post, I’m going to give the ControlEverything.com boards a try. I’ve received the 8 relay Photon board, an 8 relay I2C expansion board, and the cable to interconnect them.

So to start off, I plugged a Photon into the 8 Relay Photon board, connected 12v to the board, and worked through their getting started tutorial.

I flashed the Photon with the example I2C scan code, and it immediately detected the I2C port at address 32.

Next I tried out the example from their NCD8Relay library on GitHub. This worked great. It toggles the relays in various ways. You can hear the relays toggling, in addition to seeing the status LED of each turn on and off.

So next I needed to figure out how to integrate this board with Patriot. Currently Patriot assumes a dedicated pin to control each device. Since the ControlEverything.com boards use I2C, I’d need to make some changes.

So next I created a new Patriot plugin library named NCD8Relay. This plugin should work with any of the NCD relay boards. There are two different I2C chips used on the boards, so addressing needs to take that into account. Since I don’t have any of the other sized relay boards, only the 8 relay photon and I2C expansion boards are tested at this point.

So having extended Patriot with the NCD8Relay plugin, I verified operation of the boards using both the iOS app and Alexa smart home skill. This all looks pretty good, so the next step will be to mount the boards behind the lighting control panel and wiring them up. That’s coming up in the next post.

Posted on

RV Lighting Alexa Control

One of the lessons I learned from automating the lighting of my last RV is that I need to have a plan for what to do when it comes time to sell it. I didn’t have a plan, because I thought we were going to live in it until I died. Then it would be someone else’s problem. But now I know that I might have to replace the RV every ten years or so, so I’m going to be a bit smarter about it this time.

For the lighting for this RV, I am going to install my gadgets in a manner that doesn’t interfere with the operation of the existing switches. That way I can choose to simply disable the IoT automation, and everything will continue to work as it did the day I bought the RV. Also, I want to make it easy to remove the automation controllers without having the splice or repair any wiring going to the switches or lights.

Sainsmart Relay boards

To allow the switches to continue to work without automation, I’m going use relays connected in parallel with the switches. When using automation, the switches will be left off and the automated relays will open and close the circuit. When the relays are off or have been removed, the switches will continue to work as before. Since most of the lights are located in one of two control panels, that means I can probably handle most the lights with a pair of Photon controllers, each with a Sainsmart 16 relay board.

Piggyback Terminals
Piggyback Blade Terminals

To allow connection without modifying the wiring, I’m going to use piggyback blade connectors.

And of course, the Photon will be running the Patriot library to allow both iOS and Alexa voice control. Time to warm up the soldering iron.

Author update:

Upon connecting the Sainsmart 16-relay board to the Photon output pins (5v tolerant) I discovered that the relays are always energized. The 3.3v HIGH signal is  insufficient to turn off the relay. I could add level converters, MOSFETs, etc. to get this to work, but I don’t want all that extra circuitry flopping around when the RV is bouncing down the road. So I’m going to take a different tack.

Control Everything

In looking for Photon (3.3v) compatible relay boards, I came across some relay boards made by  ControlEverything.com. These contain various numbers of mechanical or solid state relays. They have a built-in regulator to allow 12v input to the board. And best of all the the Photon plugs directly onto the board. This will eliminate a bunch of wiring.

Even better, multiple boards can be daisy chained via I2C. So for example, I can start with an 8 relay board, then add an additional 8 relay I2C board without the need for another Photon. Surprisingly, the two 8 relay boards (with and without Photon) are a bit cheaper than a 16 relay board.

I’ve received the boards, and am starting to experiment with them. Things look very good so far, but I’ll need to modify the Patriot plugins to handle talking with the relays via I2C instead of direct pin mappings. I’ll be blogging about that in the next post.

P.S. Sainsmart has be great to work with, and I would definitely work with them in the future. This combination of parts just didn’t work out for this project. And no, they didn’t pay me to say that 🙂

Posted on

Patriot Plugin Architecture

Having released Patriot iOS and Alexa Smart Home skills, it’s time to get back to improving and extending the Particle.io Photon code. One of the obvious deficiencies with the existing code is that it requires that device support be built into the library. This is fast and really convenient if you just happen to want to use the included devices, but sucks if you have other devices you want to use. It’s all open sourced, so anyone can modify it however they’d like, but that sort of misses the whole point of Patriot: to allow hobbyists to focus on solving problems and not on how to build all the components. And the code is getting fairly complex, so it’s not a trivial task.

I’ve been thinking for awhile now that I’d need to add some sort of plug-in capability to greatly simplify adding support for new devices. This would also have the benefit of only including the code that’s needed by each particular sketch. Recently, there have been a few folks having trouble compiling the 3rd party DHT module. It seems that there are some differences between compiling natively and compiling in the Particle.io web IDE. An the irony is that DHT support might not even be needed for the folks having these problems. So my lazy solution is remove the DHT code and put it into a plugin.

So that’s what I’ll be working on for the next couple weeks. I’ll update this post with details as I work them out.

Posted on

Patriot iOS App

Patriot iOS appThis weekend I posted to GitHub the source code for a Patriot iOS app. This is a cleaned-up version of an app that I wrote awhile back to control Photon devices in my RV. The intent is to allow mounting old iPhone devices to the wall to use as control panels for my Photon controllers. Refer to my previous article about Patriot for information about the Particle.io code and Alexa skill.

In the image here you can see 3 different ways of controlling a Photon controller. There is an Alexa sitting next to an iPhone 4s mounted to the wall next to several wall switches.

The Problem with Switches

The switches are connected to a Photon mounted in the wall behind them and actually broadcast particle.io events instead of directly controlling power to lights. They can control multiple lights, or even things that aren’t lights. I had intended to put a bunch of switches like these around my home, but there’s a problem with mechanical switches like these. They suggest a ‘state’ of on or off. So for example, typically a switch would be “on” if one way, and “off” if the other. However, if I turn a a light on by flipping a switch up, then I turn the light off by telling Alexa to turn it off, then the switch continues to indicate “on” but the light is actually off.

Alexa Smart Home Skill

The Alexa is running the Patriot Alexa smart home skill to dynamically determine the events that my IoT Photons are listening for, so I can tell Alexa to turn activities on or off. But as described above, this leaves normal switches indicating the wrong state. So I decided that I need some sort of switch that can change to reflect the state even when changed by other devices or switches.

Old iPhone Devices to the Rescue

So an obvious choice is to use motorized switches. Unfortunately I couldn’t find any in my parts locker. But I did come across several old iPhones and began to think about how extremely powerful these could be to control my IoT devices. So I wrote a simple control panel app that displays the state of a list of hard coded activities, and allows tapping on them to toggle their on/off state. I then purchased some cheap plastic iPhone covers for them that I mounted to the walls, and can just snap the iPhones into place to hold them on the wall. I ran a power wire over, and voila!

Nice, works ok, but my head nearly exploded when I started thinking about  all the ways these could be extended. Before I start going on about possible future enhancements, let me announce that I have cleaned this original code up, extended it to use the latest Patriot dynamic device discovery, and posted the Swift source to Github.

 

The Possibilities of Patriot iOS Control Panels

So now that we have a system that allows old iPhones to communicate with our IoT system, what are some of the things that we can do to leverage the incredible power of these cheap devices? Here’s just a short list of some things that I’ve come up with so far:

  • Utilize BLE to detect the presence of certain other iPhones to monitor my comings and goings. Turn on lights when I get home after dark, etc.
  • Put a BLE tag on my car and motorcycle to track when they are at home or away or being stolen. Combined with the above…
  • Coordinate with Alexa commands to dim or display the panels.
  • Provide other views such as video chat, monitoring outside, etc.
  • Mount one of these outside to use as a doorbell with camera and audio intercom.
  • Use the back facing camera to perform motion detection, face recognition, etc. This one really has my head spinning. I intend to start looking into OpenCV to see about replacing simple motion and proximity detectors with just the camera mounted on the iPhones.
  • Motion detection and GPS: since my home is an RV, these may prove handy for a lot of things.

And the list just goes on and on. So this iOS code is intended as just a starting point. I hope others will get involved and contribute also.

Posted on

The Particle Libraries 2.0 works great!

I’ve built up quite a few Photon C++ files as part of my RV home automation projects, and have been noodling over how best to share these. I’d decided to release all the source on Github, but realized that just throwing a few dozen files out there probably wouldn’t benefit anybody. Well, when I saw Particle’s recent announcement for the libraries 2.0, it looked like exactly what I was looking for.

I’m delighted to say at this point that it appears to working great, and has simplified the process that I’ve been using to date. I currently use a combination of Git, shell scripts, shared C++ files, and the particle cloud compiler and flash to build the files for each of my controllers. It’s quick and works reliably, but it’s complicated and I dread trying to document and explain to someone else how to do the same thing.

So instead, it looks like Particle’s libraries 2.0 is going to make sharing quite easy.

First, I converted all my shared files into a single IoT library. This was fairly easy using the Particle CLI library functions.

Then I created several examples and included them in the IoT library’s examples directory. One of the cool things about these are that they can be built using the CLI, Particle Dev, or the cloud IDE. And since they’re a single file about a page long, any of those options work well.

Finally, I converted each of my controller’s source directories to use the Particle project format which creates a project.properties file. This allows then adding the IoT library to the project.

So now to build a project I need only run ‘particle compile photon’ in the project’s directory. To flash the project to the device, I use a shortcut where I name the project’s directory the exact same thing as the controller’s name. Then I can run the command ‘particle flash ${PWD##*/}’ and it compiles and flashes the code to the device with the same name as the directory.

And of course I created aliases in my .bash_profile so I can run them using just ‘b’ or ‘f’ from within any project directory.

The library code is probably still quite buggy, but I’ll be actively updating as issues are found. I’d love to hear your experiences with it, and reports of any problems. The source code is on GitHub at https://github.com/rlisle/ParticleIoT.git, and the ready-to-use library uploaded and published on particle.io under the name “IoT”.

Posted on

Self Discovering IoT System

I’ve been working for a couple years now to automate my RV using a combination of Particle.io Photon micro-controllers, an iOS app, and an Alexa skill. This has been fairly easy to do, due mostly to the ease of using the Particle.io API. Over the next year, in addition to adding additional functionality and more Photons, I hope to add Apple TV and Watch apps. This got me to thinking about how to make the system easier to configure and extend.

Since I’ve written all the software pieces myself (iOS app, Alexa skill, Particle sketches), up until now I’ve taken the expedient route of just hard coding the names of each controller into both of the apps. With only a single iOS app and Alexa smart home skill, this meant updating those two programs every time I added a new Photon, or extended one of the existing Photons. Not a big deal, albeit somewhat inconvenient.

However, recently I created an additional iOS app to allow using older iPhones to be mounted to the wall and used as control panels. Hard coding the names of the controllers into the apps means that I have to manually update each device whenever there is a micro-controller change. Now this is becoming a much bigger inconvenience.

So I’ve converted each micro-controller to be self registering with the system:

  1. Each Photon publishes several variables that list the device names it implements, in addition to what ‘events’ it listens for. These variables are exposed by the particle.io API and used by both the Alexa and iOS app to dynamically configure themselves.
  2. All applications use this information, instead of having to hardcode a list of commands.
  3. This functionality is built into a published IoT particle library, so copy/paste is minimized.

So now instead of needing to reprogram the Alexa skill and iOS control panel apps whenever I add a new controller, I just need to expose the data about that controller as described above, and all the applications pick it up.

I’ve posting the Photon and iOS code to Github, so please take a look and let me know what you think.

Posted on

Alexa Smart Home Skill

I’ve now replaced my previously created Alexa Custom Skill with an Alexa Smart Home Skill. I’ve been holding off doing this because of the difficulty of setting up an OAuth2 server. Recently I came across an article describing how to use Login With Amazon to do this though, and I have gotten that working now.

So now I don’t have to say the name of the custom skill when invoking Alexa. Using the custom skill, I would have to say something like “Alexa, tell My RV to turn on the computer”. Sheesh. Quite a mouthful. And easy to get wrong. But using an Alexa Smart Home skill, I now only need to say something like “Alexa, computer on”. This seems like a small change, but it has made a big difference.

I’m working on providing some instructions, and then I’ll post all this code to Github.

Update: I’ve now converted the skill from using the Login with Amazon to using the particle.io oauth directly, and I’ve published the skill. What this means is that it can now be used by anyone, and it will prompt you during installation of the skill to provide your Particle.io login to access your devices. Refer to my other posts and Hackster.io project for more details. I had initially call this ParticleIoT, but that was hard to say and spell so I renamed it Patriot which uses many of the same letters.

Posted on

Using Old iPhones for IoT Control Panels

I’ve been thinking for awhile now about using my old iPhones in my IoT projects. They have touch displays, wifi, cameras, audio, accelerometers, and maybe GPS depending on how old they are. Plus they have almost no value once they get a few years old. The only real downside to using them is the fact that they’re a bit hard to program, but hey, that’s what I do for a living.

So this past weekend, I scrummaged through my old Apple parts boxes, and came up with (2) iPhone G, an iPhone GS, iPhone 4s, and iPhone 5.
Doing some research, I decided that the iPhone G is not really worth messing with for a couple reasons:

  1. The newest iOS support available is SDK4, so writing code to run on it would be difficult, and could not support the advanced features released over the past five years or so.
  2. The iPhone G does not have a rear facing camera. One of the features I want to eventually support is using the camera for a room monitor. But since the phone will be mounted to a wall, the normal front facing camera will be pointed into the wall.

That said, the support for iPhone 3GS is not bad, but it is limited.

  1. iOS 6 is supported
  2. Xcode 7.3.1 is supported, currently the latest Xcode.
  3. Swift is NOT supported. Swift requires iOS 7.

    Image of iPhone 3GS
    Using an iPhone 3GS for simple control panel

So just for fun, I created a version of the control panel in Objective-C for iOS 6 to run on the iPhone 3GS. This app simply displays images in a collection view, and calls the Particle.io API when one is pressed. I probably won’t add much more to this app, but instead develop a Swift version for use on the newer phones. I’ll add new features to that version, and leave the Objective-C version for just simple control operations.

Update: I’ve now posted a cleaned-up version of the app code to Github, and and article on Hackster.io.

Posted on

New Photon Based IoT PCBs

New IoTv2 PCBs

I’ve updated the printed circuit boards for my IoT projects. These boards are 5×5 cm and intended to be used in a variety of IoT applications. They include the following features:

  • Switch from linear voltage regulator to buck regulator.
    • The linear regulators used on my previous boards were getting quite warm as a result of converting the RVs +12 volts to +5 or +3.3v. I found some inexpensive variable voltage bucking regulators for about $1 each. These are marked “D-Sun”, readily available on Amazon.com, and they work well.
  • Provide direct pin-outs to LED driver boards.IoTv2 PCB with LED drivers
    • I’ve provided 4 sets of PWM pins that can interface directly with the Sparkfun 12959 MOSFET LED driver boards. I’ve positioned the pins such that standard header pins can be used to attach the boards instead of wires. I’ve gone back and forth about integrating the functionality directly, and finally concluded that the space used by the MOSFET and screw terminals was better pushed off onto small extension boards. Up to four of these can then be optionally added as needed. Sparkfun sells these for $4 each, so it’s sort of a no brainer. Putting them onboard would force me to moving to a larger 10×5 cm board, and only save a couple bucks.
  • Both 3.3v and 5v supplied
    • I’m using a 5v regulator to provide power to the Photon. It then has a 3.3v regulator for itself, and can provide 3.3v @ 100 mA to other sensors, etc. Since most of the Photons pins are 5v tolerant, this enables using both 3.3v and 5v sensors.
  • Provide groups of pins for ease of connecting other devices
    • To simplify adding additional sensors such as DHT11 temperature sensors, I’ve provided groups of pads that provide a GPIO, power, and ground. Some are 5v, and some are 3.3v. I was careful to ensure that the GPIOs provided with the 5v power groups are in fact 5v tolerant. These are great for things like PIR motion sensors, various switches, and so forth.

So after checking that the first batch of 10 boards work as intended, I’ve ordered another 10 and am in the process of replacing most of my existing controllers with these. While the Photon costs substantially more than the previous Arduino Pro Mini and RF24 radios, the ease of programming over the air combined with their robust design (5v tolerant pins, super stable operation) and included Particle.io support make these worth it!

I’m currently using my Echo and Dot to control these, but recently got AVS running on my Raspberry Pi and may throw that into the mix also.

If anyone is interested in using these boards in your own projects, post your request in the comments and I’ll provide links to the Eagle files so you can have boards made yourself. If you don’t mind waiting about 6 weeks, you can order these from itead.cc for $13 total for 10 boards. If you’re in a hurry, DHL shipping increases the total cost to about $26 total for 10 boards that arrive in less than 2 weeks. I ship with DHL for the first batch, then use the cheaper shipping to get more while I work with the first batch.

Note: I’ve now posted the Eagle files on Github.

Posted on

Particle.io based IoT

Switch and PCBAt this point I’ve installed about a dozen Arduino Pro Mini based controllers in my RV. These are very inexpensive, about $2 each, but suffer from several limitations:

  1. Fairly slow
    • This is ok if all you need is something to read a switch and set a corresponding set of outputs, but becomes an issue as requirements grow.
  2. Require a direct FTDI cable connection to program or update
    • Arduino Pro Mini mounted to switchIn my usage case, I’m mounting these things above ceilings to control lights, and behind wall switches to read and broadcast switch state. This means every time I need to change or debug them, I have to open up the wall, which means removing the switch plate and switch or lamp fixture to get to them.
  3. Require direct physical access to resetSwitch plate removed and hanging from wall
    • Sometimes they just hang, or their associated circuitry hangs up, and it is necessary to “hard reset” them. They have a push button reset on them, but as mentioned above it isn’t easy to access them in my situation.

So for awhile now I’ve been contemplating converting my Arduino Pro Mini based designs to use the Particle.io Photon MCU instead. These parts are awesome:

  • Fast 32 bit CPU
  • Lots of memory
  • Built-in WiFi and antenna

This last item is the biggie. I can update them remotely, meaning that I can leave the boards buried in a wall somewhere and still reprogram or reset them.

The thing that has made me reluctant to do so up until now has been the price. These parts are $19 each. That may not sound like much, but I plan on using a lot of controllers in my RV, probably on the order of 30 to 40. But then I stopped and did the math: 30 Photons at $19 each comes out to $570.

What? I’ve been using one Photon to bridge between the Pro Minis and the internet to allow Alexa to control them. Now I’m going to have each directly accessible, simplifying the overall design. So I’ve designed and built another PCB for the Photon.

Photon PCB

So far things are working great. I’ve redesigned the architecture to use a publish/subscribe model, which will allow the system to be expanded without having to reprogram existing units. And I’ve converted my Alexa code so my Echo talks directly to the boards using particle.io publish instead of functions calls. But that’s a topic for another post.