[Sparky961]

I don't have time to read this now, but I love it already. I'd love to learn more details.

 

[Sparky961]

Your rear end is a work of art!

NO, NOT LIKE THAT! 😛

The layout is clean and just plain well done. Good job with that. It looks like someone opened up a panel on the ISS. (Okay I'm only guessing on that one...)

 

[Sparky961]

If someone wants to ship me a unit for non-destructive reverse engineering, I'd be happy to do it just for the challenge and bragging rights. I'll return the unit (your postage) undamaged or purchase/replace it in the rare event that I screw up.

I can almost guarantee that I'll be able to tell you how to hook it up and control it. Possibly multiple ways if they exist.

I figured out my Propex, but it is admittedly pretty darn simple. I'd love to see what's going on with the CANBUS on some of those units and add the capability into my own control system for future flexibility.

 

[Sparky961]

This thread is not the place to discuss the pros/cons of automation.

I was wondering how long it would take before people started taking it that direction. When it happened to me a while back it caused me to post a lot less overall here, and of much less technical nature. An unfortunate loss for many, as I've done some very interesting things.

 

[Sparky961]

What are some options for variable speed control of fans via microcontroller? Mine is [email protected], full speed. The idea to automate it comes and goes for me with the seasons, but the season where it's more important is coming soon!

Lower cost gets more points. 😉

 

[Sparky961]

I started out with a screen (RPi) and eventually decided that it was too much hassle. Pretty much everything I have control over and that can be displayed is now accessed through my smart phone using an MQTT app. The app is just one I downloaded and stuck with after trying a few. It doesn't suit my needs 100%, but it was very low effort and swapping in some other interface in the future is very easy.

[CLICK THUMBNAIL FOR FULL SIZE]

It changes occasionally, but that's my current setup. Simple, as I like it.

 

[Sparky961]

Now we just need to perfect wireless power and we're set!

Yes, I know batteries are a possibility, but no - I'm not going down that road for multiple nodes in a control system.

Maybe micro-atomics...

 

[Sparky961]

My intention is to run regulated 5VDC power feeds throughout the van, just as we do with 12VDC. Of course 12V-5V buck converters are also trivial.

I also intend to deploy the nodes in a way that is robust to central failures. I am treating HomeAssistant as icing, not the cake.

But the question then remains, since power needs to be run to each module, why not communication bus wires too?

 

[Sparky961]

Teaser...

I'm pulling both the publicly known OBD2 PIDs plus a few of the many, many proprietary PIDs using RPi connected via some interface circuitry to HS-CAN.

Click thumbnail...

And yes, I'm also able to control a few things... Like the RPMs. 😁

I'm working on putting my mess into a usable library.

 

[Sparky961]

Where do you connect with the Transit CANbus? The OBD connector or elsewhere?

I've Tee'ed into the OBD/DLC with a splitter. This made it so I didn't have to modify any factory wiring. Unless someone gets their head right in there, there's no obvious sign.

I suspect there are also HS-CAN and MS-CAN wires running in the main bundle along the driver's side. I just haven't looked into it.

 

[Sparky961]

I love the idea of simplifying hookup/integration. What are you writing this in? I would like to make an esp32/arduino version of this library for fast boot times and low power draw. Heck, just documenting the PIDs is awesome.

Some pie in the sky ideas:

• virtual ignition signal
• battery voltage
• specific door open status for lighting control
• oem cabin lighting status/control
• display alerts on dash/trigger alarms (grey water tank full, you're still plugged into shore power!)
• prevent ignition/drive (same reason as above)
• gas tank level (if this available when the car is off, it would make a great way to have a configurable threshold for a gasoline-based heater)
• gps coordinates (one less thing on the roof)
• head unit control (next track, volume up/down etc)
• interior/exterior temperatures (probably only useful if it is available when off)
• lock/unlock/remote start (battery low? Run until topped off)

I realize some of this would require some very proprietary info or access to a different data bus. There may be more to glean at https://developer.ford.com/, but it looks like they lock much of the obd stuff behind a firmware blob.


The other option I have been pondering is some sort of interface with an idatalink product to handle the heavy lifting, but I can't find anything about their own serial data protocol.

My implementation is split between a Raspberry Pi 3B+ and an Arduino board that plugs directly into the Pi. I'm thinking it might work with only an ESP32 board but haven't taken the time to research it.

As I've mentioned before, I'm working on putting together an easy to use library based on SocketCAN, so anything with that and some additional interface hardware would work.

As for your list, most of that is covered:

Ignition - almost certainly, need to verify

Battery voltage - yes

Specific doors - probably, but this is on MS-CAN and I don't currently have it connected to verify

Cabin lights - probably, same as above

Dash alerts - that one is harder but not outside the realm of possibility, certainly something I'll look at

Prevent ignition/drive - unlikely, that's a high expectation [EDIT: after some consideration, maybe there's a security mode that could be enabled to prevent start, research required]

Fuel level - Yes, but only with key on. Same holds true for just about any CAN communication we're interested in. That system draws a LOT of power and wouldn't last long without power input.

GPS Co-ords - probably, I've seen PIDS related to this but don't have GPS integrated into my own van to test. Things like this will require volunteers to test in the future.

A/V control - maybe, there's a third bus that a lot of this runs on and I haven't looked at it in detail yet

Temperatures - yes, but again only key on

Lock/unlock/start - maybe, but I think only start for models with a start button, which mine isn't. Locking and unlocking may require two additional connections, as I haven't had success on that front using only CAN.

 

[Sparky961]

Thank you for the details! Safe to assume python?

No, not safe at all. Most of what I write is in C and C++. I dislike interpreted languages for anything "serious".

I'm sure there could be a wrapper or something to use it from Python though. A lot of low level functionality is done that way.

 

[Sparky961]

It should be doable: Controller Area Network (CAN) - - — ESP-IDF Programming Guide release-v3.3 documentation

This document describes the controller interface and custom driver functions for it. SocketCAN is one level (or more) up from that. The idea being hardware abstraction, and thus nothing I need to do to support other Linux compatible hardware.

One problem I've found with my current configuration is that it's CPU intensive and sometimes it can't keep up with the high amount of bus traffic - or I'm doing something wrong, but no idea what. There is hardware CAN ID filtering in the hardware I'm using (MCP2515 SPI modules) but it isn't implemented in the kernel overlay drivers. I've seen mention of another version that does, but building stuff like that is rarely worth the effort.

What I'd kill for is a powerful Linux-based SBC with some realtime capabilities, and at least 3 hardware CAN controllers plus hardware interface line drivers. Why do they always leave out the drivers? Maybe silicon water real estate?

I'm guessing there are some automotive chips that would fit the bill but nothing widely available that I'm aware of.

 

[Sparky961]

Specific doors - probably, but this is on MS-CAN and I don't currently have it connected to verify

@Tuckie

Confirmed individual doors are available and it's even on HS-CAN, which makes it easier.

Stay tuned. I have a lot of discovery and data entry and do plan to make something publicly available when I can.

 

[Sparky961]

That's great news! Thank you for all your work!

Thanks, but don't thank me yet. It's a slog for sure.

It would be great to have some competent others that could help with the drudgery of filling in the details... For anyone who is willing to directly access the CAN bus(es), and issue a series of harmless commands while taking note of the output, contact me via PM and I'll try to give you more details. I don't have the time to hold anyone's hand in setting this up though, so I'm probably fated to doing it myself.

 

[Sparky961]

Currently researching the the capabilities of RV-C, an extension of CAN bus that is used in the RV industry.

Pros:

• open protocol specs
• Potential interoperability with existing products
• Proven physical layer
• no single point of failure
• supports multiple device instances with dynamic addressing and automatic device discovery

Cons:

• Those standards aren't always followed
• Severely lacking in open source library support. Most work seems to be surrounding OS-level integrations, instead of lightweight microcontroller-based nodes/devices. If someone can find otherwise, please let me know!
• Some existing devices are locked behind OEM installers

Edit: @Sparky961: I would love to help on the Transit CAN bus front, but unfortunately, my Transit is currently in the waiting to be in the "2023 waiting list" list.

If needed, I'll do my best to answer any questions related to CAN interface and implementation of the Transit. I've taken a pretty deep dive into this stuff.

As I've alluded already, I may be winding down the van living thing in favour of sticks and bricks soon. I'm leaning towards putting much of my work out there for others to continue.

 

[Sparky961]

Looks like I found the nerd thread.

Anyone know of a shunt that doesn't need excessive investment (time or money) to get onto a bus? Just starting down this rabbit hole, I paid a little extra for an inverter/charger that supports NMEA2000, which I can access with a PICAN-M or a cheap Arduino-based standalone N2K display for, but I really want the shunt data as well. I'm really only looking to monitor at this point, but maybe if I tackle this and run a small SQLite DB, I can do a little more w/ the historical data after.

Looks like the Victron SmartShunt will do it if you connect to the Cerbo GX and get the VE.Can/N2K adapter, but that's a $650 investment in Victron bits over VE.Direct! Sorry, doing realtime discovering while I'm posting.

GitHub Public Release, "Offgrid" Van Controller

With little fanfare, I'm announcing the release of the following companion projects: Main "server", running on Raspberry Pi: GitHub - TheWandrr/offgrid Slave controller running most peripherals: GitHub - TheWandrr/offgrid_arduino First time EEPROM initialization, or bulk changes...

www.fordtransitusaforum.com