Ik kan wel een PDF versie maken maar kan die niet uploaden hier volgens mij.
Er staan een downloadbare PDF op het forum van mijn site (www.reho.nl)
Last edited:
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Model 3: Geek mode (CANbus, OBD2)
- Thread starter prensel
- Start date
Ik kan wel een PDF versie maken maar kan die niet uploaden hier volgens mij.
Er staan een downloadbare PDF op het forum van mijn site (www.reho.nl)
De eerste HIO opleiding was in 1989/1990 en daar leerde je tenminste nog wat.
In ieder geval fatsoenlijk binair rekenen en in assembly programmeren plus alle hogere talen die gewoon standaard bagage horen te zijn als je enig recht van spreken denk te kunnen hebben.
Tegenwoordig is het nivo wat er van die opleidingen afkomt echt bagger, paar mooie bullshit bingo kreten, een fout pak aan en men noemt zich opeens ICT'er, maar iets echt kunnen is er niet meer bij...
Ik zat op de HIO vanaf half jaren 90 dus heb binair rekenen, assembly, object oriented pascal etc allemaal gehad. Dus nog in de 'goede tijd' ..... Maar ik ben van beroep geen programmeur (pruts iets met netwerken), en moet zeggen dat die HIO-kennis na een jaar of 25 *ernstig* ver is weggezakt. Hobbymatig doe ik soms wat bash/shell-scripting voor mijn homedatacentertje (hypervisor met knutsel containers/vms) maar dit soort projectjes is wel leuk om er weer eens terug mee bezig te zijn
Last edited:
Ja ik begrijp inderdaad dat dat truukje alleen werkt als je met nibbles werkt en precies in het midden van een byte terrecht komt, als het iets meer schuift dan dat moet je de maskering.
Ik zal die subroutine eens bekijken van Amund, ik lees en reken de data nu in python om, alleen specifiek voor de data die ik OP DIT MOMENT wil hebben op een 5 minute interval, omdat ik mijn mysql/grafana wil verrijken met stats die niet in de Tesla API zitten, dus voor dit moment is performance en realtime-zijn nog totaal geen issue. Uiteindelijk wil ik wel een html5 pagina maken op de raspberry4 webserver in de auto zodat ik een soort ScanMyTesla webpage heb maar dan op het scherm van de auto zelf, want tijdens het rijden ga je toch niet op een gsm lopen kijken/klooien.
Oddly alle rfc1918 ip-space is blocked vanuit Tesla, dus als je een hotspot maakt met een rpi4 met 4g (zoals ik heb gedaan) moet je wel een blokje public ip hijacken om de connectiviteit tussen de tesla-browser en je apache webserver in de auto voor elkaar te krijgen.
Ik ben toch echt al in 1984 in Enschede aan de HIO begonnen (De Maere). Al Googelend vond ik een CV van iemand die aangaf daar zelfs al 4 jaar eerder begonnen te zijn
Ik ben er overigens maar één jaar geweest. Na dat jaar ben ik richting de campus vertrokken om Informatica te gaan studeren aan wat toen nog the THT was. Beetje ter compensatie van die talloze studenten die jaarlijks, vaak met weinig succes, de omgekeerde route volgenden
Geleerd heb ik in dat jaar inderdaad echt wel het nodige. Maar de jaren daarna is er nog wel het nodige bijgekomen. Ook na mijn studie.
De BT versies schijnen inderdaad wel sneller te zijn. Hoeveel weet ik niet en stabiliteit weet ik ook niet (heb ze nooit gebruikt). Voor mij hadden hun WiFi versies een heel groot voordeel: ze konden niet alleen in AP mode werken, maar ook in Infrastructure mode (dus verbinden met een al bestaand WiFi netwerk).
Ik gebruikte ze (inderdaad meervoud) in mijn Outlander PHEV. Als die op de oprit stond te laden verbonden de adapters met mijn thuis netwerk en kon ik op de bank voor de TV het laadproces in detail volgen. Als ik in de auto zat zette ik een hotspot op op mijn telefoon met hetzelfde SSID als thuis en verbonden ze gewoon met mijn telefoon.
De reden om er meerdere te gebruiken was als volgt.
Ik ben ooit begonnen om via een OBD Y kabel het verkeer van een commercieel scannertje af te luisteren en zo een hele bibliotheek aan PHEV specifieke OBD PIDs en responses op te bouwen. En deze ook te leren interpreteren zoals jullie hier nu aan het oden zijn. Deze PIDs heb ik in Torque Pro gezet en klaar was ik (overigens, dezelfde database die ik zelf zo heb opgebouwd vormt ook de basis van EvBatMon en in PHEV WatchDog (twee Outlander specifieke OBD tools die in de App Stores te vinden zijn).
Al snel kwam ik er achter dat de sweep time veel te traag was voor wat ik graag wilde. Daarom ben ik met een tweede adapter het al aanwezige CANBUS traffic gaan monitoren ben ik deze gaan vergelijken met de data die ik uit de PIDs kreeg. Een aantal zaken kon ik relatief snel terug vinden (denk aan een jaar of 15
) maar sommige dingen ook niet.Op een gegeven moment kwam ik er achter dat de main CANBUS van de PHEV d.m.v. een firewall in tweeën was gehakt: één deel werd voornamelijk gebruikt voor ICE gerelateerde componenten en één deel was hoofdzakelijk voor de EV gerelateerde componenten. Het meeste CANBUS verkeer werd door de firewall binnen het eigen segment gehouden en zo werd overbelasting van het totale netwerk voorkomen. Maar mijn OBD diagnose poort zat dus in het deel van de ICE en dat verklaarde waarom meer dan de helft van het CANBUS verkeer nooit zag / had kunnen zien.
Toen heb ik de CANBUS draden bij de achterste elektromotor afgetakt en een tweede diagnose poort gecreëerd. Tweede MX adapter aangesloten en tada .... nog 15 jaar data crunchen. Uiteindelijk heel veel gevonden (torque request vanuit de main ECU richting motoren en generator is bijvoorbeeld super interessant), maar natuurlijk niet alles. Daarom ben ik geëindigd met die 3 MX-en, twee die aan één stuk door STMA runden op de twee CANBUS segmenten (als ik een buffer overflow kreeg stuurde ik automatisch weet een STMA commando) en een derde die 'gewone' PID requests gebruikte data op te halen die ik niet in het standaard CANBUS verkeer gevonden had.
Op mijn telefoon draaide ik een Java programma (een soort van proxy of man-in-the-middle) dat aan de achterkant met de drie adapters communiceerde en de drie data stromen consolideerde en cachete (hoe schrijf je dat in zijn Nederlands?) voor het geval hier om gevraagd zou worden. Aan de voorkant bootste het programma zelf weer een OBD adapter na, zodat ik met standaard OBD software (voornamelijk Torque PRO) data op kon halen. Aan deze kant werden requesten vanuit de cache ingevuld zodat de client nooit hoefde te wachten, ook niet als langzamere PID requesten uitgevraagd werden.
Ik heb mijn Java progje ook wel eens in combinatie met PHEVWatchDog gebruikt, als een soort accelerator. Werkt heel aardig. Zelfde resultaten maar met veel kortere sweep time.
Sorry allemaal voor off-topic, maar vond het te leuk om te delen. Wel blij dat ik het allemaal een beetje achter me gelaten heb toen ik de PHEV verkocht, want tsjonge jonge wat heeft dit allemaal belachelijk veel tijd gekost.
Last edited:
Cool man, echt lekker aan de knutsel geweest met de PHEV ;-) Leuk om te lezen
Ik was in eerste instante ook voor de Obdlink MXwifi gegaan, precies wat je zei, infrastructure mode.
In de tesla heb ik een permanent draaiende RPI4 (met Zendure X6 als UPS-functie ertussen) die hotspot draait voor de auto, met een Tplink4G-routertje eraan. De raspberry zit er als router/dhcp/dnscache tussen zodat ik wat dingen kan afvangen en via openvpn tunnel naar huis routering heb voor o.a. grafana-stats/domoticz/homekit-meuk onderweg op het grote tesla-scherm.
Idee was idd om met de MXwifi gewoon mijn raspberry-wifinetwerk in de auto te joinen en dat ik vanuit de RPI op een tcp-poort bij de data kon.
Ik zat nog te wachten op het canbus aftap-harnasje (had de MX al binnen) en toen las ik ZO veel ellende op forum van obdlink, plus op teslaowners forum waren ze echt meer fan van de LX variant dat ik besloten heb ze om te ruilen. Zit nu nog te wachten op de LX.
In de tussentijd met een cheapass elm337 china dingetje aan het klooien. Gebruik nog geen filters/masks voor de ATMA dus dat ding gaat iedere seconde over zijn giechel zo ongeveer, maar dat is maar even zo, ik heb de backend toch nog lang niet klaar
Was jij niet degene die zei dat hij meer met netwerken deed dan met programmeren?
Ondertussen al wel aan het inlezen op de ST command set, denk ik? STM commando's zouden beter moeten zijn dan ATM commando's. Meer controle / efficiëntere filtering en zo ...In de tussentijd met een cheapass elm337 china dingetje aan het klooien. Gebruik nog geen filters/masks voor de ATMA dus dat ding gaat iedere seconde over zijn giechel zo ongeveer, maar dat is maar even zo, ik heb de backend toch nog lang niet klaar
Was jij niet degene die zei dat hij meer met netwerken deed dan met programmeren?
Ja klopt, beroepsmatig al 20+ jaar aan hele grote ip netwerken aan het ontwerpen/knutselen jah.
Ja STN11xx ziet er een heel stuk robuuster uit. Gaat efficientie en snelheid wel ten goede komen, uiteindelijk wil ik op het scherm in de auto near-realtime info/gauges/leuke UI shizzle hebben
Niet weerhoud je er van om een stukje address space van Tesla te gebruiken op je lokale wifi
Of je zet op de rpi een transparant proxy oid. Zijn genoeg mogelijkheden om onder die rfc1918 restrictie uit te komen.
Nou, wat het is, vanuit de browser in tesla lijken alle connecties naar rfc1918 geblocked te zijn. Dus je moet als je in je eigen LAN wat wilt bereiken in je wifi-router NAT doen van een random public ip (wat wel allowed is) terug naar binnen naar een intern ip.
Probeer maar es, als je auto op je thuiswifi zit (met rfc1918 ip) dan kan je niet naar bv webinterface van iets in je LAN (je nas/domotica whatever) Tenminste dat was paar maanden geleden zo, neem aan dat dat nog steeds is.
Ben, voordat ik met mijn Java appje op mijn Android telefoon begon tnb Torque Pro (wat je natuurlijk niet op het scherm gaat krijgen), ook bezig geweest met een PI. Had daar een min of meer statische web pagina klaar staan, met een paar Gauges er op die via een Node JS servertje op de PI real time data ophaalden. Kan me herinneren dat mijn telefoon dat niet echt leuk vond. Die werd bloed heet. Maar het kan heel goed zijn dat ik iets fout heb gedaan...., uiteindelijk wil ik op het scherm in de auto near-realtime info/gauges/leuke UI shizzle hebben
Heb je getest met local loop netwerk addressing op 127.x.x.x ?
Die valt formeel niet in de rfc1918 en als Tesla strict deze hanteert zou 127 moeten werken.
Zo zijn er nog wel een paar die niet onder rfc1918 vallen en dan kom je ook niet in de 'problemen' met geldige adressen
192.0.2.0/24
198.51.100.0/24
203.0.113.0/24
Last edited:
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?
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?
robertvg
Extremely Well-Known Member
Heb je ergens een permanente 5V kunnen aftappen voor die RPI4 ?
Of gebruik je die Zendure voor als hij stilstaat/sleep mode gaat.
Similar threads
