Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Model 3: Geek mode (CANbus, OBD2)

This site may earn commission on affiliate links.
#61
ramonneke said:
Een Obdlink MX+ is onderweg omdat m'n El Cheapo ELK 327 niet werkt bij mijn Model S (wel in onze voorgaande auto's). Daarnaast heeft de el cheap OBD2 Bluetooth adapter pincode 1234 wat mij niet zo zint.

Wat ik wil doen is:


OBD2 => (bluetooth) => Android App => Queue => Processor

Hoe werken die OBD2 adapters? Is dat een firehose waar je *alles* krijgt of definieer je soort van filters die de OBD2 adapter matches en enkel die via bluetooth stuurt?

De Android app wil ik eigenlijk maar de volgende taken laten doen.

- OBD2 data toevoegen aan ringbuffer
- Indien ringbuffer vol of een timer is gepasseerd, binary copy, compressen, toevoegen aan dispatch wachtrij
- Dispatch wachtrij bevat chunks die elk afzonderlijk verstuurd/gepubliceerd moeten worden naar een queue

Belangrijk is dat als er *geen* verbinding is dat de app local storage als buffer moet gebruiken en dat als de mobiel restart deze data niet weg mag zijn.

Natuurlijk kun je dat nog een storage limiet hanteren op basis van max bytes or max age of een combi.


Ik zelf dacht er aan dit publiceren af te handelen middels MQTT. Het is lightweight en lijkt me goed passen. Ik heb enkel geen Android dev ervaring maar misschien zijn er al goede apps die zoiets al doen.

Iemand ideeen/tips?
Click to expand...

Hoi Ramon

Leuk dat steeds meer mensen zich hier mee gaan bezig houden, ik ben er de laatste weken ook erg druk mee.
Het is flink prutsen en uitzoeken maar begin hier al wat succesjes te behalen.

Ik had in eerste instantie ook de OBDlink MX-wifi, maar die heb ik teruggestuurd. Wat een onstabiel kutding.
Forum van obdlink staat er ook vol mee, het is een known problem. Blijf weg bij deze adapter.
De MX+ waar je het over hebt is in feite een LX maar dan met de certificering voor apple, zodat er uiteindelijk IOS apps voor gemaakt kunnen worden.

OBDelm327 is supertraag, de OBDLinks zijn flink rap maar hebben ook STN1100 ondersteuning.
Default krijg je niks, tesla praat helemaal geen OBD maar je gebruikt de adapter om de canbus messages op te vragen en door te zetten.
Bij de ELM327 zit iedere halve seconde de buffer vol en stopt ie, daar moet je filters maken met masks om te krijgen wat je wil en dan met ATMA de stream aanzetten. Je krijgt de boel in hex eruit en met ATH1 kan je de headers aanzetten zodat hij de can-id ervoor zet.

Met STN1100 werkt het een stuk fijner. Je kan daar een hoop filters inzetten en alleen met 'STM' laten streamen wat je wilt zien.

Voor wat betreft die bluetooth 1234 pincode, daar was ik in eerste instantie ook niet blij mee, maar er zit een pair-knopje op, en na indrukken moet je binnen aantal seconden pairen en anders issie niet meer discoverable. Tis dus niet zo dat iedereen zomaar kan connecten zonder fysieke toegang tot het pair-knopje ;)

Ik gebruik ScanMyTesla alleen maar voor het realtime gebeuren, main doel is voor mij om met mijn raspberrypi4 bluetooth connectie te maken met de Obdlink en specifiek een xx aantal pids te capturen en in mysql te zetten voor grafana, om zo mijn grafanadashboards die ik tot nu toe vulde met TeslaFI api data, verder te verrijken. In canbus zit ALLES natuurlijk, kwestie alleen is om het te vinden.
Er zijn wat sheets/overzichten maar alles zit enorm verstopt in 64bits blobs en ook vaak nog half in de ene byte en half in de andere.
Maakt het er allemaal niet makkelijker op. Ook kom ik tegenstrijdige info tegen over het omrekenen van bepaalde readings naar 'reallife' waardes. Het zou tof zijn om een gezamelijke knowledge database/wiki op te zetten met alle info/scriptjes etc die we gebruiken??
 
#62
robertvg said:
Heb je ergens een permanente 5V kunnen aftappen voor die RPI4 ?
Of gebruik je die Zendure voor als hij stilstaat/sleep mode gaat.
Click to expand...

De RPI4 heeft (zeker op cpu-intensieve momenten) nogal flink wat piekspanning, zit standaard ook een 3A stroomadapter bij
Dat is allemaal wat heftig voor de usb-poorten. Nu vangt de Zendure het op. Bovendien moet je de RPI4 via usb-c voeden, maar ik heb diezelfde poort ook nodig voor data, want aan de RPI4 heb ik een samsungT5 die een paar partities heeft, 1 voor music, 1 voor teslacam en 1 voor storage voor de RPI4 o.a. canbus logs etc, zodat ik op de boot-SDkaart van de RPI4 niet zo intensief hoef te schrijven (voor de levensduur).
De partities heb ik trouwens XFS gemaakt met relinking zodat ik snapshots heb. Ik heb bijvoorbeeld een teslacam.img (wat een fat32 partitie is die ik dan met g_mass_storage driver export als USB-opslag, zodat de tesla hem als usb-stick zie. Ik heb van een lege Teslacam partitie ook een snapshot gemaakt. Dus als de tesla het FAT32 filesysteem weer es corrupt heeft gemaakt, kan ik met 1 druk op de knop image wegdonderen en de snapshot neerzetten, usb-mass driver aanzetten en HUP, binnen 5 seconden weer nieuwe versie 'usbstick' voor de auto.
Met XFS kan ik snapshots maken om dan daar iedere minuut webcam-shots uit de laatste sentry-opnames te trekken (met ffmpeg), zodat ik in mijn domotica-systeem ook (near) live webcambeelden van de auto kan bekijken
Ik heb de ZendureX6 USB-C poort aangesloten op de Tesla front-USB, daarmee wordt de zendure geladen. De zendure staat in HUB mode dat 2 andere poorten in verbinding staan met die usb-c .Met 1 van die poorten voed ik de RPI4 en gaat ook data overheen, de andere poort in de Zendure blijft vrij om een game-controller op te prikken voor de spelletjes. De andere front-USB heb ik gesplitst voor mijn draadloze oplader voor de gsm. Verder tak ik nog power af van de Tesla USB-poort zelf, daar heb ik een WemosD1mini aan hangen (maar iedere ESP8266 will do).... Daarmee schakel ik met gpio draden de RPI4 aan... Een andere gpio is hoog als de Wemos aanstaat en is aangesloten op de gpio van de RPI4. Zodra de tesla in slaap gaat, gaat wemos uit (RPI4 draait op dat moment nog op de Zendure power dus is nog online), en ik doe dan na 10-20 minuten netjes een shutdown van de RPI, zodat hij bij langer parkeren de Zendure niet helemaal leegtrekt. Aan de RPI4 heb ik een MIFI4G routertje hangen met openvpn naar mijn thuis hypervisortje, waar alles naar toegepushed wordt qua data(mysql) voor grafana.

Op afstand kan ik de boel als het in slaap gevallen is weer wakker maken door gewoon de tesla-app te starten, auto wordt wakker, 12V gaat aan en dan geeft de Wemos een poweron flipje op de GPIO van de RPI4 en die gaat dan booten.

Als ik wil dat de boel blijft draaien, laat ik gewoon sentry-mode aanstaan. dan gaat auto niet slapen en blijft alles draaien en online (en kan je ook de zendure nog even bijladen, want als je een dagje of 2 parkeert in sleep, is met het idle-verbruik van de RPI die zendure toch nog leeg...

Tijdens het rijden/sentry mode laad de tesla de zendure MEER bij dan dat de RPI eruit trekt, dus dat is mooi.
Als je weinig auto-uren maakt, zou je bv iedere dag paar uur sentrymode kunnen schedulen om ervoor te zorgen dat de zendure regelmatig op niveau bijgeladen word.


Apache webservertje met wat PHP dingen om vanuit de Teslabrowsers wat dingen te starten/stoppen (met lekker grote knoppen, makkelijk voor tijdens het rijden ;)

1.png


Eerste paar CAN-gegevens die ik via Python (PySerial) en eigen scriptjes extract, omreken en naar Mysql zet voor grafana graphs (op dit moment nog 1 x per 5 minuten)

2.png


De webcam snapshots trek ik dus uit de Teslacam image snapshots, laatste frames van de laatste mp4 file die sentry aan het schrijven is. Haal ik met ffmpeg eruit.
Uiteraard weten we de GPS-coordinaten, dus met Openstreetmaps reverse-geocode kunnen we daar ook de lokatie bij gooien. Vanuit domotica kan je 'near realtime' meekijken, de rest sla ik op (1 x per 5 min) de SSD op en als ik thuis ben en Wifi beschikbaar is, word het naar mijn NAS gegooid en die maakt er dan per dag een timelapse filmpje van.

tesla-front.jpg

Ja I know, WHY ....... vind het leuk om te knutselen.
 
Last edited:
  • Like
  • Love
Reactions: nico180 and robertvg
#64
RichieB said:
@joverdijk Dat klinkt erg leuk! Heb je je code ook op github staan? Ik draai nu TeslaCam maar automatische time lapse filmpjes lijkt me wel een leuke toevoeging.
Click to expand...

Hoi

Nee nog geen Github, ik ben helemaal geen programmeur ofzo en de code is een rommel van bash/php/python bij elkaar, omdat ik in niks echt goed genoeg ben ;-)) Wellicht zo INEFFICIENT en tenenkrommend geschreven dat bij iedere programmeur de tranen in hun ogen/broek schieten ;)

Maar ik ben ooit begonnen met de teslacam/marcone github: marcone/teslausb
Als je daar "/root/bin/remountfs_rw" uitvoert, is het filesysteem niet langer readonly en kan je flink rommelen in zijn scripts,
met apt vanalles installeren etc. Na reboot wordt de boel weer readonly, dit ivm het makkelijk corrupt raken van de sdkaart.
Maar ik liep al snel tegen resource/disk limitaties aan op de RPI ZeroW dus vandaar heb ik zelf de boel omgekat naar RPI4. Volgens mij zit er tegenwoordig op die Marcone github al wel RPI4 support, maar dat kwam pas nadat ik al met mijn eigen install begonnen was.

Anyway. De scripts en tools die ik gebruik zijn vrij rechttoe geschreven op mijn setup hier, maar is feite redelijk afgeleid van Teslausb.
Het heavy-liften toe ik niet op de RPI4 maar op een linuxVM op mijn hypervisor.

de timelapse filmpjes is supersimpel te doen met ffmpeg. De RPI4 upload zijn webcam snapshots naar de NAS, en timelapse maak ik vanuit cronjobje. Ik probeerde hier wat code neer te zetten maar het forum gaat meteen helemaal in de stress, misschien toch maar eens een centrale github + wiki/knowledgedatabase ergens gaan inrichten als we met een groepje forummers een beetje willen prutsen??

Damn, echt van *alles* gaat forum in security-shutdown. dan maar even als een plaatje, dit is aanmaken timelapse (maar is ook 1 google 'away' hoor, niks rocketscience aan ;)

Screenshot 2019-11-29 at 23.46.55.png


Hij pakt van alleen de front-camera (snapshots worden per 5 minuten gemaakt en staan in die snapshot-directory)
 
#65
Mn obdlink binnen gekregen en testrit gemaakt. Werkt prima al wordt de verbinding niet altijd hersteld bij het wegvallen van de verbinding.

Mijn oog viel op het ALL tabje meteen op de waardes "usable full pack", "usable remaining", "nominal full pack" en "nominal remaining".

Ook even een screenshot van de API response genomen om de waardes te kunnen vergelijken.

Heeft de Model 3 deze waardes ook?

Screenshot_20191130-145451.png
Screenshot_20191130-145423.png
 
#71
Bahram112 said:
Ondertussen stapje dichterbij:
Via Obtain a Copy of the Vehicle Data Associated With Your Tesla Account kan men vehicle data opvragen. Helaas ben ik bang dat dit voor Nederland niet mogelijk is.
Click to expand...
Een stapje dichterbij van wat?

Ik vermoed dat je historiek wil ophalen? Dat zal niet mogelijk zijn zonder een ODB2-lezer actief tijdens de rit (het onderwerp van dit topic) of een API scraper die tijdens de rit de informatie van de Tesla API inlas, zoals TeslaFi/TeslaMate/... Ook vanuit Tesla vermoed ik niet dat je historiek vroeger dan de laatste paar weken kan opvragen, aangezien Tesla zelf hun diagnostische informatie maar beperkt kan ophalen van je auto.
 
#79
joverdijk said:
De RPI4 heeft (zeker op cpu-intensieve momenten) nogal flink wat piekspanning, zit standaard ook een 3A stroomadapter bij
Dat is allemaal wat heftig voor de usb-poorten. Nu vangt de Zendure het op. Bovendien moet je de RPI4 via usb-c voeden, maar ik heb diezelfde poort ook nodig voor data, want aan de RPI4 heb ik een samsungT5 die een paar partities heeft, 1 voor music, 1 voor teslacam en 1 voor storage voor de RPI4 o.a. canbus logs etc, zodat ik op de boot-SDkaart van de RPI4 niet zo intensief hoef te schrijven (voor de levensduur).
De partities heb ik trouwens XFS gemaakt met relinking zodat ik snapshots heb. Ik heb bijvoorbeeld een teslacam.img (wat een fat32 partitie is die ik dan met g_mass_storage driver export als USB-opslag, zodat de tesla hem als usb-stick zie. Ik heb van een lege Teslacam partitie ook een snapshot gemaakt. Dus als de tesla het FAT32 filesysteem weer es corrupt heeft gemaakt, kan ik met 1 druk op de knop image wegdonderen en de snapshot neerzetten, usb-mass driver aanzetten en HUP, binnen 5 seconden weer nieuwe versie 'usbstick' voor de auto.
Met XFS kan ik snapshots maken om dan daar iedere minuut webcam-shots uit de laatste sentry-opnames te trekken (met ffmpeg), zodat ik in mijn domotica-systeem ook (near) live webcambeelden van de auto kan bekijken
Ik heb de ZendureX6 USB-C poort aangesloten op de Tesla front-USB, daarmee wordt de zendure geladen. De zendure staat in HUB mode dat 2 andere poorten in verbinding staan met die usb-c .Met 1 van die poorten voed ik de RPI4 en gaat ook data overheen, de andere poort in de Zendure blijft vrij om een game-controller op te prikken voor de spelletjes. De andere front-USB heb ik gesplitst voor mijn draadloze oplader voor de gsm. Verder tak ik nog power af van de Tesla USB-poort zelf, daar heb ik een WemosD1mini aan hangen (maar iedere ESP8266 will do).... Daarmee schakel ik met gpio draden de RPI4 aan... Een andere gpio is hoog als de Wemos aanstaat en is aangesloten op de gpio van de RPI4. Zodra de tesla in slaap gaat, gaat wemos uit (RPI4 draait op dat moment nog op de Zendure power dus is nog online), en ik doe dan na 10-20 minuten netjes een shutdown van de RPI, zodat hij bij langer parkeren de Zendure niet helemaal leegtrekt. Aan de RPI4 heb ik een MIFI4G routertje hangen met openvpn naar mijn thuis hypervisortje, waar alles naar toegepushed wordt qua data(mysql) voor grafana.

Op afstand kan ik de boel als het in slaap gevallen is weer wakker maken door gewoon de tesla-app te starten, auto wordt wakker, 12V gaat aan en dan geeft de Wemos een poweron flipje op de GPIO van de RPI4 en die gaat dan booten.

Als ik wil dat de boel blijft draaien, laat ik gewoon sentry-mode aanstaan. dan gaat auto niet slapen en blijft alles draaien en online (en kan je ook de zendure nog even bijladen, want als je een dagje of 2 parkeert in sleep, is met het idle-verbruik van de RPI die zendure toch nog leeg...

Tijdens het rijden/sentry mode laad de tesla de zendure MEER bij dan dat de RPI eruit trekt, dus dat is mooi.
Als je weinig auto-uren maakt, zou je bv iedere dag paar uur sentrymode kunnen schedulen om ervoor te zorgen dat de zendure regelmatig op niveau bijgeladen word.


Apache webservertje met wat PHP dingen om vanuit de Teslabrowsers wat dingen te starten/stoppen (met lekker grote knoppen, makkelijk voor tijdens het rijden ;)

View attachment 482788

Eerste paar CAN-gegevens die ik via Python (PySerial) en eigen scriptjes extract, omreken en naar Mysql zet voor grafana graphs (op dit moment nog 1 x per 5 minuten)

View attachment 482787

De webcam snapshots trek ik dus uit de Teslacam image snapshots, laatste frames van de laatste mp4 file die sentry aan het schrijven is. Haal ik met ffmpeg eruit.
Uiteraard weten we de GPS-coordinaten, dus met Openstreetmaps reverse-geocode kunnen we daar ook de lokatie bij gooien. Vanuit domotica kan je 'near realtime' meekijken, de rest sla ik op (1 x per 5 min) de SSD op en als ik thuis ben en Wifi beschikbaar is, word het naar mijn NAS gegooid en die maakt er dan per dag een timelapse filmpje van.

View attachment 482791
Ja I know, WHY ....... vind het leuk om te knutselen.
Click to expand...

Erg gaaf hoor @joverdijk veel lijkt me logisch wat je gebruikt, heb zelf nog niet de noodzaak en tijd.
 
You must log in or register to reply here.

Similar threads

ToemkeWTM
Eerste LR trip met Y LR
Replies
77
Views
4K
Belgium and the Netherlands
PriOkkie
PriOkkie
Monstarr
Mijn service ervaringen met de MYP...
Replies
15
Views
450
Belgium and the Netherlands
Devils son
D
D
Achter display Model-Y
Replies
12
Views
689
Belgium and the Netherlands
Karel
Karel
wooter
Ervaringen automatische front trunk nabouw opties
Replies
9
Views
247
Belgium and the Netherlands
SpaceWagon
SpaceWagon
A
Foutieve informatie Tesla Service Center
Replies
74
Views
1K
Belgium and the Netherlands
RobsEV
RobsEV
Top
Back
Blog
New
Forum list
Marketplace
Menu