Garage Minder

We had a Model 3 and it was great.  Then we got a Model Y.  That is when I learnt that the HomeLink garage door opener that we had got so used to was no longer standard equipment.  So, this note describes the design of the replacement.


First, the functional requirements for this project:

1.     Open garage door automatically when the Tesla arrives

2.     Close garage door after it leaves

3.     Open garage door when it is ready to leave

4.     Turn off the Climate Control (AC/Heat) and close garage door n minutes after it is parked inside the garage (where n is configurable.)

And the implementation requirements:

1.     Do not abuse the Tesla API by over-using it.

2.     Do not add to phantom drain with excessive API calls that keep the Tesla awake.

3.     Allow configurable distance thresholds for auto opening and for closing.

4.     Allow easy set up using a phone or laptop and have a HTTP / REST interface for easy configuration & monitoring.

5.     Should not require separate power supply connection for ease of installation. (We don't have a convenient power plug.)

6.     Should sense if garage door is open or closed.  Options: Magnet/Hall effect, Tilt sensor, IR distance sensor.

7.     Be reliable, low cost and cool.

The solution described here comprises a device that monitors the Tesla's location and controls the garage door.  There are products readily available (like MyQ) that would work, but then that is no fun.  I considered building an Android app to continuously post location data to the garage door opener since I already have most of the code to do that from my Where project.  Streaming data from the Tesla will be something else to try next. 

Bill of Material

There is nothing complicated here.  I'll add more specific part details soon, along with costs & sources. 

1.     Raspberry Pi Zero W + 8 Gb micro SD  (~$15)

a.     Later, perhaps this can be replaced with an ESP-12 to further reduce costs

2.     Garage Door control stuff

a.     Relay, transistor, diodes, resistor,

b.     Magnet, Sensor, wires...

3.     Power supply (Buck converter)  OR  a 5 watt (5v) microUSB power supply.

4.     Alarm (piezo buzzer)  or  LED for alarm

5.     Housing

6.     4.5 - 6v Battery (2x CR2032)

7.     and Software, with TeslaAPI


A Raspberry Pi Zero W is used to open and close the garage door.  I did not have a convenient outlet to plug in a power supply for the Pi.  So my Pi gets its power from the existing garage opener control wiring for the wall button.  Typically, there is 24 volt AC available here, though it may be a lower voltage in older openers.  A Buck converter down-regulates this voltage to 5 v DC.  A battery allows the Pi to continue when the wall button is momentarily pressed, and the power is shorted out.  We need two diodes so that the forward drop (1.4v) stops the 6v battery from continuously discharging into the 5v power supply.  The battery is barely used, so it should last for a long time.  And if an outlet is conveniently available, then a regular 5v micro USB charger can be used.

The relay to pulse the garage door opener is driven by a transistor.  The diode shown protects the Pi & transistor from any inductive spike caused by the relay as it turns off.

The sensor is a magnetic induction reed switch.  A magnet is mounted at the edge of the garage door.  The sensor is placed close to it on the garage door frame, so that when the garage door is fully closed, the magnet will cause the sensor contacts to connect.  For this type of sensor, the magnet should ideally be positioned so that the lines of force pass longitudinally through the sensor.

The 'reset' button is used to clear alarm conditions and to reset all configurations.  The piezo alarm (or LED) is controlled by software to display alarms.


Software Version 1

The first idea was to ping the Tesla continuously and detect its arrival and departure by the pings alone.  That did not work out well.  On arrival, the Tesla would not respond to pings until it was put into Park.  So the driver (my wife) had to wait for about 30 secs for the door to open.  On departure, the Tesla stopped responding as soon as it was put into Reverse to get out of the garage.  Clearly, that is too early to close the door.  But I learnt a lot from this experiment:

1.     The Tesla responds to ICMP pings on the home WiFi LAN when it is 'online', but not when it is 'asleep'.

a.     Besides being 'online' (awake), the Tesla will respond to pings only when it is in Park.

b.     Ping responses usually take less than 200 ms on our LAN.  Occasionally, they take ~250ms.

2.     The TeslaAPI GetVehicleData will return code 408 (Request Timeout) when the vehicle is 'asleep'.  Response takes ~350ms.

a.     Need to wake it up with a 'WakeUp' API call if needed.  WakeUp takes about 15 secs.

3.     TeslaAPI also returns 408 codes briefly after the vehicle is shifted into Drive, Neutral or Reverse from Park.

a.     This dead period ranges between 8 to 40 secs.  I think this is while the Tesla is switching from WiFi to a mobile cell connection.

b.     When the vehicle is with Tesla for service, the WakeUp API call works but GetVehicleData call returns 405 (Method Not Allowed)

4.     Tesla will wake up if the door, frunk or trunk is opened.

a.     But it will eventually go to sleep even if the door, frunk or trunk is still open.

5.     The Tesla will usually go to sleep about 11 mins after the last API call. 

a.     Any API usage during that time will reset the timer.

b.     Pings do not keep the Tesla awake.  They do not reset the timer.

c.      It goes back to sleep in ~6 mins after a door is opened and closed.

d.     My Model Y takes forever to go to sleep after a drive.  Not sure why.

6.     Tesla will wake up when climate control (heat, cool) or timed charging kicks in.

a.     It will stay awake until that action has completed.  If parked outside on a hot day, this could be a long time.  To avoid this, set 'Cabin Overheat Protection' to Off (under Safety & Security).  Setting it to "No A/C" is not enough.

b.     I think climate control is on if 'right_temp_direction' or 'left_temp_direction' is non zero.  Not 100% sure.

c.      A Software Update arrival wakes it up, but it then goes back to sleep after a few minutes.

7.     The Tesla sometimes will not go to sleep.  Force-stopping the Tesla app on Android may help.  Yuck. 

a.     Perhaps we need an app that raises an alarm if the Tesla does not go to sleep for a long time. It would be useful to combat phantom drain.

b.     However, the mobile phone will not enable the Tesla for driving unless the Tesla app is running.  I had thought that its Bluetooth was enough for authentication.  Login required ?

One modification to this idea was to ping the Raspberry Pi that is already in our car.  This device is a Sentry Saver functioning as the USB drive, as described here.   It gets USB power whenever the Tesla is awake.  When this Pi stops responding to pings, it is because the Tesla went to sleep or went out of range.  We can distinguish between these two situations using the Tesla API to get vehicle's location and compute its distance from the garage.  If the API fails, then the Tesla is asleep, perhaps in the garage.  If the API indicates that the vehicle is far away, then close the door.  While the vehicle is away, we continue pinging and get no responses.  On arrival, the responses resume and we can use the API to verify the vehicle location before opening the door. 

This simple approach works, though it takes a about 40 secs to open the garage on arrival.  The Pi needs time to detect and connect to the home WiFi after arriving on the driveway.  This was not acceptable.  The driver expects better.  Back to the drawing board.

Software Version 2

Pinging the Tesla while it is at home is a good idea since it spends most of the time there.  It avoids a whole lot of TeslaAPI calls.  The next version tracks the Tesla location while it is away and opens the garage door when it gets close.  It relies on the logic developed for the Charge Minder project, described here

The Tesla can be in one of 4 states: ATHOME_ASLEEP, ATHOME_AWAKE, AWAY_ASLEEP, and AWAY_AWAKE.  There are rules defined to switch between these states and actions to perform at that time.  The actions are to open & close the garage door, and also to set timers and other state variables.  The following descriptions of states and actions have been simplified for illustration:

·        ATHOME_ASLEEP: The Tesla is in the garage (or driveway) and is not responding to pings.

·        ATHOME_AWAKE: Tesla is in the garage (or driveway) and is responding to pings and TeslaAPI requests.  The gear setting is Park.  While in this state, if it stops responding to pings, then it may have fallen asleep or is getting ready to drive away.

·        AWAY_ASLEEP: The Tesla is out of the Garage zone and is not responding to TeslaAPI requests.  The gear setting is Park.

·        AWAY_AWAKE: Tesla is out of the Garage zone and is responding to TeslaAPI requests.  The gear setting is usually Drive, but could be Park.


     if not pingable:     # still asleep

           sleep 2         # wait a bit

           return ATHOME_ASLEEP # stay in current state

            if pingable:         # it woke up


           get distance from garage

           if distance <= GarageThreshold  and  vehicleState.driverDoorOpen:

                openGarage ()

           if distance > DrivewayThreshold:

                return AWAY_AWAKE    # next state is AWAY_AWAKE

           return ATHOME_AWAKE        # next state is ATHOME_AWAKE


            if pingable:         # still awake

           sleep 2         # wait a bit

           return ATHOME_AWAKE        # stay in current state

     if not pingable:     # could have fallen asleep or could be moving

           while True:


                get distance

                if distance >= OutboundCloseThreshold:


                     return AWAY_AWAKE

                sleep 10 secs

                if pingable:               # parked again

                     return ATHOME_AWAKE



     if getVehicleData failed:

           return AWAY_ASLEEP


     if distance < InboundOpenThreshold:

           openGarage()                    # hey la, my Tesla's back

           turn off climate control

           return ATHOME_AWAKE

     t = getDriveTime()                   # use last distance & speed

     sleep t secs

     return AWAY_AWAKE

State: AWAY_ASLEEP is similar to AWAY_AWAKE, some differences in details


     if getVehicleData failed:

           return AWAY_ASLEEP


     if distance < InboundOpenThreshold:  # unlikely

           openGarage()                    # it somehow snuck back in

           turn off climate control

           return ATHOME_AWAKE

     t = getDriveTime()                   # use last distance & speed

     sleep t secs

     return AWAY_AWAKE

The function getDriveTime() estimates the minimum time needed for the vehicle to return to the garage from its current location.  The goal is to minimize API calls.  If the vehicle is not moving, the function tries to wait for 15 mins so that the vehicle can go to sleep.  When the vehicle is far away (> 3Km), the arrival time is estimated by assuming an average approach speed of 100Kmph (60mph).  For close distances, the program maintains a histogram of geohashes vs. times, which allows it to adapt and 'learn'.  The geohash is a representation of the latitude and longitude. I use a 7 digit (35 bit) geohash, with a 150 meter granularity.  The time is how long it took to get to the garage from that point.  A problem with this approach is that the times depend on the weather and the current driver.  The weather can be compensated for but I wish the TeslaAPI included the current driver's name.

The software also has a HTTP server that displays status and allows the garage door to be opened and closed manually.  All of this is working and I need to try it for a few months to determine its reliability.

Software Version 3

Next, the software will learn driving patterns.  Whenever the vehicle starts, the starting location and time-of-day are used to figure out:

·        the likely destination

·        how long the vehicle will wait at that destination

·        and when will it return from the trip

Much of this data is used to estimate the vehicles recharging requirements for Charge Minder.  But I need lots of travel data for this so this project is on hold until life returns to normal after covid...

All in fun...

--  (June 2020)