That title sounds like one from a boy’s book, a Tintin (Kuifje) or Spike and Suzy (Suske en Wiske) comic, but this blog is about Tesla, cloud computing, and hexagons.
In the middle of September 2020 Tesla suddenly blocked all network traffic originating from any of the major cloud providers, like Amazon, Google and Microsoft. A number of of third party Tesla apps were suddenly in big problems because of this, including my TeslaTasks. A lot of developers had to scram to work around that unexpected situation.
We’re down to the last piece of the puzzel; calendars are examined in a regular interval, we can tell the cars what to do, but those two need to be connected.
It is very practical to quickly see in a calendar what will be happening, and the summary field of an appointment is rendered in any view, so that is the best field to use. Other fields like description are often only visible in a detail view. Below is how I’ve currently setup my Tesla this February (which is winter).
My car goes into a security cam mode every night between 2 and 6 am, by activating sentry mode at home. And I’m making sure the doors are locked and the sun roof is closed. I could also schedule charging at that time, but I want my car to be fully charged ASAP. At weekdays I’m preconditioning the car early in the morning, which means heating up the battery and the cabine. We have a lame winter this year, so that suffices to remove any ice on the windows, but if it were really cold I’d put in “defrost”. You can see that my current schedule takes me to a different project on Tuesdays, with less driving time, so I can leave later.
In the previous post we took a look at how the initial just-for-my-own-car implementation was refactored into a version that supported many cars using a database instead of hardcoded values. It also showed that the LogicApp based implementation lost its merrits, and everything was moved into Java code. In this part we’ll take a look at the Tesla API that is used to make the car do things.
Some time has passed since my previous post about fixing the issue that a Tesla does not allow scheduling preconditioning (de-icing) the car prior to a drive in the winter. The original post used an Azure Logic app as its core.
What you see above is a Logic app for my car only; the first step “When an event starts” is linked to a Tesla calendar in my personal Google Calendar. The “StartHVAC” and “EndHVAC” call out to serverless functions that hardcoded contain the data for my personal car. And the emails go to a hardcoded email address of mine. Totally not reusable, but working.
After publishing that post, people started to ask if they could use the same functionality as well. Ahm, I did just say it was not reusable, didn’t I? But being a good friend, I ventured out and rewrote the whole thing to support multiple calendars and cars.
The last few blogs had a “not my usual content” text here, but this one is about software development. As it turns out Tesla is missing a -for me- very critical piece of functionality; being able to start the airconditioning (AC) system at a certain time. It is possible to turn on the AC immediately via the app using the fan icon (see the image below), but not automatically at 06:00, while I’m still counting sheep in my bed.
But to my amazement, every Tesla car is accessible via the internet through a REST API. This API is what the Tesla app uses to access the vehicle. Using this API is not officially supported, but Tesla does not seem to mind people accessing it.
Okay! That is interesting! I’m a software engineer, I can handle a REST API…
