[Tuckie]

That has to be the most impressive Victron setup I've ever seen! If you ever decide to sell your vehicle, I imagine Victron would love to take it off your hands for road shows You wouldn't happen to have any wiring diagrams (even sketches) would you?

I am of the same mindset (and similar plans) on automation. I don't want a wall of thermostats and controls, just give me automation based on battery condition, driving/parked, outside temp, tank levels etc. Like others have mentioned, my plan of attack is ESPHome + Home Assistant. FYI, MQTT control is still an option with HA, so you could integrate the work you've already done. There's also a Victron integration as well. ESPHome is especially nice for the climate controls.

Do you have any details you could share on the Cruise N Comfort AC wiring (and the Maxxfan)? I reached out to them for details and got nowhere (they won't even provide a manual for their wifi thermostat so I have no idea what capabilities it has). Undermount AC at least publishes their wiring diagrams, but they don't offer a true 24 volt system.

 

[Tuckie]

@Tuckie Cruise-N-Comfort

Thanks! Still not quite sure how the evaporator controller and thermostat controller translates to a pinout/interface, so I hope you will share your endeavors as you progress. I plan to build out an esphome-based climate system with fan speed control (including the outside fans in parallel/series config).

MaxFan - This is the circuit diagram for the RJ-45 connected 6 button panel.

This looks much more straightforward, I was hoping for a bit more smarts there as far feedback, but what can you do I did find a similar attempt at controlling it here:

What are some options for variable speed control of fans via microcontroller?

I was really hoping that this was going to work for you, but it looks like it can't quite handle the load. As an aside, if anyone hasn't heard of m5stack, I highly recommend it for adding a bit more polish to your esp32-based projects if they happen to sell the pieces you're looking for. I used their rs485 module to make dead-simple adapter for converting a dmx light into a wireless esphome-based smart light.

On the more general automation front: some ideas I have knocking around:

• automatic winterization (compressed air)
• automatic water filling (using a nmea2000 seelevel)
• freeze protect with hydronic heat (multiple thermocouples on key systems)
• humidity regulation with maxxfan and ac
• kitchen fumes with particulate sensor and maxxfan
• automatic shutdown of non-essential systems based on battery level (home assistant can handle the modbus interface with victron)
• water/hydronic heat electric dump load when batteries are topped up and there is still sun in the sky
• bluetooth proximity-based system wake

A goal of the system for me is a simplification of the user interface. With home assistant I can create that single pane of glass of all parts of the system, and prevent the wall full of displays (aka basket of remotes).

 

[Tuckie]

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:

• ESP32-POE-ISO Olimex LTD | RF/IF and RFID | DigiKey (POE & verified working with ESPHome)
• Shelly Pro 4PM (Would be a good central control unit for AC Loads)
• Shelly Pro 2PM (Same as above... hoping that you could load custom firmware onto it like other shelly products)
• Shelly Pro 2 (dry contacts for DC loads)
• QuinLED-An-Penta - quinled.info (Good for LED dimming over ethernet... when it gets released)

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.

 

[Tuckie]

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.

 

[Tuckie]

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).

 

[Tuckie]

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.

 

[Tuckie]

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.

That's definitely my preferred route too, if it can handle the traffic volume. It looks like there's support for the MCP2515 too. I thought this was an interesting idea to bridge the esphome and opendbc projects.

 

[Tuckie]

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

 

[Tuckie]

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.

 

[Tuckie]

I'm leaning towards putting much of my work out there for others to continue.

Any work you've done would be very much appreciated for myself and the community! A Github repo would be fantastic, even if you want to immediately mark it as archived.