Once again it’s been some time since I last posted. Hopefully I’ll speed up a bit in 2025 as I have a few projects going on. Anyway, if you haven’t signed up, please do. You won’t get any spam, just notifications of new posts. Hope you enjoy this one!
Earlier this year, we changed our hybrid Hyundai Tucson for a Tesla Model 3 dual motor (second hand I hasten to add).
[I’ll take a short detour here to explain what happened, skip forward if you’re not interested. We decided to replace the Hyundai and my initial thinking was to dip my toes into the EV world with a plug-in hybrid. However, the more I looked into the options, and we were only ever considering a low mileage second hand car, it became pretty obvious that a full EV was probably the best choice. You hear lots of the anti-EV brigade going on about EV depreciation but they forget that, for second-hand buyers, the more depreciation the better! And I found that you could buy what was a £50,000+ car new for around half that price at little over two years old. Happy days!
In the end, I narrowed the choice down to a Tesla Model 3 dual motor long range for its long range and the Tesla super charging network. This was before Elon went completely nuts and the only good thing is that by buying second-hand he gets none of our money!
By the way, we sold our Hyundai Tucson using Motorway as they were offering the highest price.]
With the new car, I thought I’d simply take the mini wireless D1 module out of the Tucson, plug it into the Model 3 and the mechanism I’d described in my post below would work. What could possibly go wrong?!
What did go wrong!
To be fair, everything worked as it should, although not as expected!
Ignoring the minor annoyance that the Model 3 only has USB-C ports, I found that its ports would come alive at random times1, not just when someone got in the car. So the gates could open at any time, even at three in the morning. Relying simply on the mini wireless D1 module was not an option. I had to find a more fool proof algorithm.
Is there anybody in there?
It seemed obvious that, probably combined with pinging the mini wireless D1 module, I needed to detect when someone was in the car (which, after all, is what my previous approach effectively did - detecting when the ignition was turned on). Fortunately, there’s a Home Assistant (HA) Tesla integration that connects with the Tesla cloud service (like many cars today, Teslas connect to cloud servers through which apps and APIs can control and get information about the cars) and exposes a host of entities through a series of HA controls and sensors (see the figure below for the sensors).
The eagle eyed among you will have spotted the User present binary sensor. This is off if a user isn’t in the car and on if someone is in it (more strictly, if the car has detected a user’s device - key card or phone). So I extended the NodeRed algorithm in my original gate control as follows:
Wait for a successful ping to the mini wireless D1 module (as before).
Using the HA Tesla integration, poll the car to update its sensors (they are not “live” sensors and the car needs to be polled to get their latest states).
Inspect the User present sensor to see if anyone is in the car (or is it a random wake of the car’s USB ports with no one in the car). If so, open the gate!
Steps 2 and 3 are repeated three times (to allow for any delays in the sensors being updated). I have a wait of 20 seconds between each repeat to allow the car to contact Tesla’s servers.
If, after the three repetitions, there is no one detected, then give up. The USB ports must turn off as this algorithm is triggered by the successful ping of the mini wireless D1 module after failed pings.
Note that polling Tesla’s servers through the API is rate limited, hence my arbitrary limit of three repetitions with a 20 second delay between each repetition before giving up. Ideally I’d be polling much more frequently and more often.
Too fast and too slow
This algorithm had its good and bad points:
It worked perfectly when arriving home. The mini wireless D1 module is quickly detected when within range and the poll of Tesla’s servers usually returns a user present at the first time of asking. The gates therefore open promptly when we pull up in front of them.
However, the departing procedure would often be like a Benny Hill farce (without the theme tune!). Often, you don’t simply get in a car and drive away, you might set the sat nav, arrange your handbag (grrrr), empty pockets etc. All of which take time. However, the algorithm takes no account of this and will open the gate when it wants. So often it’d be a race to beat the gate and quite often not even bother and so having to open the gate through the HA app or the key pad on the wall!
I mitigated this a little by delaying the opening of the gate but, as there’s no way to easily work out if one was arriving or departing, it meant when arriving you’d sit at the gates for several seconds before they’d open.
I wanted a better solution and now I think I’ve found it!
Shifting up a gear
In the forest of sensors the HA Tesla integration provides, I recently noticed the one called Shift state. Assuming it behaves as you’d expect, and my tests showed it does, I could use this instead of user presence detection. Its value is one of N, R, D depending on what is selected and is always N when you get in the car. So now, rather than checking if there’s a user in the car, I check that the car is not in N.
Moreover, as the car connects to my WiFi, I don’t actually need the mini wireless D1 module, as long as I give the car a static IP address, HA can ping it instead.
My updated algorithm using this sensor and pinging the car now looks almost identical to before. I’ve repeated it here for ease of understanding but without some of the detail:
Wait for a successful ping to the car.
Using the HA Tesla integration, poll the car to update its sensors.
Inspect the Shift state sensor to see if the car is in N. If NOT, open the gate!
Steps 2 and 3 are repeated three times with a wait of 20 seconds between each.
If, after the three repetitions, the car is always in N, then give up.
Top gear
This new approach works as I want:
When departing, you get in the car but only take it out of N when you’re ready to depart. The gates open shortly afterwards (of course if you delay longer than the three repetitions, then you’ve missed your chance!). There is now no need to delay the opening of the gates.
On arrival, the gates are opened more or less immediately as the delay to avoid the Benny Hill farce is no longer needed.
I’m happy with this but if you can think of a better way, please let me know in the comments below.
In all the time I’ve had the car, I have been unable to find any rhyme or reason for when the ports become live!
The Tesla broadcasts an iBeacon all the time. I use an esp32 in the garage to see if the car is located there. Connected to the same esp32 I have a sonar, this used the distance to tell if the car is in the spot. Between these 2 sensors I have the garage door opening and closing quite well. I also put an iBeacon in my old truck and get all the same advantages.