Ford Transit USA Forum banner

Van automation (Technical Discussion ONLY)

15K views 83 replies 23 participants last post by  edumartins 
#1 ·
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
8
Discussion starter · #8 ·
I don't know how committed you are to your current path, but if you were starting from scratch I would strongly recommend you take a close look at Home Assistant and ESPHome. They are a hugely popular and active open-source project intended to do exactly what you are envisioning. I believe that you could accomplish 100% of your goals with 30% of the time and effort.

That said, I do understand that sometimes it is the journey and not the destination, so you may have very good reasons to continue down your current technical path.
I haven't looked at either really. These days I pretty much assume everything involves an internet connection and a phone app. I don't need to remotely do anything (even though I will add a secure way to do that in the future) and I'd prefer to just throw my phone away. The other big thing is that the interfaces I'm building are all custom, so at some point I'm going to have to do a lot of work. I'd much rather fit it into my framework than adapt it. My way probably isn't better, but at least I know how the pieces fit. And as you say, it is a journey, I started the project knowing that it probably wouldn't be completed before moving on to the next thing. A lot of things I've tried to make modular to facilitate that transition when it comes.
 
Discussion starter · #24 ·
@Tuckie Cruise-N-Comfort

Rectangle Product Slope Font Parallel


I specifically requested the dumbest possible setup. I think they're working on a panel of some kind but I was very adamant with Chris that I'd prefer 'bare wires'. It's pretty simple, the 'Temperature Control' is just a temperature activated relay. It came with one of the capillary tube based ones, which I've temporarily replaced with some cheap programmable temperature relay from Amazon.
 
Discussion starter · #25 ·
MaxFan - This is the circuit diagram for the RJ-45 connected 6 button panel. If this doesn't make sense to you, well it doesn't make sense to me either. I recreated this exact setup with relays where the membrane button contacts were. Simulated finger presses if you will; 50ms is all you need.

Handwriting Rectangle Font Slope Parallel
 
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.
 
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.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top