GarageMinder
We had a Model 3 and it was great. Then we got a Model Y, and I learned that the HomeLink garage door opener that we had got so used to was no longer standard equipment. This note describes the design of a replacement, which turned out to be surprisingly challenging due to unexpected issues. We describe the final design first and then discuss the lessons learned.
Requirements
First, the basic functional requirements for this project:
1. Open the garage door and turn off the Climate Control (AC/Heat)automatically when the Tesla arrives. The door should never open erroneously.
2. Close the garage door (reliably) after the Tesla leaves.
3. Expose a web-accessible interface to operate and monitor the garage door, and to configure various parameters.
There are three ways to detect a Tesla: Bluetooth, ICMP pings and the Tesla API. I found that pings and the Tesla API (pre-Fleet) are not reliable enough to open and close the door safely and reliably. 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,
Hardware
A Raspberry Pi Zero W is used to open and close the garage door. It has an external antenna, though
There is nothing complicated here. The total cost is less than $40.
1. Raspberry Pi Zero W + 4 Gb micro SD (~$15)
a. Later, perhaps this can be replaced with an ESP-32 tofurther reduce costs
b. An external antenna helps
2. Garage Door control stuff:
a. Relay, transistor, diodes, resistor,
b. Magnet, Magnet sensor, wires...
3. A microUSB power supply (5v 10w) or a Buck converter
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 'door closed' 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 activate the sensor. For this type of sensor, the magnet should ideally be positioned so that the lines of force pass longitudinally through the sensor.
The 'door open' sensor is mounted on one of the door panels. When the door is open, the panel becomes horizontal and a tilt switch powers on a BLE beacon. The signals are detected by the Pi. When the door is closed, the beacon will be powered off and its battery should last for years. It is not essential to have this sensor, the 'door closed' sensor can be good enough.
The 'reset' button is used to clear alarm conditions and reset all configurations. The piezo alarm (or LED) is controlled by software to display alarms.
Software Version 1
When the Tesla is at home, it connects to the WiFi LAN to download software & map updates. It's IP address can be easily determined. The first idea was to ping the Tesla continuously at its WLAN address to detect its arrival and departure. That did not work out well. On arrival, the Tesla would not respond to WLAN 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 learned 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. When it is in Drive or Reverse, it switches to the cell phone network.
b. Ping responses usually take less than 200 ms on our LAN. Occasionally, they take ~250ms. Fewer than 1% of pings are lost.
c. The TeslaAP Ineeds communications between the Tesla server and the vehicle. It uses the WiFi LAN when available, or the vehicle's cell phone network when a LAN is not available.
2. The Tesla API GetVehicleData will return code 408 (Request Timeout) when the vehicle is 'asleep'. Otherwise, the response takes <950ms.
a. A 'WakeUp' API is available if needed. WakeUp usually takes 11-15 secs.
3. TeslaAPIalso 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 the GetVehicleData call returns 405 (Method Not Allowed)
4. 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.
5. Tesla will wake up if a door, frunk or trunk is opened.
a. But it will eventually go to sleep even if the door, frunk or trunk is still open.
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 stay awake forever. 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 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, with Bluetooth
The Tesla continuously broadcasts Bluetooth LE advertisements, even when it is asleep. These can be used to detect the presence or absence of the Tesla. A transition from absence to presence indicates an arrival and the door should be opened, while a transition from presence to absence indicates a departure and the door should be closed. The Pi detects the BLE signal of the arriving vehicle about 30 meters away. This sounds easy in theory, but there are many issues in reality:
· Though there are several (~10/sec) BLE advertisements transmitted, many get lost due to collisions. Also, the Pi may not be able to keep up with the transmissions and may drop some.
· There is a lot of jitter in signal reception during vehicle arrivals & departures. This needs to be smoothed out.
· Even when the vehicle is peacefully asleep in the garage, the signal frequently gets lost for several seconds, falsely indicating a departure. I initially suspected the Pi's Bluetooth hardware, so I set up two separate receivers. Both saw similar dips and losses, which indicates that either something is jamming the 2.4 GHz spectrum or the Tesla is not broadcasting steadily.
· The Tesla API is not a reliable way to verify a departure, because the API seems to not work for the few critical seconds after the vehicle starts. ICMP pings are a good way to verify departures: the pings should have stopped only recently, less than 3 minutes ago. This is the time between when the pings stopped because the Tesla was moved out of Park and the time when the BLE signal was lost because the Tesla went out of range. I also tried maintaining moving averages of BLE signal strengths (RSSI). The idea is that a departing Tesla would show a distinct drop-off in signal strength.
· Software updates cause the Tesla to stop broadcasting the BLE signal for about 2 minutes, probably while rebooting. When the signal is restored after the update, it could falsely indicate an arrival and cause an undesired garage door opening.However, we can use the API to verify that the vehicle is moving nearby before the door is opened for an arrival.
The software has an embedded HTTP server that displays status, allows the garage door to be opened and closed manually, and allows more configuration. Sometimes it takes several seconds after the car leaves for the software to detect the loss of BLE signal and close the door. This leaves us wondering if the garage door is closed. So the software sends me an SMS message when the door closes. The web page also shows the current state of the door and a history of the last few actions.
This solution is not limited to Teslas. Other vehicles (and bicycles too) could carry a BLE beacon. However, I would use a long-range beacon and power it using the vehicle.
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 vehicle’s 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.
Web Server
A web server on the Pi supports opening/closing the garage door, displays Tesla status and distance, locks the doors, turns the climate control on or off, etc. Port forwarding and Dynamic DNS allow the server to be accessed from the Internet.
The Genii Hack
Also check out a related project: https://pejaver.com/Projects/GeniiHack.htm
All in fun...