that is gonna be an issue, indeed, i’m assuming they want the expensive SSL organisation verification crap. If this is the case, a site provided by an open source code-site might not be enough.
Maybe it might be more interesting to combine with others and find a way to fund this as a group of people. maybe do FAAAS (Fleet API As A Service)
thanks, the link worked!
I think I now remember how I solved this. Instead of buying a certificate for my server, I routed the traffic through Cloudflare, which terminates HTTPS on their side using their own certificate.
Preparing for the Jolla Phone 2, I’d like to remote control my Tesla via Home Assistant. But I don’t have a Webserver, and the Home Assistant server is only available locally (on purpose). I found some advice to use TeslaMate to obtain the Fleet API key, but failed miserably. Or the HA integration did. Whatever… 
Basically it’s all about pre-cooling, pre-heting and starting/stopping/configuring the charging at home for me - happy to use the card to open and start the car - whatever it takes to get away from Android.
What are my options? Get a webspace with SSL and try again? Or is there a trusted service to remote control the car via the web browser on SailfishOS?
I only know the trusted webserver route to obtain a fleet key. I then use my native Sailfish app (mentioned in this thread further up) to control the Tesla, but I think you could use GitHub - teslamotors/vehicle-command · GitHub to control it from Home Assistant once you have the key.
Uh, oh, I overlooked the fact that you created a native app - even better!!! 
So I’ll get the smallest web space with SSL certificate I can get and try to get the fleet API key.
I gave up - for whatever reason I was not able to get the Fleet API set up. When investigating all kinds of approaches I stumbled over “Teslemetry”, bit the bullet and forked out some cash - using their services I have now full access to my car via Home Assistant, including unlocking and driving even without the access card. Awesome. Obviously there is a security risk by trusting the 3rd party, but at least it’s just a Tesla, nothing important. One step further away from Android!
Following this post by @Gepardi55 where they mention building an app for their Ford EVbased off a pypi package, I thought to check if there were any similar packages for Toyota.
Lo and behold there is!
Pytoyoda lets you use your MyToyota (which incidentally does work in AppSupport) credentials to access the service. The simple client provided doesn’t yet have the full capability of the app, but you can retrieve the status of the vehicle (with accuracy at 3dp rather than 1dp in the app), and it will perform some calculations on new and existing data.
e: pytoyoda only supports the European service, there is toyota-na for NA
@cypherpunks did you managed to publish your Tesla app?
I’ve sent it to someone from this forum who wanted to try it at some point, but it requires a fleet key, etc., and it has things like hard-coded VIN numbers in it. So it’s not something I can simply release without putting some more work into it, which I didn’t do because it seemed only marginally useful to anyone else.
I think it could be very useful for a lot of people, for how big the overlap between Tesla and Jolla could be.
I tried building my own, I’m still testing it, it only goes via bluetooth, but I’m a Rust developer, I know little about C++ and Go, so I had to rely to 3 different LLMs to sanity check everything, and I still don’t like it (as much as I don’t like LLMs).
I found out the approach is similar to your, I’ve isolated the tesla-command via dbus to keep the frontend app clean and sandbox-compatible.
I can DM you the code if you want to take a look but It’s not something I can release quickly.
FYI: The Tesla Android app seems to work on the new Jolla Phone 
I haven’t actually driven it with the Jolla as key yet, but I do get the “Model 3: connected” notification whenever I’m close to the car and the unlock/open frunk/open trunk/flash lights/etc commands do work.
It took a little more work to get running than on actual Android though - first the login stopped at the end when it navigates to a tesla:// -protocol URL, the native SFOS browser didn’t know what to do with that. Then I installed Android Chrome, and with that the login page ran inside the actual Tesla app. Then there was a part that didn’t work automatically, I had to enter some code and tap my key card inside the car before it would connect.
If someone could make a “Tesla Daemon” kind of app, that’s only a native backgrounded service that makes the phone act as a mobile key, I’d definitely go with that though. It wouldn’t even need an interface at first, other than the initial setup to get the credentials. @nappa85 ‘s project looks very interesting!
I’ve already tried it, it’s unreliable, sometimes it connects, sometimes not, I ended up having to start the car from the phone because it wasn’t seeing my phone while I was in the car", that’s why I’m working on the native app.
@cypherpunks if you could DM me the code, I don’t have much free time and debugging why the daemon doesn’t work is taking me so much time (and it’s probably something really stupid)
Did you have all the Android permissions enabled? All that background stuff needs to be enabled even on actual Android phones and on some it’s less reliable than on others because of all the battery optimization crap some vendors do. For example on Samsung it’s pretty reliable but on my wife’s previous Xiaomi she always had to do everything manually from the app (she’s got a Samsung too now).
Anyway, I’ll help test that application once you get it sorted! I could help with the code too but I don’t have any experience with said stack or programming languages even, so I’d also just be slamming an LLM on it 
My application is working now. It’s for sure graphically worse than @cypherpunks’ one, but I can improve.
Just to sum up things, if you don’t want to read the LLM-generated readme:
Feel free to copy what you need. 
The 2-part system seems to be a common style in various Sailfish apps. For example Situations also has a separately installable daemon part. It makes sense, but IMO the Sailfish developers should make a unified way for sandboxed apps to install a background daemon.
Oh yeah and I noticed today how unreliable the Android app is on SFOS. It just straight up refused to start this morning, which is of course unacceptable for such a critical thing. Turns out the bluetooth stack had crashed, and it started working again after restarting it. Hopefully the native app will be a little more gentle with it
I’ll test the app and I’ll see what I can do to help out!
Do you have the bluetooth audio working on your Tesla? I’m having quite a lot of problems with it.
Today I’ve been able to successfully pair for the first time, but music was still coming from the phone, even if the car was correctly reporting track name and progress
I haven’t tested it yet, I use a mobile hotspot + the car’s own Spotify app usually. But I’ll test it when I get a chance.