(P)Imp my Garage

I’m §Imp’ing my garage, like most, but going one step further; with parking assist. In my design I have an Imp looking after the garage door, handling status (open/closed), and actions (Open/Close). This first Imp will also be talking to a Fibaro home automation controller. The second Imp is driving a dot matrix display, connected to a MaxBotix EZ4 distance sensor, to indicate how close the car is to the rear garage wall, with a traffic light effect to indicate when the car is safely in the garage. However, I also want the latter Imp, to be cognisant of the door status.

What’s the recommended pattern for having two Imps speak with one another (Agent <-> Agent ?). Any way of sharing one Agent amongst two devices ?

Many thanks…

I think you will need to send requests to agent urls like you would with any other web service. Sharing isn’t possible to my knowledge. Please keep us posted with your results… I have been thinking about doing this myself. My garage is pretty full, so knowing exactly how far in the car needs to be would be very handy. How many pins will the distance sensor need? I still have 3 remaining on the April breakout that handles my door opener and sensors.

Do you have the rangefinder talking to the imp?

Yes, the range finder is talking to the Imp. I bought the slightly more expensive EZ4 which i) has a serial output, ii) a narrow beam. It has a minimum sensing of 20cm, maximum of 7m (so I’ll be able to tell when the car has left the garage), and, is accurate to 1cm. It gives a reading at about 10 a second and transmits “Rnnn” for how many centimetres. So, it only needs +Ve, Gnd and Serial Tx. Essentially one I/O.

I did think about loading everything up onto one Imp but then didn’t want signal wires traversing the length of the garage and it seemed more logically to separate the functions.

The display matrix is two of these cabled side by side, and, to simplify driving it, the use of a driver module board, which drastically reduces the pin requirement to just a UART.

The LED matrix boards, can, at a maximum, when one row of LEDs is lit, draw 4 amps, and given that I have two, that’s possibly 8 amps! It then caused me to think that I don’t want the display on all the time, so I then introduced a PIR (talk about scope creep!). I chose this Sparkfun PIR. It’s somewhat erratic so I just may ditch it’s use.

It’s all breadboarded at the moment, but hope to move it to the garage shortly.

Where are you mounting the rangefinder? Depending on the time of year, I park two different cars in the garage bay that I want to sense…so I need to sort that out as well, since they are different lengths. I really just want to know when the car is just past the door, so I thought about installing an infrared beam that would shoot up at an angle so it would be tripped by a rear bumper at any height. Do you have code for the rangefinder? Also… I see EZ models on the Maxbotix site, but not EV.

Whoops… yes, it’s an EZ4

I haven’t mounted the range finder yet, but was thinking of bumper level. The code looks like this:
function DistanceSensorEvent ()
// Read the first byte from the buffer

local DistanceByte = DistanceSensor.read ();

// Cycle round until we've emptied the buffer

while (DistanceByte != -1) {
    ProcessDistanceByte (DistanceByte);
    DistanceByte = DistanceSensor.read ();


function ProcessDistanceByte (DistanceByte)
//server.log (ProximityByte.tochar ());

switch (DistanceState) {
case -1:
    if (DistanceByte == 'R') {
        DistanceState = 0;

case 0: // 100's
    Distance = (DistanceByte - '0') * 100;

case 1: // 10's
    Distance += (DistanceByte - '0') * 10;

case 2: // 1's
    Distance += (DistanceByte - '0');
    if (--DistanceReadings == 0) {
        server.log ("Distance: " + Distance.tostring () + "cm")
        DistanceReadings = 10;
    DistanceState = -1;  // reSync


DistanceState <- -1;
DistanceSensor <- hardware.uart12;
Distance <- 0;

DistanceSensor.configure (9600,8,PARITY_NONE,1,NO_TX,DistanceSensorEvent);`

I’m trying to think what angle would work from the rear. For the same car length, mounting it to hit the front of the car would be easy. If you mount it in the rear of the garage, would you be sensing when the car was fully past, ie, when the range became the opposite wall?

I’m not sure that the beam would be narrow enough, unlike a laser, etc. I think you’d probably find that the car bumper would have to be another foot or so past the direct line to the opposite wall. I went through the whole thinking of ‘detect at the rear’ or ‘detect at the front’. The LED/laser solution at the rear seemed fraught with problems associated with strong sun, etc, so just went with detecting at the front, and, I only have a one car garage.

Ahh ok… I think that is the best solution. Maybe I’ll have to have my Imp sense which car is in the bay. :slight_smile:

The prototype is now in the garage. There are reed switches attached at the bottom of the roller shutter door and at the bottom. I’ve tied one side of each reed relay to GND and the the other side to Pin 8 (Door Open) and 9 (Door Closed). Each pin is configured as DIGITAL_IN_PULLUP with an event handler.

I have a server.log in the event handler, and, with no garage door movement, I’m intermittently seeing the events firing, but when I read () the pin, it’s the same value, whereas the documentation suggests it only fires when the state changes.

Are there any other circumstances that the event fires ?


The shortest pulse that will fire the event, is much much shorter than can be read from Squirrel – i.e. if the line goes low for, say, 5us, then it will have gone high again by the time the Squirrel event handler is running. So a loose connection causing glitches, could cause those “phantom” events.


seems like noise on the signal. Classic solution is an RC filter. What value do you get when you say “it’s the same value” - high?

After you see the event you could do a digital read to verify the signal has changed - depending how long you expect the switch state to be different. You can also search for de-bounce techniques because you may also need to do this given you are using a mechanical switch.

I had exactly the same problem with my security system sensors, since the runs were very long. My garage door sensors are up at the opener, itself, and are very short so I don’t see the problem there. and RC filter will work, but I just added a checking filter in software. I kept track of the state of each sensor, and if I got a callback, i would check it against the known state. Is there any chance you could put your sensors at the opener? My opener had switch sensors that were used by the opener itself, and I just piggy backed off of that mechanism. The lift chain would flip two arms at open and closed.

This is what I did for the sensors in my security system.

Thanks for the ideas. A couple of things I guess are possible; a) I’m using telephone cable (2 pairs) and it’s quite a small gauge of wire, so possibly that’s intermittent in the breadboard, b) the run to the sensors in probably about 7m and quite possibly picking up some noise.

As a first step, I’ve soldered the ends of the wire onto a DIL pins, so connections are all good now. However, in the few minutes that I’ve been typing this reply, I can see that it’s still triggering. Pins 8 and 9 are both going high (pull ups) intermittently randomly.

In terms of distance, I have the distance sensor at the back end of the garage, and the reed relays on the door. The breadboard is near the distance sensor. I had originally thought about two Imps, one for the door and one for the distance + display.

The RC filter is interesting, let me look in to that also.

Hugo suggested adding stronger pull-up resistors on the sensor lines as well… Here is the discussion on mine.


At the moment I’m using the internal Imp pull-ups, but that is a thought using external ones instead and configuring the pins as DIGITAL_IN. In the interim, I’ve tried my own RC filter, using no ‘R’, only ‘C’ :smiley: . I used a ceramic capacitor of 0.22uf between the pin and Vcc, and, touch wood, no interference as of yet. The only thing I’m left with at the moment is contact bounce from the (mechanical) relays but that’s expected, and I’ve been looking at your code jwehr for some ideas there.

Just some in the field information on the Maxbotix EZ4 ultrasonic distance sensor. I’ve employed an algorithm that averages out the last N readings. It’s currently set at N=8 to try and smooth out any random readings. I have previously set it at 32 but the updates start getting slower. There’s obviously a fine balance.

Additionally, the sensor is mounted 50cm off the garage floor, which is the height of the bumper on the car. It seems to work well when the car is within 400cm, but beyond that, it’s getting rather random readings. I’m wondering if this can be attributed to reflections off the garage floor, what with the sensor being mounted so low.

However, I can confirm that with the car 149cm from the rear wall, it is just possible to shut the garage door. :slight_smile: Additionally, my wife is now religiously using the red/amber/green LED traffic light so I just need to ensure no software bugs going forwards !

That is music to my ears! I might have to install one to display correct distance left and right. I have shelving and workbenches all over my garage, so proper parking in the sweet spot is crucial for getting in and out easily. Please keep sharing your findings.

I think that would be the ideal situation as I have ladders, plasterboard, timber, etc down both sides of the garage, so sensors on both walls, and one on the rear.

I’ve now introduced a sleep mode such that when the door is shut, after 30 secs the display goes blank. But, if someone walks between the sensor and the (reducing the distance to < 110cm), the display will activate for another 30 seconds or until the door is opened.

A whole day has gone by and no interference or spikes on my 7m of cable to pins 8&9, due to the 0.22uF capacitors.

I have used a button filter class to debounce signals like you get from the contact of switch. An RC filter may be all you need, depends on how noisy the contact points are and the quailty/integrity of the materials in the switch.

Here is a link to the class, it allows you to tune how long to wait for a valid switch event to appear. Hope it helps.

@fliphunter, many thanks for the class, it was the way I was thinking I needed to go. The RC filter I have has cured the interference/spikes that the wire was picking up, but, had decided to go software to cure the bounce. Great stuff.