I’m going to use this thread to document how I created a Photon/cloud based controller system for two gates on my property.
First, these two gates were automated by a high end company that installs their own hardware and basic electronics to control the gates themselves. They have a basic “contact closure” interface for other devices to also control the gates. You simply connect a relay controlled by your own device to two wires. Pulse it, and the gate will do a normal open cycle and close back. Hold the relay closed and the gate will stay open. Open the relay and the gate will close and stay closed. This is typical of most gate hardware. I am only doing full “open and stay open” and “close and stay closed” kind of commands, no pulsing.
(Word of warning: the above boards will ALMOST work with a 5V power brick, but the relay itself won’t pull! Don’t make that mistake. Use 12V warts. Don’t ask me how I know. Also worth noting: they have 1, 2, 4, and 8 relay boards. All use the same i2c IO controller to control the relays, but each has a different firmware as the number of relays is hard coded. Also worth noting is the 1 relay board is a special case in that the firmware just wants “on” and “off” commands for the single relay, whereas the others want “1on” and “1off” for the first relay, “2on” and “2off” for the others, etc. I have some 1 and 2 relay boards, but I use the same firmware on all of them since I don’t use any of the other IO anyway but thought I might use the second relay one day for something.)
Then I plugged in Particle Photons. In my original setup, I just used the NCD firmware with IFTTT integration. I had recipes that open/closed on a schedule, and I used the IFTTT app on iOS plus widgets to have buttons that could control my gates. But I had no status that way.
So later I created a controller for my gates using another Photon and I added some very basic Particle Cloud support for the controller (which I call a “monitor”) to talk to the gates (the “controller”). Confusing, I know. But it grew organically and so some things just didn’t get cleaned up along the way. Sue me.
So the Photon that controls each gate on the NCD.io board is controlled by the code here:
First, a disclaimer: I don’t know C++ and I’m not great at C, but this code does work for me. If you see things that you feel like REALLY should be improved, please point them out for me. I’m open to criticism and suggestions. Obviously this code started as the stuff from NCD, but all of it that does cloud stuff is added by me.
But basically you name the gate controller when you set it up and the code retrieves the name of the device it’s running on. In my case, one is “main_gate” and one is “club_gate”. These names aren’t hardcoded anywhere in gate-controller.
One note on status…we are really reporting the status of the control relay, not using any sensors to sense the actual position of the gate. We are assuming that the relay really is controlling the gate. And if you have any other controllers connected to your contactor (it’s common to also have garage door style fobs, industrial keypads, etc) and one of THOSE has the gate open, that open status is NOT reported by this device in any way.
This code I wrote from scratch. It uses the buttonClick, neopixel, and a library to talk to the i2c display.
The commands you can send to the cloud:
{gate-name}_relay_1 {1on|1off}
1on opens the gate or 1off closes it
getstate
each gate is listening for this and will publish {gate-name}_1 {ON|OFF} X where X is a 0-9 digit representing the amount of commands that will be skipped
skipcommand X
where X is 0-9
This command simply tells ALL gates to skip the next X commands from the cloud
The reason for the skips is because I still do scheduling with IFTTT (now using REST since we lost native IFTTT support) and sometimes I want to “leave the gate open” instead of letting IFTTT close it at the end of the day.
So a short press of the gate control button toggles the gate state. A long press sets the skips to 1 but can only do that, no more. There’s another way to do more…see next post.
Also a note on this: If you are doing the LCD, you can easily skip the Neopixels for status. I was experimenting on if I could even do them. They were hard to integrate, honestly. They are individual big neopixels inserted into arcade style buttons that were supposed to have 12V lamps in them. I hacked them to work, but again, it was kind of ugly and I didn’t document it.
And conversely, if you don’t care about the LCD or knowing skips, you can do just a button an neopixel setup. You could also go with both and use the extra space on the LCD for other info you could code in. That was part of my plan (was gonna pull some basic weather info…my monitor is in the wall in our kitchen).
The final way to control the gate is with an iOS app. You can’t buy the app, but we’ve open sourced it for anyone who can code their own app or just wants a code reference for how to talk to the Particle Cloud via iOS code. We currently deploy it to a handful of users using Testflight.
My kid wrote this app while on a road trip with me telling him as I drove how to talk to the devices. He has a couple other apps he’s written and had no Particle Cloud experience before this. I think my cloud ID is hard coded in this app, but our security token is not, you enter that in Settings. Anyway, the code for the app is here:
It shouldn’t ever actually be needed, but “Update” at the bottom does a “getstate” and populates the status outputs. Skip Control just does a “skipcommand” with whatever number you put in that entry box between 0-9. So basically if you want to keep JUST the main gate open at the end of the day, you’d send skips of 1, which would set that for both. Then just send a command (either one, doesn’t matter) to the club gate which will get ignored but change that gate to a 0 again.
This all works great for a small family to all have the app and have gate control and know what the gate status is anytime, anywhere. The app works fine on iPad as well as Apple Silicon Macs.
Note that the “Additional Headers” above is cut off ON PURPOSE. After “Bearer” you need YOUR token here. I’m not giving you mine! Lol. Then in addtion to the above you also need:
So this would turn the main_gate “1on”, which opens the gate.
A note: this is a recipe that uses my cloud method to control a Photon. There are examples of how to do this the “other” way, which would be using the REST API to talk directly to a Photon Function. That would work, but actually DOES NOT work in my complete system because the way I’ve coded the firmware for gate-controller the Function interface does NOT do the cloud stuff properly. That is to say it won’t send the state after it changes. So, uh, don’t do it that way.
Anyway, I don’t actually expect anyone to use this code to implement your own gate control system. But I post it here because it’s a fun example of a Photon controlled device plus a controller built with a Photon, plus the ability to control with an iOS app all talking via Particle Cloud. Of course if someone DOES want to use it for their gate control, I’m happy to help and open to patches.
I am not worried about people hacking my actual gates because I’ve posted all this. My gates exist to keep honest people from snooping and whatnot. There are many ways a motivated criminal could get access easier than hacking my gates via this system.
Future iterations will mostly probably be changes to the iOS app. My kid is working on some kind of iOS Widget support so you don’t have to fully open the app. We have Shortcut support now, too. We may add an Apple Watch widget, too. So if you’re interested in how to do those things, keep an eye on his github repo and/or ask here.
Oh, and as for the “why IFTTT?” Because I’m lazy and coding time properly isn’t trivial. But that’s a thing that IFTTT actually does really well. DST has always just happened properly, etc. And there’s a web interface if I want to disable the schedules completely for any reason. That is also why it was easier to limit “skipcommand” to a single digit. If I need to disable the gate for anything longer than that, well, I can just go turn off IFTTT.
And I mentioned it in an earlier post, but I want to mention it again: the ACTUAL PHYSICAL GATE STATUS is NOT being reported in this system. What is being reported is ONLY what THIS SYSTEM is telling the gate to do. If any other controllers are also controlling the gate (it’s common to “stack” various other controllers on the gate contactor wires), this system will NOT report when one of those is overriding and opening a gate that this system thinks is closed. I’ve been tempted to add support for this, but never done it. I’d welcome it as a contribution, certainly.
I’m probably forgetting something important, so just yell if you see something obvious missing.
Great writeup; a simple magnetic reed switch could be used to retrieve the actual gate position. We use these quite often when installing gate systems for customers for various uses.
I think it’s even easier than that…I’m pretty sure there’s an interface on the gate control hardware upstream of mine that will give that info, I’ve just not looked into it. That’s the only way I’d even bother because adding wiring from my control box to the gate itself would be a big pain in the butt. I really don’t think I care, though. Short of a full failure, none of the upstream controllers I have ever do anything to hold the gate open anyway. I have a keypad that’s programmed with codes and I have a garage door fob thing, both of which just pulse the gate. And the most likely failure mode is to do nothing, which would just leave the gates closed anyway.
