I’ve never had to debounce either the mechanical switches on my garage door sensors or the magnetic switch sensors on my security system sensors… I do get line noise though, and I might have to redesign my circuit with some caps. It would be nice to not have to do software debouncing.
I’ve got one of the EZ4’s hooked up, and am trying out your code. Not getting expected results. Are you powering it with 5V or 3.3V?
Hi there Joel. Everything powered with 5V. Have you put the serial signal through an inverter (TTL)? I’m using a 7400 NAND gate (both inputs tied together) for my inverter.
I have a debounce class, modelled on @fliphunters approach, but slightly different implementation. Strangely, even set at 100ms, I’m experiencing some issues, but I think what’s happening is that as the magnet passes over the switch, activates it, then goes through a dead zone and then activates it again. So, I’m wondering if it’s not actually bounce, but physics surrounding magnets and the reed switch. Code for my class looks like this:
`class ReedSwitch {
static DEBOUNCE_PERIOD = 0.100 // Debounce delay of 100ms
_DebounceEnabled = null // Are we processing a switch bounce
_LastState = null // Remember the last state
_InputType = null // Type of Pin
_HardwarePin = null // Pin that this class is attached to
_CloseEvent = null // Switch is closed, so pin is grounded (0v)
_OpenEvent = null // Switch is Open, so pin is floating/pulled up (+ve)
constructor (HardwarePin, InputType, CloseEvent, OpenEvent) {
// Copy constructor args
_InputType = InputType
_HardwarePin = HardwarePin
_OpenEvent = OpenEvent
_CloseEvent = CloseEvent
// Configure the Imp Pin
_HardwarePin.configure (_InputType, StateChangeBegin.bindenv (this))
// Set the initial/last state from a physical reading
_LastState = _HardwarePin.read ()
_DebounceEnabled = false
}
function StateChangeBegin ()
{
// Check to see if we're in the midst of checking for switch bounce
if (_DebounceEnabled)
return; // Yes, ignore this state 'change'
_DebounceEnabled = true
// Check the switch a little later. Let it settle down
imp.wakeup (DEBOUNCE_PERIOD, StateChangeFinal.bindenv (this))
}
function StateChangeFinal ()
{
// Read the state of the pin
local NewState = _HardwarePin.read ()
// Did it change from its last state ?
if (NewState != _LastState) {
if (NewState == 1) { // Has the switch gone to an open state?
_OpenEvent (); // Call the delegate
}
else { // Switch has closed
_CloseEvent (); // Call the delegate
}
_LastState = NewState // We have a new state
}
// Strange, but the switch, after that wait, is in the same position
else {
server.log ("After debounce, switch state not changed!")
}
_DebounceEnabled = false
}
function GetState ()
{
return _LastState
}
}
`
Additionally, I’ve now implemented the PushOver logic present in this article. So, I have an Agent which uses that snippet and I now get iOS notifications of when the garage door is Open or Closed.
Didn’t have an inverter in the loop. I’ll pick one up tomorrow. Thanks. I finally broke down and ordered an iPhone 5S, as iOS 7 really slowed down my 4. I wanted to hook up SiriProxy to the opener, but I just read that it got hosed with iOS 7. Guess I’ll have to look around. Pitchfork needs a full iOS 7 makeover as well.
I’ve been using Twilio for any notification that isn’t a reply back from an app request.
I think that garage Imp is going to also handle the lighting. I have a meter of RGB LEDs and some MOSFETs coming. From what I can tell, a meter is only going to produce about 240 Lumens, so I would need 7 to replace a 100W incandescent bulb. Can anyone provide better info on that?
Dave, any updates on the sensor code? Do you have it on Github?
Yes, I had updated the sensor code to introduce a little bit of hysteresis (by averaging) thinking it would help. I’m not so convinced but I’m living with it. I was trying to iron out the seemingly random readings. As for GitHub, have not got around to such a thing 
but will look to do so. Here’s the code in the meantime:
`Distance <- 0;
DistanceState <- -1;
// Distance variables
DistanceMaxReadings <- 16;
DistanceAverage <- 0;
DistanceReadingsTotal <- 0;
DistanceReadings <- [];
function ProcessDistanceByte (DistanceByte)
{
switch (DistanceState) {
case -1:
if (DistanceByte == ‘R’) {
DistanceState = 0;
}
break;
case 0: // 100's
Distance = (DistanceByte - '0') * 100;
DistanceState++;
break;
case 1: // 10's
Distance += (DistanceByte - '0') * 10;
DistanceState++;
break;
case 2: // 1's
Distance += (DistanceByte - '0');
// We have the distance from the sensor
// Have we got the minimum number of readings yet ?
if (DistanceReadings.len () == DistanceMaxReadings) { // Yes
// Remove the oldest reading, make room for a more recent one
DistanceReadingsTotal -= DistanceReadings[0]
DistanceReadings.remove (0)
}
// Calculate the new reading
DistanceReadingsTotal += Distance
DistanceReadings.append (Distance)
// Recompute
DistanceAverage = (DistanceReadingsTotal / DistanceReadings.len ()).tointeger ()
DistanceState = -1; // reSync
break;
}
}
`
@Joel “I think that garage Imp is going to also handle the lighting. I have a meter of RGB LEDs and some MOSFETs coming. From what I can tell, a meter is only going to produce about 240 Lumens, so I would need 7 to replace a 100W incandescent bulb. Can anyone provide better info on that?”
I have 30 LED bulbs in my house and I’m obsessive about ‘Lumens’. I think a typical house room would probably deploy a 60W incandescent bulb so I was looking either to replace that light output or better it. I finally chose a 7W Samsung bulb that pushed out 650 Lumens, although I tested some Philips 12W 850 lumen bulbs but they were twice the price. The only ‘room’ left to deploy LED is the garage, where i have 3 x 35W fluorescent tubes and being fussy about light output I would want to get it right. I think a single light source/bulb would not be suitable for me, and much prefer the distribution. I think for ease I’ll probably just go for direct LED replacement of the existing tubes.
Incidentally, are you considering ‘mood’ lighting with your RGB? 
It does open up all sorts of possibilities; animated (direction of travel) landing strip lights, coloured lights to signal positioning in garage (red, amber, green), weather outlook (blue: cold, red: warm, white: snow/ice)
@Dave Thanks for the code. I’m still working through understanding it, so it is a really good learning experience.
As for lighting I agree with you completely. I am in the process of replacing all of the bulbs in the house with LEDs, and wanted to start Imping them. I have flourescents in the garage as well, (that I hung), and I am realizing that it is going to be difficult to get as much light as want with LED strips. (You don’t want to be squinting in dim light when your cleaning a motorcycle carb. )
I very much want to do mood lighting in the house though… but I clearly have a lot to learn about various LED’s first. I was in Radio Shack last night, and looked at some LED strips that they have, and the package said “lasts 1000 hours”. 1000! That’s it? That’s a non starter.
Joel, you’ve got me surfing for LED strip lights! Might I suggest these:
However, it’s only 11,000 lumens ! That said, FlexFire seems to be the brightest
Nice! Looks like there is tape strip on the back. Maybe Ill have to install strips of aluminum on the ceiling and then some Flexfire.
Joel, how did it go with the inverter and the EZ4 ?
Only looked at it for a minute so far. Worked on a few other projects, and the leaves finally fell around here, so raking got in the way of imping. 
Hopefully I can hit it up tonight or tomorrow. I’ll probably have more questions.
Got it working. Thanks for the code… You just taught me a quite a few things by looking over it! Seems pretty accurate. I’m going to connect it to a Neopixel and have it change colors based on proximity to an object.
I have a Neopixel set up to show Red/Yellow/Green. Time to stick in the garage and see what happens.
Edit…
I have it working on a breadboard in the garage. Seems like it will work reasonably well for this application. I am going to run CAT6 from my Neopixel and sensor up to the garage door imp and see if things still work well over that distance. Anyone want to offer advice on what cat 6 wires I should use for GND, VCC, MOSI, and UART?
Semi permanently mounted in the garage. I used Orange for VCC, Orange-White for GND, Blue for MOSI, and Brown for UART(On the CAT6). Mounted 18 inches off the floor, and gave a 4" “Green Zone”. Wife tested and approved.
Neopixel is yellow for too far out, Green for in place, and Red for too far in.
I’m not sure if I would use that sensor for other things, like robotics, but it works nicely for this application. I’d have to do more testing.
Using a twisted pair for power/ground is likely a good thing. As neopixel is one wire, you could maybe put an additional ground on the other wire in the pair with data.
Don’t mix the UART and neopixel drive as that’ll induce noise.
Thanks Hugo. I can easily add GND to Blue/White. Should I also send GND in the pair with the UART signal? I’m only RXing from the rangefinder, never sending.
Woke up this morning and found my sensor doing wacky things, after working correctly yesterday.
@Dave, do you have yours ranging constantly? I think I may have mine only range when the garage door is open.