Yet another selfhosted Teslog/Teslafi alternative

Servus,

ich hab da mal was fertig gemacht:

[url]https://github.com/lephisto/tesla-apiscraper[/url]

1508×951 129 KB

1515×950 107 KB

Motivation war, einen Telemetrielogger ohne proprietäre Komponenten im Toolstack zu haben, welchen ich auf meiner eigenen Infrastruktur hosten kann (VServer, Raspi etc).

Basiert auf InfluxDB, Kapacitor, Grafana und ein bisschen Python (Danke auch an cko für die Inspiration)

Verfügt über eine erweiterte Sleeperkennung, dH das Fahrzeug muß nicht durchgehend online sein und der Logger bekommt frische Daten auch direkt mit, wenn das Fahrzeug durch öffnen / losfahren wieder aufgeweckt wird.

Alles weitere steht im Github readme.

Wie hast Du das hinbekommen?

Die Owner API hat im Zusammenspiel mit der Mothership API ein paar Eigenheiten. Wenn das Fahrzeug abgestellt wird und nicht lädt, man aber weiterhin die API abfragt, schläft es erstmal nicht ein. Fängt man an, die Abfragen graduell zu throttlen schläft es irgendwann ein. Von dann an kann man bestimmte Teile der API sooft abfragen wie man will, ohne daß das Fahrzeug aufwacht. Wacht es wieder auf, kann man die Abfragen auf den vollen Telemetriedatensatz erweitern, und hat somit wieder alle Messpunkte.

Danke. Das war mir soweit bewusst glaube ich. Aber auch hier hast du das Problem, dass dir mitunter Daten verloren gehen können in der Zeit wo du polling reduziert hast um ein einschlafen zu ermöglichen, oder?

Ja, in der Phase, in der das throttling bis zum einschlafen erhöht wird, kann das passieren, das sind so um die 20 Minuten. Danach nicht mehr.

In Planung ist dafür allerdings noch eine App, mit der man das resetten kann, falls man unerwarteterweise in der ersten Minuten nach abstellen oder Ladeende wieder losfahren will.

Danke - schon mal angefangen zu installieren…
Nach der installation von influxdb (telegraf) auf dem Raspi gibts aber kein „influx“ binary - muß man da noch was dazu installieren?

Edit:
curl -sL repos.influxdata.com/influxdb.key | sudo apt-key add -
echo „deb repos.influxdata.com/debian stretch stable“ | sudo tee /etc/apt/sources.list.d/influxdb.list
sudo apt-get update
sudo apt-get install influxdb

…danach ging es, ohne den Tesla komm ich jetzt aber nicht weiter

Ja, Influx am besten immer aus den Vendorrepos installieren…

Gibt apt-get update einen Fehler aus?root@teslaapi:~# apt-get update [...] E: The method driver /usr/lib/apt/methods/https could not be found. N: Is the package apt-transport-https installed? E: Failed to fetch https://repos.influxdata.com/debian/dists/stretch/InRelease E: Some index files failed to download. They have been ignored, or old ones used instead. Ich musste bei mir https für apt nachinstallieren, damit er die aktuelle influxdb runterläd und installiert:

apt install apt-transport-https apt-get update apt-get install influxdbSonst hat er eine uralte Version aus dem debian-repo genommen, die ohne das CLI daherkam.

Meine Frage: In welchem Verzeichnis führt ihr diesen Befehl aus? git clone https://github.com/lephisto/tesla-apiscraper

Traditionell installiert man Software, die nicht vom package manager der Distribution verwaltet wird, in ein Subdir in /opt.

Hallo zusammen,

kann vielleicht jemand hierfür ein fertiges Raspi-Image erstellen?
Das wäre prima

Vielen Dank & Gruß
Peter

Um das Insomniaproblem zu lösen habe ich gerade noch eine andere lösung in der Arbeit: Eine MIni-app, die sobald es den Tesla per BT sieht, das scraping wieder aktiviert. Toller fände ich eine bessere API, aber anders gehts gerade nicht.

Das schaut dann in etwa so aus:

apiscraper_app.png476×919 44.1 KB

Perspektivisch könnte man damit über die Grafana API auch ein paar Graphen abfragen…

Sehr Cool!

Super Projekt. Toll wäre, wenn die App sich selbst startet wenn das Telefon in Reichweite vom Tesla-Bluetooth ist, und auch wieder selbst beendet, sobald nicht mehr in Reichweite, so wie das z.B. die „Blitzer“ App von TomTom macht.

Das ist der plan. Erstens als proximity Sensor um das scrapen einzuschalten wenn der apiscraper gerade versucht das Fahrzeug einschlafen zu lassen und zweitens (optional) um can bus Daten von einem elm Modul welches über bt verbunden wird und mit einem Adapter kabel am diag port hängt, ebenfalls zu erfassen und visualisieren zu können…

Sehr cool, funktioniert. Danke.

Des schaut ziemlich cool aus. Am besten gießt man das Ganze wohl mal in ein Docker-Image, macht das upgraden und sichern einfacher.

EDIT: Ich würde mir das mal ans Bein nageln ein Repo mit einem Raspberry-Pi Docker-Image zu erstellen.

Sooooo, ich war mal fleißig am Wochenende:

github.com/markusdd/tesla-apiscraper-rpi

master branch verwaltet das ARM image für Raspberry, der amd64 bietet auch eine Debian Variante für normal X86/AMD64 an.

Alles automatisierte builds, die images finden sich direkt auf Dockerhub:

ARM-Image:
cloud.docker.com/u/markusdd/rep … craper-rpi

x86/AMD64 Image:
cloud.docker.com/u/markusdd/rep … apiscraper

In der README.md stehen die nötigen volumes, im endeffekt müsst ihr für die persistenten Daten /var/lib/grafana, /var/lib/influxdb und die config.py reinreichen/rausreichen.

Die Dashboards müsst ihr nicht manuell importieren, das macht der Container automatisch.

Beim ersten grafana strat müsst ihr noch die datasource manuell setzen, einfach localhost:8086, database tesla, kein passwort. Die Influxdb wird nicht exposed außerhalb des containers, also muss man da nix seperat absichern, da kann nur Grafana intern mit reden.

Docker ist nun auch im Master, ebenso noch ein paar neue Features…

• Android App für Scraper remote Control
• Elevation Tracking
• Umbau auf Multithreading

Derzeit in Arbeit:

ELM OBD2 Modulschnittstelle

So, das ganze nimmt nun Form an, anbei ein paar kurze Erklärungen.

Hier erstmal das Komponentendiagram:

Component_Diagram.png985×292 21.3 KB

Der Obere Zweig ist stable und funktioniert mit Model S, X und 3. Die Logik ist wie folgt:

Scraperdaemon wird gestartet. Je nach Config fängt er sofort an die Owner API abzufragen, oder wartet auf Befehl durch die App (a_start_disabled).

Der Befehl an die Scraper-Api durch die App kann manuell ausgelöst oder durch einen Bluetooth Connect auf das Fahrzeug automatisch getriggert werden. Verlasse ich das Fahrzeug bzw kommt es zu einem Bluetooth Disconnect kann ich nach einer vorgegeben Karenzzeit automatisch das scrapen beenden. (Die Karenzzeit beugt unbeabsichtigtem Bluetooth Disconnect vor (Akku Leer, Beifahrer koppelt sich etc). Der Timeout kann immer manuell abgebrochen werden.

Übergangen werden kann das „disableScrape“ Kommando ebenfalls durch Ladevorgänge. Das heisst, wenn ich das Fahrzeug irgendwo anstecke und mich entferne, der Python Daemon aber einen Ladevorgang mitbekommt, läuft der Scraper weiter, bis der Ladevorgang beendet wird.

Ist ein fahrzeugseitig scheduled Charging eingestellt, fängt der Scraper zum geplanten Zeitpunkt an, die API abzufragen.

Main.png1080×1920 102 KB

Settings.png1080×1920 63.1 KB

Wer die Scraper Api mit der App nutzen will sollte diese auf jeden Fall per Reverseproxy hinter einem Webserver verbauen, da der http-thread im Pythondaemon kein SSL implementiert hat, und somit der Scraper Api Key im Klartext durchs Internetz fliegen würde. Weiterführende technische Infos gibts auf GH.

[url]https://github.com/lephisto/tesla-apiscraper[/url]

App:

[url]https://play.google.com/store/apps/details?id=to.mephis.apiscrapercontrol[/url]

Der CAN3/OBD Teil ist optional, und derzeit nicht im Produktivrelease, ich warte derzeit noch auf mein OBD2 Kabel zum testen. Hier wird man interessante Detaildaten zu den Batteriemodulen, BMS Metriken, Beschleunigungswerte, AP-Status etc. über die restlichen Metriken legen können, die aus der Owner-API fallen. Die Daten werden über die RestAPI in den Scraperdaemon übertragen und von dort aus in der InfluxDB landen, von wo aus sie dann im Grafana visualisiert werden können. Voraussichtlich wird dieser Teil erstmal nicht im Model 3 funktionieren, da noch kein Zugang zum CAN Bus gefunden wurde.

besten gruß