Ford Transit USA Forum banner

Van automation (Technical Discussion ONLY)

9967 Views 83 Replies 23 Participants Last post by  edumartins
8
As I have hinted in other threads I have been working on an automation and control system for the van. The 3 phases of this project are:

1. Single pane of glass control of all devices (to include vehicle controls as well)
2. Sensor and data collection; local and internet
3. Automate various tasks based on sensor data

Step 1 involves turning most of your disparate 'dumb' devices into relays which can be controlled by the MCUs. Some things like the MaxFan and the CnC AC are pretty straight-forward. I haven't started on the Espar yet, but I imagine I'm in for a load of fun. As for vehicle controls, they're pretty well documented, and for the most part I will render the physical vehicle controls inoperable. This also includes relay controls for lighting, pnematics, and really anything else that needs a power switch.

Step 2 is gathering the values which will be needed to make the automation workflows. Throughout the van there will be sensors that I will install such as temp/pressure/contacts/lidar/ultrasonics, etc. In addtion, the CerboGX has a ton of data on the electrical system, and there are also various APIs I can pull from online, such as weather data. I also have OBD-II data feed and the vehicle status outputs from the High Specification Vehicle Interface Connector.

Step 3 is the fun part. Most of automation will revolve around lighting and environmental controls. I will be able to write logic using any of the sensor data collected to make these tasks as intelligent as possible. For example, the solar panels might only extend if the vehicle is off, distance sensors detect no obstructions, the weather report says winds are less than 50 mph, and the system SOC is less than 90%.

All of this is accomplished with various MCUs around the vehicle collecting sensor data and controlling relays. This data is all sent to an MQTT server where other MCUs can act on the information. This is a fairly common and well documented method of DIY automation. I'm using Teensy 4.1s because of the built-in ETH PHY along with the extremely beefy (for an MCU) hardware specs. For example my panel code is already using 200 Kb of RAM whereas your standard Arduino Uno only has 2 Kb of RAM max.

The panel is an 800x480 capacitive touchscreen and is essentially stateless like all the other MCUs. I'm making a few more at the moment for the inside and rear of the van. On powering up it pulls all the MQTT topics which describe relay status and other variables and is able to immediately represent the status of the system. This happens anytime the topic values are updated, whether it's another panel changing something or automation code.

As with everything in the van, the current status is "temporary working example". I'm not particularly fond of the GUI I came up with, but I did just refactor all the backend code to make additions to the system very easy. It's really down to building proto-boards at this point in order to bring everything up.
Communication Device Tablet computer Gadget Mobile device Output device

Circuit component Electrical wiring Hardware programmer Passive circuit component Electronic engineering

Passive circuit component Circuit component Hardware programmer Electronic engineering Electrical wiring

Passive circuit component Circuit component Automotive tire Bumper Electrical wiring

Circuit component Hood Gesture Finger Hardware programmer

Product Tablet computer Communication Device Gadget Output device

Output device Communication Device Gadget Mobile device Portable communications device


BONUS pic of electrical system...
Motor vehicle Vehicle Trunk Automotive design Mode of transport
See less See more
  • Like
  • Wow
  • Love
Reactions: 5
41 - 60 of 84 Posts
There is no compelling argument against a hardwired LAN. For many years, I was strongly in the "use wires whenever possible" camp. But, confronting the practical realities of my upcoming build, combined with real-world experience with ESPHome has caused me to reevaluate. I am actually kind of surprised that my position has changed on something that I once thought was totally obvious, but it has. If I were designing some closed system that I believed would rarely change (e.g, an HVAC system in a large building) I would still tend to prefer wire. But, all of my vans have proven to be open-ended experiments, and that tips the balance for me.

This is not an issue that I feel like proselytizing about -- there are arguments both ways. But here are what I see as the arguments for wireless:

--WIreless technology, and WiFi in particular, has become VERY robust, due to its wide deployment in the consumer world. The likelihood of serious performance or reliability issues in machine-to-machine applications has gotten very low.
--Wireless is likely to be more robust, not less, in a mobile environment, since there is nothing physical to break (to speak of). And, most problems can be debugged without often-difficult physical access. Of course, wired LANs can be made arbitrarily reliable, but doing so is neither easy nor inexpensive. I have no problem with folks who enjoy this challenge, but do not underestimate it.
--Comparing LAN wiring with power wiring is fair, but the fairness depends on the choice of LAN topology. Most wired LANs use star topologies for bandwidth and maintainability reasons. Such topologies are a lot more complex than a simple electrical bus. The historical exceptions, such as RS-485, have many limitations and tend to be difficult to scale. This, of course, leads to CANbus. There are very good reasons why the automotive industry has gone this route. It is a true distributed daisy-chain network and is indeed on the same order of complexity as power wiring. If you are prepared for all of the complexity of going to a CANbus-based system, then I have no quibble with it. Be prepared for a science experiment, though. And make sure that the wiring is very robust, since every inch of it is a potential point of failure.
--Extensibility: This is probably the thing that tipped the balance for me. With a wireless lan, slapping in a new node is a casual project, anywhere power is available. For example, deciding to put a new light switch somewhere you overlooked is trivial. Putting a temperature sensor on your under-chassis tanks--no problem. If your style is to design/build/walk-away, this doesn't apply. But, that is not my style at all.
--Maintainability: The thing that won me over to ESPhome in particular was the seamless way they handle OTA updates. Once ESP is running on a node, you never have to plug it into a computer again. Remote updating is like falling off a log. You can add features from the comfort of your living room. Yes, this could in principle be done with CANbus etc, but actually doing it with hobbyist MPUs would be quite a project as far as I can see.
--Hardware simplicity: The existence of SOC processors with on-chip WiFi an Bluetooth (such as the ESP32) means that simple nodes can be almost unbelievably simple from a hardware perspective. And simple means reliable. Again, not a show-stopper, but I have found working with such MPUs to be incredibly pleasant and productive,

Again, I am not really trying to convince anybody here--I will leave it to someone else to develop the list of advantages of wired LANs. But I did want to lay out the arguments that led to my conversion on this point.
I have several issues with wireless:

1. Unless you're running dot1X, you wireless is trivially hacked.
2. There are so many interference sources on 2.4 these days, and even 5 is started to get crowded. Do you have a microwave in your van?
3. Wireless is still a CSMA-CD type of medium, so each additional node reduces performance for all users. I do have wireless for entertainment uses, and I want it to be as fast as possible.

Not really an issue, but in my case, the MCU's are all powered over PoE, so hardwiring them solves two issues at the same time.
Do you have a microwave in your van?
Yes. And I would bet real money that it will not affect my network in any meaningful way.
  • Like
Reactions: 1
Not really an issue, but in my case, the MCU's are all powered over PoE, so hardwiring them solves two issues at the same time.
what PoE MCU are you using? And what PoE switch do you use to power them?

I’ve been a long time fan of wired Ethernet but given the ESP32 price and availability I’ve been switching more and more to wifi.
what PoE MCU are you using? And what PoE switch do you use to power them?

I’ve been a long time fan of wired Ethernet but given the ESP32 price and availability I’ve been switching more and more to wifi.
It's a hack. I have 24V PoE set always on at the switchport, then on the MCU end, I have one of those splitters to RJ-45 and a barrel jack. The barrel jack goes to a 24V-5V DC-DC converter.
  • Like
Reactions: 1
My ideal setup would be modbus throughout with interconnected nodes, but I'm looking for a low code option, so that leaves Ethernet.

Some components I'm considering:

Edit: What I would really like to find is a clean, scalable way to handle load monitoring and switching of DC loads (Fridge, Water Pump, Aircon, etc). In a perfect world, this could potentially even detect a failing component.
  • Like
Reactions: 1
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...

Font Technology Electric blue Science Darkness


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.
See less See more
  • Like
Reactions: 5
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.
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.
See less See more
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.
Where do you connect with the Transit CANbus? The OBD connector or elsewhere?
Subscribed! We're in the early doodle phase of our build, and I'm looking at various automation ideas.
My ideal setup would be modbus throughout with interconnected nodes, but I'm looking for a low code option, so that leaves Ethernet.

Some components I'm considering:

Edit: What I would really like to find is a clean, scalable way to handle load monitoring and switching of DC loads (Fridge, Water Pump, Aircon, etc). In a perfect world, this could potentially even detect a failing component.
The Shelly RGBW2 is perfect for dimming over WiFi Ethernet. I used MQTT to integrated it with Node Red and use a Node Red dashboard with a custom slider that I found to dim the lights in my mock up for the van (still waiting on the van..)
  • Like
Reactions: 1
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.
  • Like
Reactions: 1
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.
See less See more
What you’re missing is the ability to automate. If you put it all on one automation system then you can now have things happen automatically based on state changes. So if for some reason you want to turn off your AC and go ahead and switch to fan based on some rule like “if ambient outside temp is below 78F and battery capacity is below 40%” or whatever.

These are things that can happen while you’re sleeping or while you’re not even at the van.

I can see uses for this, but you’re not wrong that it’s also a potential failure point. Obviously folks engineering these systems have some level of trust that they can fix it in the field if necessary, especially if it’s a system you wrote from the ground up. I personally love the idea enough to follow it, but not quite enough to bother in my own van.

I would be willing to donate to a project to reverse engineer the Espar, though not because I want to automate it, just because I want to replace the incredibly annoying control unit it ships with. I pretty much hate how it works.

—Donnie
I have to admit I'm of the same mind as Kenryan. It's just not that difficult to enjoy an RV without a centralized system, even though I do like having app/phone control, and I agree that gas and diesel heaters are one glaring exception in terms of how far behind the smart control curve they are.

But going crazy automating every last thing, all of the hours and hours of labor, all of that space for tons of wiring and hardware seems a bit overkill, not to mention vulnerable to malfunction. It looks cool, sure, but would I trade the loss of space and the maintenance considerations for something my rig mostly accomplishes already with a largely hidden (under the bed) power system? I don't think so. When I open my rear doors I see the sunset and the waves lapping the beach before a beautiful blue ocean, not the inside of a mainframe computer.

My AC Infinity T6 fans already offer automation for a mere $50 upgrade that gives you a killer app, schedules, temp and humidity triggers, etc, and the minisplit can already be programmed for all kinds of automated functionality or even just stay in a sleep state in eco mode until temps cross above its setpoint. Both can also be programmed from my phone or the laptop or their physical interface or remote control. And it didn't require any extra cost or time. I've spent so many hours building that any project that increases van complexity is seen as more sad days spent doing the opposite of why I built a rig in the first place.

Having said that, tapping into the Ford system is highly desirable. There are numerous features about the van itself that I'd love to be able to change.

But having my led light strip automatically turn on/off? Why? I wake up and take naps and go to bed at slightly different times everyday, so any automation just becomes a headache to constantly reprogram to try to meet my evolving needs.

Okay, I'm probably coming across as a jerk here, so apologies if it reads that way. I guess I'm just so dang happy to actually be enjoying my rig after years of work that I'm probably just temporarily biased against some of this. I did automate many safety features in my power system, and who knows, maybe someday I'll be willing to give up more months of my life automating everything. Then you guys can all say "I told you so." Lol.

Cheers.
See less See more
I have to admit I'm of the same mind as Kenryan.
...
I think this is why @sYfte made the title, "(Technical Discussion ONLY)" - in hopes that we'd keep the debate out of the thread. Can't blame a person for trying... :LOL:
  • Haha
Reactions: 1
I think this is why @sYfte made the title, "(Technical Discussion ONLY)" - in hopes that we'd keep the debate out of the thread. Can't blame a person for trying... :LOL:
Well technically I did discuss the automation capabilities of AC Infinity Cloudline T6 fans and Carrier minisplits. Lol.

And I thought maybe the title was reverse psychology, given how no thread on any internet forum in history has ever remained on point for long.

I'm also pretty sure some of those photos were intended as eye candy, and don't exactly qualify as technical discussion :)

All I know is one run of 10awg wire, a single dc breaker/switch, and a single 150V mppt that are all totally hidden from view (and don't obstruct any nature views) were all it took to wire in 1110W of solar to my power system, which is proving to be more juice than I need to keep the van icy cold.

But I won't lie, his ADHD-pleasing setup has the eye candy cool factor at a level my rig never will. I do give props for that. But I'm usually trying to hide my treasures from the mass of humanity, not attract them to it. And I want every last inch of free space available in the van for storage, for those bad weather days when I need to stay inside, and mostly to prevent anything from blocking my view of mountains, oceans, lakes, rivers, sunsets, etc.

Maybe I'm just disgustingly anti-social though. Probably something to that.

Cheers.
See less See more
  • Haha
Reactions: 1
Shelly RGBW2 is perfect for dimming over WiFi Ethernet.
Shelly makes good stuff, just looking for a more hardwired option.

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.
It should be doable: Controller Area Network (CAN) - - — ESP-IDF Programming Guide release-v3.3 documentation

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.
Thank you for the details! Safe to assume python?

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]
Awesome! Thank you!

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.
I would be happy to help (assuming there's an end to the supply chain issues).
  • Like
Reactions: 1
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.
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.
See less See more
No, not safe at all. Most of what I write is in C and C++. I dislike interpreted languages for anything "serious".
No worries, I only saw mention of python during a quick look into the SocketCAN project.

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.
Not quite what you're looking for, but have you by chance come across the comma.ai project? They're doing some interesting things to create a plug and play self-driving car, but as a side-effect, they've built out interesting hardware with open-source firmware, mapped out a lot of vehicle-specific traffic, and built tools for sniffing the traffic yourself... the bad news: the hardware itself is closed-source, but hopefully these pieces might at least provide some inspiration for you.
For you Home Assistant fans, note that ESPhome has a CANbus module.
CAN bus
It supports both the ESP-32's internal CANbus transceiver and external CANbus modules such as the TJA1050 (which interfaces to the ESP via SPI). So, the low-level CAN stuff is all nicely done in a dedicated ESP, in proper edge-computing style. This is how I intend to proceed, at least at first.

People have also gotten the Canable USB/CAN device working directly in Home Assistant, but that would require plugging the Canable device directly into the RPI, which I am trying to avoid.
  • Like
Reactions: 2
41 - 60 of 84 Posts
Top