How I got the Amazon Echo to start my car. (Part 6)

UPDATE 2: Amazon broke it and a lot of other two word devices. Removing the space from “MyCar” works.

UPDATE: Amazon OR SmartThings BROKE virtual switch capability with the echo earlier this week. It shows up under discovered devices and just gives a failed tone when triggered. I have inquired about this and have not heard back yet.

The elusive Part 6 of my Amazon Echo car start series is finally here!

So here we are, you read through the first five posts and are thinking to yourself “Ok Jryan, how in the hell do I do this myself?! Simple directions please.”

A little demanding tone, but ok, I’ll oblige.

WARNING: THIS ONLY WORKS ON GM CARS! Don’t waste your time trying other cars unless you’re up to months of frustration figuring it out. It *may* work on others, but you WILL need to find out the can-bus to use, the can-bus entry point, and the commands to use and how to structure them.

Gather your materials

  • Smart Things (No link, I will detail in another post eventually why I am no longer recommending the platform. That’s what I have currently setup in my home, but not for much longer. Summed up, it’s unreliable.)
  • Raspberry Pi Model A+
  • Raspberry Pi Model A+ Case (The one I have is no longer made, you’re on your own here.)
  • Sandisk SD Card
  • Bluetooth/Wifi Dongle
  • OBDLink MX Bluetooth
  • Car Adapter
  • A random generic USB hub, USB Keyboard/Mouse, HDMI Cable, MicroUSB wall adaptor, android tablet or phone. All of this is needed JUST for setup. If you are seriously reading this right now, setting this all up, I guarantee you have all of these things already.

NOTES:

  • Vera, OpenHAB, HomeSeer will all work, but I am not outlining the directions here. Maybe later if I am asked for specifics on these systems.
  • I suppose you could use a Rpi zero as well. I can’t tell you how it works though BECAUSE I CAN’T OBTAIN ONE! Also, steer clear of ALL OTHER MODELS of the Rpi, including the new Rpi 3, the power draw is too high for this project, among other issues you may have. If you aren’t going to attempt this until June, give the $9 C.H.I.P computer a try.
  • The Cirago Bluetooth Wifi dongle I used is no longer available and I HAVE NOT personally tested the one I listed.
  • Feel free to use whatever car adapter you’d like. Power issues are a bitch though. My Samsung fast charge car adapter has been great.
  • WTF, root? Sudo for the web service? ARE YOU MAD?! Yeah, well, do whatever you’d like. This is not a device sitting on the public internet, you can only get to it from the local network. If you want to secure it even more Mr. (Or Mrs.?) Paranoid, be my guest.

Perform The Steps

  1. Head over to the Raspberry Pi site and download “Raspian Jessie Lite”.
  2. Image your SD card. Here, have some directions: https://www.raspberrypi.org/documentation/installation/installing-images/README.md
  3. Plug in the usb hub, wifi/bluetooth dongle, keyboard/mouse, the SD Card, HDMI cable and power.
  4. You should be loaded into the terminal on boot. The default username is “pi” and the default password is “raspberry”. (If you care to change the password, you can do so by typing “sudo raspi-config” and selecting option 2.)
  5. Setup Wifi
  6. Give your Raspberry Pi a static IP
  7. Enable SSH:
    • Type sudo raspi-config
    • Option 9
    • Option A4
    • Enable
    • Ok
    • Finish.
  8. Set the root password:
    • sudo passwd root
  9. Allow root login on SSH:
    • sudo nano /etc/ssh/sshd_config
    • Change the line “PermitRootLogin” to “yes”
    • Ctrl+o to save
    • Ctrl+x to exit back to terminal
  10. Remove a few troublesome packages:
    • sudo apt-get purge ifplugd avahi-daemon
  11. Update and Upgrade Raspbian
    • sudo apt-get update && sudo apt-get upgrade
  12. Reboot the Rpi
    • reboot
  13. Install a few needed packages:
    • sudo apt-get install php5-common php5-cli php5-fpm nginx bluetooth python-serial minicom
  14. Add www-data to allowed sudoers.
    • sudo nano /etc/sudoers
    • Add the line below to the last line of the file. Save and exit.
    • www-data ALL=(ALL) NOPASSWD: ALL
  15. Setup Nginx to use PHP
    • sudo nano /etc/nginx/sites-available/default
    • Find the section below and REMOVE the # signs so it looks as follows.
    • # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
      #
      location ~ \.php$ {
      include snippets/fastcgi-php.conf;
      #
      # # With php5-cgi alone:
      # fastcgi_pass 127.0.0.1:9000;
      # With php5-fpm:
      fastcgi_pass unix:/var/run/php5-fpm.sock;
      }
    • Save and Exit
  16. Downgrade the MX Bluetooth to V3 firmware. Ugh, what a wasteful step. We wouldn’t need to do this if OBDLink was a responsive company…
    • Pair your MX Bluetooth with your phone.
      • Plug it into your car, press the pair button, and you better know how to complete the pairing progress on your phone/tablet.
      • Now that you have it paired, go to the Play Store and download “OBDLink”
      • Open OBDLink
      • Select “Settings”
      • “Communications”
      • Select “Bluetooth Device” and select whatever name the MX Bluetooth paired as.
      • Select “Firmware Updates”
      • Select the version 3 firmware, and downgrade it. Why? Because it’s way more stable than version 4 for this purpose.
      • When the upgrade is finished, unpair it from your phone and reset it to factory settings (Hold the button down until you see the light start rapidly flashing on the MX)
  17. Here’s the step where ssh is going to come in handy. Plug just the usb wifi/bluetooth adapter into the Pi, hook it up to your car’s power, and bring a laptop to SSH into it.
  18. Pair the MX Bluetooth to your Raspberry Pi
    • Plug the MX Bluetooth into your car
    • bluetoothctl
    • scan on
    • Press the pairing button on your MX Bluetooth
    • It will pop up, copy the mac address.
    • pairable on
    • pair MACADDRESS_GOES_HERE
    • trust MACADDRESS_GOES_HERE
    • scan off
    • exit
    • sdptool add SP
  19. At this point, it would be a good time to find your keyfob lock code. Go back and read. I get into this. EXCEPT, you will be using Minicom instead of Cutecom because there is no GUI with Jessie Lite and I do not recommend you install one.
  20. Install some files from Github. You can WGET or send them over with SSH (you may have set it up earlier). https://github.com/jryanishere/GM-Car-Automation
    • Place keyfob.php in “/var/www/html”
    • Place keyfob.py in “/var/www/html/cgi-script”
  21. Edit keyfob.py
    • nano /var/www/html/cgi-script/keyfob.py
    • Insert the first two digits on line 58 and the next 6 digits on line 61. (Hopefully the rest of the command will line up and everything will work.)
  22. Time to test.
    1. In a browser on your computer, navigate to “http://RASPBERRY_PI_IP/keyfob.php?command=lock”
    2. Did your car lock? Yes? Go to step 22.
  23. Get SmartThings configured
    • Make a developer account if you don’t already have one.
    • https://graph.api.smartthings.com/
    • Login
    • Click “My Device Handlers”
    • Click “Create new device handler”
    • Click “From Code”
    • Copy and paste the contents of the “SmartThings Device Handler” from my Github
    • On line 43 and 49, update the ip address to your ip address. You’ll notice a hex code after the IP. You’ll need to change this as well. It is a converted version of your IP address. You can convert it here: http://www.miniwebtool.com/ip-address-to-hex-converter/
    • Click Create
    • Click “Publish” then “For me”
    • Click “My Devices”
    • Click “+New Device”
    • Name it “My Car”
    • Make the Network Id “CarStart”
    • Select your hub
    • Select the type, at the bottom of the list select “On/Off Button Tile”
    • Create
  24. Now that you have your new device in SmartThings, you can now re-add your SmartThings account in your Amazon Alexa app, select your new device, and discover new devices.
  25. “Alexa, turn on my car”

How I got the Amazon Echo to start my car. (Part 5)

For legal reasons, I can’t post the codes I found on my car. So the script I have on Git Hub WILL NOT work as is, but it’s close.

Git Hub: https://github.com/jryanishere/GM-Car-Automation

I am going to side track in this post as now would be a good time to follow up on what I meant when I said, don’t use the Raspberry Pi Model B, Model B+ and Model 2 B OR Wheezy. If you’re just going to take my word for it, go ahead and skip ahead to Part 6.

Beyond the high idle power draw, I had MAJOR stability issues with ALL of them. I would get the thing working reliably, and a few days later, something else would mess up. If someone asked me at the beginning of all of this: “What do you think the hardest part of this project would be?” I NEVER would have said getting the Raspberry Pi to not be a little bitch. I chased issues for damn months. I’ll save you all of my swearing and jump right to WHY I said not to use them.

Wheezy was a pain in the ass to pair with the MX and once it was paired, it had serious connectivity issues with every Bluetooth dongle I tried.

Wifi was unstable in wheezy. At first, I read about turning off power saving, which appeared to fix it, but it still was dropping after a day or two. It turned out to be the ifplugd package randomly taking down the interface and never bringing it up again.

Multiple Kernel Panics. I thought this was a power issue at first so I bought a lipo battery that can provide charging while powered. Maybe it was the uneven power provided when my car started? Nope. I brought the Raspberry Pi 2 Model B inside on stable power. Nope, still randomly panicked on a known good power cord. I tried multiple Bluetooth and wifi dongles, no go, the Pi 2 B crashed. It crashed even faster when I had a Huawei E303 plugged in as well.

I tried a couple different powered USB hubs (which shouldn’t have been needed! this was a Pi 2 B damnit) and I was having trouble getting the dongles to be consistently recognized.

I tried a new SD card and started fresh with Jessie. The kernel panics continued.

I tried different versions of Python, I switched from Apache to the lighter weight Nginx, and I installed the Jessie Light build without the gui and other useless packages. Panics…

Last thing I tried on the Pi 2 B was making a custom power adapter, volting up to 5.3 volts, connecting it to the gpio pins and giving that a try for a while. About the first 24 hours were good, then the pi 2 stopped booting, for good. Ok, full fuck this mode.

I brought out the Model B+ I had and the original Model B. I bought a few different powered USB hubs to use with them and I got the Wifi/Bluetooth working, but not the cellular dongle. I couldn’t get Usbmodeswitch to work reliably on a powered hub. And when I did get it to work, wvdial sometimes would throw an error. It worked perfectly fine on the same hubs when plugged into my Linux Mint laptop.

I was hundreds of dollars into this and two months into trying to make this stable. I was so pissed. The easiest part of the project suddenly became the hardest.

After trying to get my hands on a Pi Zero the entire time I was swearing at the other models, I settled on trying a Model A+ as a last ditch effort. I set it up with Jessie Lite after everything I have learned from all the previous tries and… it worked. I never had any issues. WTF. What was on all the previous models that was screwing with me?! I never found out. I suspect it was a hardware architecture problem of some sort, but I was never able to confirm it. I was just happy that the Model A+ was relatively stable.

Notice how I said relatively stable up in the last paragraph? There are two issues that you may encounter.

First, the MX Bluetooth is a horribly unstable product with ZERO product support. LESS than zero product support. I am so pissed about this, but I digress. It’s the only commercially available adapter that requires NO aftermarket mods to work on the SW CAN Bus of GM Vehicles. If you downgrade the firmware right when you get it, it helps, a lot. It will now stay stable for just over a week (as opposed to a few days), then becomes unresponsive requiring a power cycle. I have resorted to unplugging it once a week until a few competitors release SW Can capable adapters OR I finally get around to making my own adapter. There is also a timer/relay mod I came up with to reset it once or twice a day, but that’ll be in a much later post, maybe.

No real competitors to the MX Bluetooth yet. In my research, I found one guy that used the STN1170 chipset (made by the same people that make the MX), but the demand just wasn’t there, so he didn’t make another batch. BUT there is a small glimmer of hope. There will be at least one new competing adapter that will hit the market within the next year. I will post on it when the company is ready to send me one.

Second, I haven’t told you about Minicom yet. Minicom is THE BEST serial console that runs completely in terminal, no GUI. If you open a RFCOMM channel, open Minicom, and start sending commands via the Python script, you WILL get a kernel panic. I have not found a way around this. It is only a slight problem for testing. Not a huge deal, but I thought I’d warn you now. As I did for most of my initial testing, you could install the full version of Jessie with the GUI and use CuteCom.

Ok, side track is over. Time to dive into how I finally got all of this to work.

Continued Finished on Part 6!!!!  Soon…

How I got the Amazon Echo to start my car. (Part 4)

Disclaimer: I did not list any actual codes in this blog post. I am not sure the legalities involved, so I will outline everything except the actual codes to send on the CAN Bus. Everything I talk about are just place holders. They are easy enough to find on your own.

What in the hell was I missing?! I had the adapter configured and the car still wasn’t listening. Back to the STN1100 sheet I went. I just knew at this point I was structuring it incorrectly. If I had the command 10 00 00 00 02 01 how was I supposed to put that code back on the CAN Bus and get a response. I’ll spare you the exact details, but I ended up trying a lot of different things. I eventually hit pay dirt.


AT CP 10
AT SH 00 00 00
02 01

Boom. Instant response. My car doors locked. Now to find the unlock button.

I did the exact same thing as earlier. I turned the car off, let the CAN Bus go to sleep, and pressed the unlock button five times as I was logging the data from the CAN Bus.

I dumped the data to Excel again and started to sift through it.

Hmm. I wasn’t seeing ANY commands showing up five times. I thought about it for a minute, and guess what happens when the car is locked and you hit the unlock keyfob button for the first time? Just the driver door unlocks. Well, that explains it.

I found the command that showed up FOUR times (because the first command was something else to just unlock the driver’s door remember?).


10 00 00 00 02 03

Hmm. That’s the exact same code I wrote down earlier, well almost. It was the same up until the very last digit. 01 changed to 03, that’s it. Game on.

Side note, you’ll see the importance of this soon: My car was running when I started sending codes for two reasons.

  1. It was freakin’ cold out!
  2. The CAN Bus goes to sleep when the car is turned off.

I started rifling down the list, 01, 02, 03, 04…20 until I found everything.


01 Lock
02 Unlock Driver
03 Unlock All
07 Panic
15 Trunk

Hell yes. (Hint, GM only has a few sets of codes across ALL of their vehicles since 2006. Most of these may line up to your vehicle.)

Wait a minute, something is missing from that list. START! Where in the hell is start? Ugh. So close, yet so far. And how in the hell was I going to find what worked for start with the car running and the CAN Bus busy as hell?

I actually got lucky here. I remembered the STN1100 chipset allowed filtering by header. Since I already knew the header that all of the keyfob commands were sending, and only the last two digits of the code changed thus far, maybe the start commands were structured like the rest of the commands. Yes, yes they were.


0B Start
0C Stop

Sweeeet. I’ve got my codes. But as I discovered earlier. The CAN Bus goes to sleep when there is no activity… Well, what is the hell was I supposed to do now?!

Wake the sucker up. Duh.

I had absolutely no idea how to do this. I Googled for a while, trying multiple different search terms trying to find ANYONE that could give me some insight.

That guy saved my project. I had to send an 11-bit wake-up message FIRST before sending the rest of my commands. Ok, cool. SO HOW IN THE HELL DO I DO THAT?!

Back to the STN1100 Reference Manual and OBDLink MX Protocol Commands PDF.

I’ll spare you the ridiculous trial and error I went through and jump right to how I woke the bus up.


ATR0
ATAL
STP 61 (Set the sw can mode to 11 bit)
STCSWM 2 (Set the sw can mode to “Wakeup”)
AT SH 621 (Set the header to 621)
01 FF FF FF FF 00 00 00

BUT WAIT, The CAN Bus dude said I only had 3 seconds to send commands after the CAN Bus was woken up.

I’d like to say this is where I started to investigate writing a Python script to do everything fast enough for me, nope. Imagine me sitting in my driver’s seat with my laptop on my lap and a list of commands printed next to me in the order they needed to be typed. Imagining? Good. Now, imagine me typing as quick as I can trying to beat the 3 second timer, for 20 minutes straight, growing increasingly frustrated. Now imagine me throwing my laptop on my passenger seat and running into my house pissed as shit. Ok? Done laughing? Joke’s on you, I got it to work by hand. 😛 Let’s move on to the Python script.

To Be Continued on Part 5. Check back in a day or two. Writing is hard.

How I got the Amazon Echo to start my car. (Part 3)

I turned the car off, opened the door to kill accessories, and to my surprise the data kept flowing. Lucky for me, the car did not need to be turned on to be on the SW CAN Bus. The stream also slowed down quite a bit. Still too fast to pay attention to in real time, but noticeably slower. Then something happened. As I sat there in the driver seat staring at my laptop screen (yes, I was vnc’d into the pi, I recommend you do the same instead of dragging a hdmi screen and keyboard/mouse into your car), the dome lights turned off and the CAN Bus went silent. No activity.

So now I have a blank screen. A screen that holds all the answers. A screen that stands between me and a successful project. I just had to do something to get it to give me all of the answers.

I hit the lock button on my key fob. The CAN Bus started going nuts again.

And then it died down to nothingness. I really needed a way to filter this. I wasted a few hours on trying to get Can Utils AND a GM LAN sniffer programming running. These programs were supposed to easily filter out all the noise and show me the changes in the noise. Great idea, but I couldn’t get either to work with a Bluetooth serial device. Instead of wasting any more time, I recalled reading in another blog that they hit the button they were trying to find in a very controlled way, dumped the info to excel, and tried to filter it all out. And that’s exactly what I did. Except I went the easier route of just sorting and finding the code that only showed up the number of times I hit the keyfob button.

Cutecom sorted

I quickly found my lock button! Well, what I thought to be my lock button. (Spoiler- Yes, it did turn out to be my lock button, I wasn’t sure yet. I felt kind of stupid as it was always within the first couple of messages after the bus woke up. But it was good practice as I needed to dig out the start button later.)

So I have what I think to be my lock button. Before I went any further, I made it my mission to lock that car from the serial terminal. I reset the adapter with ATZ as I didn’t want any old settings to interfere.

I keyed in the hex code into the terminal and… nothing happened. Nothing, at all. I tried typing it with various spaces and with a 0x in front as it was a hex code, and nothing…

I then started the car and tried again.

“Traction Control Off” popped up on my DIC (Driver Information Center)

Hmm. Ok, a response. I like that. Maybe I am just typing it wrong. I then tried to type it every which way I thought it could be.

“Traction Control Off” “Service Traction Control” “Service Stabilitrak”

“Shit. SHIT! What did I do? What did I possibly do? I BROKE IT. SHIT, SHIT, SHIT, SHIT, SHIT. Ok, let me just turn the car off for a few minutes and let the CAN Bus go to sleep again.” I start my car.

“Traction Control Off” “Service Traction Control” “Service Stabilitrak”

“F THIS. I am so done. I have dumped enough money into this project and now I will probably need a trip to the dealer on my JUST out of warranty vehicle to fix whatever I messed up. Son of a bitch.” I turned the car off, got out, slammed the door, and went inside for a half hour as I calmed down.

I was sitting inside, on my couch, staring at the ceiling. My brain was running a million miles an hour. I couldn’t drop it. I couldn’t drop that I was stupid enough to break my car and fail so badly at a project that I should have the mental capacity to finish. THIS SHOULDN’T BE DIFFICULT. Time consuming maybe, but NOT difficult.

Still fuming from the Stabilitrak issue, I went back outside, got in my car, started it and… silence. No beeping, no idiot lights, my DIC displayed my compass and mileage. BACK IN BUSINESS BABY!

SO what do I do? I go back to the serial console and type in the same damn command again…

“Traction Control Off”

Oh no, no, no, no. I am NOT going down that road again.

I sat back and took a good look at what I was doing. I reset the adapter again and began to set it up when it occurred to me, I FORGOT TO SET THE SW CAN MODE! So much mental anguish for one stupid command I forgot.

Feeling pretty sure of myself with my adapter setup the CORRECT way now, I enter the code, and nothing. I didn’t even get “Traction Control Off”. I was disappointed, but that was progress.

Continued on Part 4.

How I got the Amazon Echo to start my car. (Part 2)

Fast forward to Saturday morning. My new MX Bluetooth showed up around 10.30am. I was ecstatic. Like a kid waiting by the mailbox for his x-ray specs to arrive.

Armed with the knowledge of all my purchase mistakes, blogs, forum threads, and datasheets, I jumped right in.

First step, image the pi and get the wireless setup. This was crazy easy and I didn’t need any directions, but for you, the reader, here are the directions to do it:

Next, I had to get the MX Bluetooth to connect to my Raspberry Pi. Bluetooth pairing should be straight forward right? Ha.

The first Raspberry Pi I tried was a Pi2 model B with Raspbian Weezy. I specifically picked the newest model due to the number of USB ports and the 500ma power rating per port. (DO NOT USE THE Pi B, Pi B+, Pi2 B, OR WHEEZY! more on this later. I had major stability issues with them all. Proceed if you’d like. If you figure out why they were unstable, please let me know.)

The first thing I tried was the built in GUI to try and pair this thing. The GUI wouldn’t even load, even with a supposed compatible Bluetooth adapter. Ugh… Ok, so how in the hell am I supposed to do this via terminal?

I knew how to use hcitool to pair when the device had a pin, but the MX Bluetooth doesn’t use a pin.

Thank-you stackoverflow: http://stackoverflow.com/questions/12888589/linux-command-line-howto-accept-pairing-for-bluetooth-device-without-pin

Even with the correct directions, I had to try pairing it three or four times until it finally worked…nothing can be easy.

The stackoverflow thread made mention of rfcomm to connect to the Bluetooth serial device, that was the next thing I needed to setup.

It was very straight forward. The man file had all the info I needed.

I needed to edit the file /etc/Bluetooth/rfcomm.conf as follows:


rfcomm0 {
bind yes;
device BL:UE:TO:OT:HA:DDRESS;
channel 1;
comment “MX Bluetooth”
}

(Quick note, I used “bind yes” initially, however, this turned out not to be the best method, more on this in a later post.)

MX Bluetooth paired- Done

MX Bluetooth mounted as a Bluetooth serial device- Done

Next step was picking a serial terminal. As I was still in the discovery phase of this project, I kept the GUI installed. So why torture myself? I used the awesome GUI serial terminal, CuteCom.

cutecom-0.14.0

source: http://cutecom.sourceforge.net/

With CuteCom installed, I didn’t know the exact serial settings (the STN1100 command reference sheet I linked is not exactly the same as the STN1151 which is in the MX Bluetooth), so I made an educated guess and got it to connect first try.


115200, 8, N, 1

Sweet. I now have a serial terminal to manipulate the adapter directly.

I started my car (with the key…) and set a few commands I thought may be helpful:

  • ATAL (Allow long messages, I wanted to see everything)
  • ATH 1 (Turn message headers on, again, I want to see EVERYTHING)

I issued the STMA command and ERRORS! ERRORS EVERYWHERE!!! Oops. I forgot to set the adapter to GMLAN first.

I turned off STMA by hitting enter, literally hitting any number/letter, and hitting enter again.

The MX Protocol Commands only had 4 SW CAN settings. I set the first one by issuing:


STP 61

Issued STMA again and BINGO, sweet, sweet data. Loads of hex codes went flying by. Fast, like really fast. Like 1000 lines in a few seconds fast. What in the hell was I going to do with all of this information now when 99.99999% of it is useless for my goal?

Continued on Part 3.

How I got the Amazon Echo to start my car.

How I got the Amazon Echo to control the factory remote start via wifi on my car (I got cellular working too, but that’ll be in a later post).

Quick Outline Vid: https://www.youtube.com/watch?v=_GTH1A73xwc&feature=youtu.be

I bought my Echo in January 2015 and received it at some point in March 2015. I honestly thought it was a weird product without any real use. The only reason I bought it was due to the $100 discount Amazon was giving out to early adopters/prime members. It couldn’t control any of my smart devices yet, and didn’t have any third party skills of any value. It turned out to be a glorified alarm clock and weather reporter. I wasn’t even sure why I bought it.

In the coming months, more and more was released to make the Echo what it is today. In April, Amazon announced Wemo and Philips Hue support. By the end of April, a talented programmer going by the handle “Armzilla” released his Amazon Echo Bridge for Vera smart home hubs.

I soon had Echo controlling multiple aspects of my smart house. It was controlling my lights, locking my doors, controlling my thermostat, and I even had it turning my TV on and off. Now the Echo was becoming seriously appealing.

As the months went by, I continued to ask myself “Why in the hell can’t this thing start my car yet?!” on Sunday, November 28th, I finally decided to do something about it.

I began to break down the project. What are the components I actually need to gather to make this work, and is it even possible? No matter what I was going to do, I had already decided a Raspberry Pi would need to be the main control for all of this. Then, all I needed was a way to interface the Pi with the can bus of my car, and a way for the Echo to reach the Pi. Simple right? I came to find out, not so much.

At first, I settled on sacrificing one of my key fobs. I already had the Raspberry Pi and a wifi usb dongle for it, I just needed a relay board. I was going to hook the relay board to the gpio pins, solder some wires to the buttons on the fob, and make a python script to fire the relays and press the buttons in the correct order. Happy with my plan, I ordered a relay board from Amazon for ~$8 and went to bed.

The next morning, the cogs in my head began to turn “How hard would it be to do this by jumping on the CAN Bus of my car?” Oh crap, here we go. I scrapped the key fob idea before I even attempted it. I could always fall back on it if the CAN Bus defeated me.

I began to research CAN Bus hacking. I read through every blog I could find. The information was seriously lacking. Not many people mess around with the CAN Bus on their cars. I only found a few decent blog posts on the topic:

I ordered an Arduino and a CAN Bus Shield after my research that day. The Chad Gibbons blog said it was a pain in the ass, but it didn’t register with me how much so. I just looked at the ~$45 price tag for the hardware and ordered it.

Once again, before I even received my next hardware order, I continued searching, but this time, for GM specific information about hacking the CAN Bus. I quickly found out GM uses a standard that NO OTHER AUTOMAKERS USE! Thanks guys… I’m sure there was some awesome reason for you to deviate from the rest of the industry.

GM uses something called Single-Wire Can. Going forward, I you will see me using SW CAN and GMLAN interchangeably. It is used for all infotainment, key fob, and On-Star commands (among others). This rang a bell as I have installed half a dozen aftermarket remote starters on GM vehicles and some of the immobilizer bypass modules had a single can wire. Damnit… I did find a few threads/blogs on the matter:

Even with the mention of getting the Arduino to work with GMLAN, I didn’t spend much time on trying it after seeing the g8gt blog ($45 wasted on the Arduino… and I didn’t want to return it if I found some other need for it later in the project). He detailed how he modified someone else’s modification of a cheapie Elm327 clone off of Ebay to work on GMLAN. I found the exact clone he bought and went on Digikey to price out all of the parts. It came out to be $10 for the clone adapter and ~$30 for enough parts from Digikey to make 5 transceiver mod chips.

Once again, (do you see where this is going?) I continued to research GMLAN capable adapters, AND I FREAKIN’ FOUND ONE. AHHHH! SON OF A… Another $40+ wasted on the clone and Digikey parts (another fallback idea though). I purchased an OBDLink MX Bluetooth (which has a lot of its own problems, more on this later) for $100 on Amazon.

While I was waiting for the adapter to arrive, I read through the entire STN1170 datasheet and found the protocol commands cheat sheet.

Continued on Part 2.