Jeep Bot – Proof of Concept #1

I finished the 1st proof-of-concept for using the CAN-Bus data to control auxiliary relays. It worked great. Attached is a block diagram of what I used, and a longish video of how the testing went.

Jeep Bot Block Diagram


If you want to skip all the bench testing, the actual in-car testing happens at the 11:15 mark of the video.

Code for the demo can be found at

A few hours after I finished, a bluetooth-low-energy board I ordered showed up. The next step will be to throw that on there so that I can use the smartphone to configure each switch and optionally control them by hand.

Each switch will have the following different possible control states:

  • always on
  • manual only
  • on when interior lights are on
  • on when high-beams are on

Right after that, I’ll start working on a prototype PCB and housing so I can start testing real versions of this system.

I’ll post the design, schematics and code in progress on my blog so anyone can offer feedback as it gets built.

Published by


Chad is a software developer from the Houston, Texas, USA. He's been working in the software industry since the 1980s and presently works for Alert Logic, a provider of managed security-as-a-service solutions for the Cloud. He spends way too much time bicycling or playing with cars.

13 thoughts on “Jeep Bot – Proof of Concept #1”

  1. I’m curious why you decided to go with an arduino as your final solution rather than the RPi. I have both and think the pi is much easier to program, more resources, faster clock etc, just way more powerful in general. There seems to be plenty of room for worse behind the dash.

  2. The RPi isn’t very good at real-time behavior, and especially the CAN-BUS drivers available for it tend to be laggy at inopportune times. You can make it work but it winds up being a lot more work.

    And, frankly, CPU horsepower is not the limiting factor in here. The RPi is way over-kill for this and consumes a great deal more power than needed because of it.

    And when you get to GPIO handling, I don’t actually find the RPi easier to program. The wiringPy or RPi.GPIO python libraries are great, but I still don’t find them easier.

  3. Have you made any more progress with this yet? I am hoping to do something similar to this with my Ram. I have found an OEM Aux switch panel that is intended for the 2500+ Rams. I have been able to wire it to my truck. However, the truck doesn’t recognize the panel.

    I assume that the panel never gets activated as the truck powers up. I would like to develop an interpreter for this. i.e. when the truck tells the stock panel to wake up, the interpreter would wake up the new panel. When a button on the new panel is pressed, the interpreter sends the equivalent command that the original panel would have sent.

  4. Hi i know you are busy is it possible to send me the Rpi compiled image.
    Thank you

  5. Very interesting stuff. I’d like to start hacking my 2008 Jeep WK.

    I was wondering if you are able to enable, or disable, things within the Jeep via the canbus?

    Specifically, I want to enable the rear defrost and seat heaters if the temperature falls below X degrees. I can do a sloppy hack with a circuit board (LM57 + one shot) that momentarily closes the switch, and then physically solder the connections to the switch. But I’d rather use the canbus if possible.

    I don’t even know if the canbus has messages for the seat heater or rear defrost, and I don’t know if it is possible to enable these systems from the canbus, but considering you found steering wheel messages, I wouldn’t be surprised.

  6. Keep in mind that the messages in your 2008 will be different than in the data I’ve published. They changed all of the CAN bus message IDs in 2010 I believe, but the general format of how things work will be similar.

    The answer to your question is: probably, but it will depend. What you will find by looking at the data is that the CCN module does in fact send out those messages over the interior bus, and the TIPM will power the defroster, etc. That implies you’d be able to send out your own message whenever you want.

    What will get in the way however, are two things:
    1. Can you do that in any power state, or will the TIPM ignore the message if the car isn’t in the right mode? That’s probably OK depending upon your use case.
    2. Does the CCN send out an ‘off’ message for the switch you are trying to turn on all the time, or is it only sending out messages if the switch is ‘on’? I’ve seen various behaviors from the car on this. If the message is sent out constantly, all you wind up doing is fighting with the CCN. If it is periodic, then you can control it.

    Other approach would be to become a LIN slave to the CCN, and tell the CCN the switch is active and the rest happens with the car.

    I think in this particular case, you’ll be OK. The automated HVAC controls are already doing this in the newer JKs. I’m not sure in the 2008 if the HVAC automation was an option for not.

    In any event, don’t be shy about hooking up a monitor and seeing what data you get. It’s good fun and it’ll help you figure out the right approach.

  7. Great project, and I think I have read every article you have posted and watched every Youtube video that you have posted about it. Now that it is 2019, are you still using the Jeep/switch bot boards? Or did you go a different route? I am asking since I am in the process of doing something similar with my wife’s 2016 Cherokee, I am needing to control some lights using factory lighting, and of course it is all canbus now days, which doesn’t make it fun for anyone.
    My point is this, if you did this same project now, would you use the same hardware choices? Or would you go a different route?

    I am a network engineer (20 plus years) and a ham radio guy, so a challenge like this is right up my alley, just trying to figure out the hardware I need to get started.

  8. Amazing how quickly time passes…

    I’m back to tinkering with this… relocations and new jobs have a habit of derailing my hobbies for a bit.

    To answer your question, I’m pretty happy with using an ATMEL microcontroller (what Arduino uses) just because it is so, so easy. There are other cheaper choices out there, and a solid embedded engineer may chose a microcontroller that has CAN bus directly built in. For example, I have a dev board from Microchip that does both, and TI has some wonderful automotive grade solutions as well…. but it’s still really cheap to do it with an ATmega368P and a couple of Microchip CAN ICs as well.

Leave a Reply

Your email address will not be published. Required fields are marked *