Ford Transit USA Forum banner
41 - 60 of 84 Posts

· Registered
Joined
·
319 Posts
Discussion Starter · #41 ·
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.
 

· Registered
2021 AWD High Roof Passenger Van
Joined
·
37 Posts
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.
 

· Registered
Joined
·
319 Posts
Discussion Starter · #44 ·
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.
 

· Registered
Joined
·
141 Posts
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.
 

· Registered
Joined
·
2,152 Posts
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.
 

· Registered
Joined
·
141 Posts
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.
 

· Registered
2022 Cargo Extended HR AWD EcoBoost W3U
Joined
·
60 Posts
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: brío

· Registered
Joined
·
2,152 Posts
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: brío

· Registered
Joined
·
2,152 Posts
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.
 

· Registered
Joined
·
2,139 Posts
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.
 

· Registered
2020 High-Extended AWD EcoBoost Cargo with windows
Joined
·
5,278 Posts
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:
 

· Registered
Joined
·
2,139 Posts
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.
 

· Registered
Joined
·
141 Posts
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).
 

· Registered
Joined
·
2,152 Posts
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.
 

· Registered
Joined
·
2,152 Posts
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.
 

· Registered
Joined
·
141 Posts
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.
 

· Registered
2022 U8U
Joined
·
759 Posts
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.
 
41 - 60 of 84 Posts
Top