[gregoryx]

I skimmed this and other threads, but I couldn't tell - has anyone done any prior work here on CanBus integration into Esp Home? I don't mean via Cerbo GX, but directly with the target device.

Context - I'm planning to tap into Victron comms ports on my batteries, but not going via Cerbo GX, but rather connecting directly to their ports from ESP32.

It's a long story, but TL;DR is that I run a 2S2P setup that isn't supported via their Victron comms, and naively connecting apparently just results in mangled inputs, so my plan is to just bypass all Victron, tap directly into each of those batteries from an ESP32, and monitor them outside the Victron system.

AFAIU from a quick search, ESP32 contains built-in CanBus support, and I need a trasceiver to match the voltages. Sounds doable?

I'm curious if there's any prior work here on something similar in case I could reuse it and not reinvent the wheel that's already been invented. TIA

I haven't heard of that being done; but that doesn't mean it isn't, of course. My understanding is that CAN messaging is challenging to sniff out; maybe the first question is whether you can get some published information from your BMS? If not, I suspect it could be pretty rough.

If you're not in the Smarty Van Discord, there's some pretty sharp folks there - at least one or two might have more insights on the CAN situation.

 

[dhagberg]

This discussion and associated github project might give you some ideas - talks about interfacing with the Rixens heating system via CANBus:

https://www.fordtransitusaforum.com/threads/rixens-hydronic-heating-mcs7-can-bus-control-via-esphome-home-assistant.97261/

And I've ordered the nice ESP CAN "hat" and kit from MrDIY that should (I hope) provide the right voltage interfacing with CANBus:

ESP32 CAN Bus Shield – Store – MrDIY.ca

store.mrdiy.ca

 

[Irontent]

I skimmed this and other threads, but I couldn't tell - has anyone done any prior work here on CanBus integration into Esp Home? I don't mean via Cerbo GX, but directly with the target device.

Context - I'm planning to tap into Victron comms ports on my batteries, but not going via Cerbo GX, but rather connecting directly to their ports from ESP32.

It's a long story, but TL;DR is that I run a 2S2P setup that isn't supported via their Victron comms, and naively connecting apparently just results in mangled inputs, so my plan is to just bypass all Victron, tap directly into each of those batteries from an ESP32, and monitor them outside the Victron system.

AFAIU from a quick search, ESP32 contains built-in CanBus support, and I need a trasceiver to match the voltages. Sounds doable?

I'm curious if there's any prior work here on something similar in case I could reuse it and not reinvent the wheel that's already been invented. TIA

Here is another ESP32 solution for CANBUS -- might be cheaper than the one mentioned above?

Adafruit has a shield for their Feather line which should plug directly into any of the ESP32 feather versions they sell.

Adafruit CAN Bus FeatherWing - MCP2515

Adafruit CAN Bus FeatherWing - MCP2515

CAN Bus is a small-scale networking standard, originally designed for cars and, yes, busses, but is now used for many robotics or sensor networks that need better range and addressing than ...

www.adafruit.com

requires an SPI port and two pins for chip-select and IRQ. Use it to send and receive messages in either standard or extended format at up to 1 Mbps.

Since ESP32home has CanBus support they would likely work and you would flash the feather ESP32xx with the CanBus feather shield, and should be good to go AFAIK

I've used the two chips on the CanBus shield with code I wrote -- they are the most popular chips I think for CanBus now.

 

[chicagoandy]

I skimmed this and other threads, but I couldn't tell - has anyone done any prior work here on CanBus integration into Esp Home? I don't mean via Cerbo GX, but directly with the target device.

Context - I'm planning to tap into Victron comms ports on my batteries, but not going via Cerbo GX, but rather connecting directly to their ports from ESP32.

It's a long story, but TL;DR is that I run a 2S2P setup that isn't supported via their Victron comms, and naively connecting apparently just results in mangled inputs, so my plan is to just bypass all Victron, tap directly into each of those batteries from an ESP32, and monitor them outside the Victron system.

AFAIU from a quick search, ESP32 contains built-in CanBus support, and I need a trasceiver to match the voltages. Sounds doable?

I'm curious if there's any prior work here on something similar in case I could reuse it and not reinvent the wheel that's already been invented. TIA

I talk to my residential batteries over both canbus and rs485. Both are straightforward.

Rs485 is better as you can typically see cell level data. I use esphome and an rs485 library I found in GitHub, you'd want to fund the right one for your BMS. I use m5 stack components.

I also use canbus to pull data into a separate app called solar assistant and which is unrelated to home assistant. I do not use esphome for that one.

I would expect configuring the yaml to be fairly well understood as the protocol is widely implemented.

That said, I am surprised to see your challenges with victron and 2p2s batteries. You can connect two independent canbus wires, and each wire can have a master/slave setup. While I haven't done 2p2s I am conceptually not clear why it wouldn't work.

Victron supporting two canbus wires is relatively new, so I wonder if you are relying on older information?

 

[KRK]

I talk to my residential batteries over both canbus and rs485. Both are straightforward.

Rs485 is better as you can typically see cell level data. I use esphome and an rs485 library I found in GitHub, you'd want to fund the right one for your BMS. I use m5 stack components.

I also use canbus to pull data into a separate app called solar assistant and which is unrelated to home assistant. I do not use esphome for that one.

I would expect configuring the yaml to be fairly well understood as the protocol is widely implemented.

That said, I am surprised to see your challenges with victron and 2p2s batteries. You can connect two independent canbus wires, and each wire can have a master/slave setup. While I haven't done 2p2s I am conceptually not clear why it wouldn't work.

Victron supporting two canbus wires is relatively new, so I wonder if you are relying on older information?

I do remember asking the manufacturer's support tech about the two master-slave daisy chains on the two ports as I saw it somewhere on YouTube. It's been a while, but as I recall, the issue he described as the reason it wouldn't work was that the way the devices would report themselves to Victron if one were to setup a dual-master configuration this way was that they would alternately appear in Cerbo GX at different times, wouldn't be recognized as parts of a larger system, and DVCC would be getting confused by getting data points from two different sources mixed up together, which would cause issues with charging.

I don't know how much if at all that explanation makes sense, or if there's an easy fix to it, I have yet to read up on the Can Bus protocol to understand how it works. I recall hooking my batteries up, and seeing what appeared to be the behavior just like what he was describing. Perhaps indeed something changed since that conversation? I'll have to give them a call.

Anyhow - could you share some details of how you setup your ESP32 to retrieve data from your batteries' CanBus? Maybe I can reuse some ideas.

 

[chicagoandy]

I do remember asking the manufacturer's support tech about the two master-slave daisy chains on the two ports as I saw it somewhere on YouTube. It's been a while, but as I recall, the issue he described as the reason it wouldn't work was that the way the devices would report themselves to Victron if one were to setup a dual-master configuration this way was that they would alternately appear in Cerbo GX at different times, wouldn't be recognized as parts of a larger system, and DVCC would be getting confused by getting data points from two different sources mixed up together, which would cause issues with charging.

I don't know how much if at all that explanation makes sense, or if there's an easy fix to it, I have yet to read up on the Can Bus protocol to understand how it works. I recall hooking my batteries up, and seeing what appeared to be the behavior just like what he was describing. Perhaps indeed something changed since that conversation? I'll have to give them a call.

Anyhow - could you share some details of how you setup your ESP32 to retrieve data from your batteries' CanBus? Maybe I can reuse some ideas.

ESP32 CAN

Instructions for setting up the ESP32 CAN bus platform in ESPHome

esphome.io

Can would connect direct to gpio pins except the voltage is too high, there are adapter transceivers available, or you can roll your own.

You can find example yaml files for different bms's on GitHub.

I use can via a pi4, so I just use a can/USB cable

I use esphome with rs485, which isn't can.

Regarding victron, you could ask on the victron community, probably get a better answer than from a salesman.

 

[KRK]

ESP32 CAN

Instructions for setting up the ESP32 CAN bus platform in ESPHome

esphome.io

Can would connect direct to gpio pins except the voltage is too high, there are adapter transceivers available, or you can roll your own.

You can find example yaml files for different bms's on GitHub.

I use can via a pi4, so I just use a can/USB cable

I use esphome with rs485, which isn't can.

Regarding victron, you could ask on the victron community, probably get a better answer than from a salesman.

@gregoryx you mentioned it could get pretty rough, and I recall seeing such comments in passing in various threads, I think also on this forum. I understood this to mean that the protocol is proprietary and the format of the communication is not disclosed (i.e., not OSS anyway). Is that what you meant?

@chicagoandy right, my understanding is that ESP32 has built-in support and just bridging the voltages will allow me to see the data in ESP - the part that less clear to me is the above question to Gregory. Did you program yours based on some published protocol specs from Victron?

I've only just started digging into this, but it appears there are two Can Bus-like formats, one originally created by Victron, another developed by 3P, or did I misunderstand? Please correct me if wrong. TIA.

 

[gregoryx]

@gregoryx you mentioned it could get pretty rough, and I recall seeing such comments in passing in various threads, I think also on this forum. It understood this to mean that the protocol is proprietary and the format of the communication is not disclosed. Is that what you meant?
...

Correct. Just what I've read/heard: if you HAVE the library, not bad; if you're trying to extract it, not easy. But @chicagoandy is saying otherwise and he's got the legit experience with it.

 

[KRK]

Correct. Just what I've read/heard: if you HAVE the library, not bad; if you're trying to extract it, not easy. But @chicagoandy is saying otherwise and he's got the legit experience with it.

I see, ok. Since @chicagoandy was able to make it work, I guess the next step is to hook it up, and just see what comes out.

 

[chicagoandy]

I see, ok. Since @chicagoandy was able to make it work, I guess the next step is to hook it up, and just see what comes out.

In terms of batteries, the canbus protocol is fairly well trodden. The first battery vendor to use canbus was Pylontech, and they published their protocol. That protocol was copied by all the other BMSs, with minor changes but the Open Source people have done what they do and created githubs for all of the different BMS specific variants. That means for us, it's pretty straightforward to find the correct repo and run with it.

Yes, one of the flavors of battery CAN is Victron, but again, there's plenty of Open-Source work done here already. What is awesome is that Victron open-sourced the Cerbo software into "Venus OS", so anything you see for "VenusOS" also works on Cerbo.

Here's a repo called "Venus OS Serial Battery " that I think you'd find helpful. GitHub - mr-manuel/venus-os_dbus-serialbattery: Battery Monitor driver for serial battery in VenusOS GX systems. I'll qualify that I haven't used this. I try to avoid serial batteries if possible, native voltage is a better approach.

@gregoryx is correct that there is still a lot of murkiness on the CAN protocol for automotive, and well - everything that isn't a battery, charger, or inverter.

 

[onewomanarmy]

We're back at it with the van and digging into our electrical and HASS setup for the van. As is our way, we're probably wayyy over doing it, but having fun. As of right now (and subject to change at the drop of a hat) we're planning on mounting our mosfets and connections, as well as fail safe buttons, on the hinged seat bottom of one of our "dinette" seats using DIN rails and printed DIN rail connectors. Pictured below is the early mock up with 2 rails for mosfets (2nd and 4th row) with each mosfet row having a row of levernut connectors (rows 1 and 3) feeding into the mosfets (only the bottom right mosfet shows the lever nut in place). The different colors will be different zones or applications. To the right will be the 2 esp32s that will run each rail of mosfets. There will also be a set of buttons should we have connection failure.

This is the general idea -

This is what happens when it's too hot outside when you're ready to get back into working on the van. "LET THEM EAT CAKE USE HASS!"

Now to finish reading the tome that is this thread to see how we could BETTER do this. 😄
I've not even thought about CANBUS. We're on the ground floor right now.

 

[OldChubbyKnuckle]

Are you mounting your fail safe buttons on the DIN rail also? If so, which buttons are you using and which 3D printed model for them?

 

[larry barello]

I apologize in advance for what surely is a previously answered question in the forum: what solutions are available for a push on/push off switch that can be controlled by HomeAssistant and runs of of standard 12v house battery (e.g. 12.5-14v LiFePO4)?

I assume one of the shelly offerings are the most straightforward. Which one? Are there ESPHome compatible doodads available? I have all the parts to roll my own, but I don't want to package the parts. I did that for a refrigerator control and the bloody plastic box was probably the most expensive part!

Something packaged, COTS would be preferred: power, switch and load. Oh, illuminated switch or separate LED also needed to indicate state.

TIA

 

[gregoryx]

I apologize in advance for what surely is a previously answered question in the forum: what solutions are available for a push on/push off switch that can be controlled by HomeAssistant and runs of of standard 12v house battery (e.g. 12.5-14v LiFePO4)?

I assume one of the shelly offerings are the most straightforward. Which one? Are there ESPHome compatible doodads available? I have all the parts to roll my own, but I don't want to package the parts. I did that for a refrigerator control and the bloody plastic box was probably the most expensive part!

Something packaged, COTS would be preferred: power, switch and load. Oh, illuminated switch or separate LED also needed to indicate state.

TIA

Loads of options - lots of them pretty easy to do.

Did I miss where you say what the load is? Or how/what you'd want the switches to look/work? Anticipated details of load(s) - amps / dimming / etc?

 

[larry barello]

Loads of options - lots of them pretty easy to do.

Did I miss where you say what the load is? Or how/what you'd want the switches to look/work? Anticipated details of load(s) - amps / dimming / etc?

Simple manual switch with the load being a small 24 v 3 A supply for my starlink.

I already control a small relay via home assistant, but want to replace it with something that works with and without HA.

 

[gregoryx]

Simple manual switch with the load being a small 24 v 3 A supply for my starlink.

I already control a small relay via home assistant, but want to replace it with something that works with and without HA.

My go-to would be a Shelly - using a momentary push-button with a lighted indicator. It'd take just a couple minutes to replace your small relay, then wire in the switch so it works without any automation with whatever lighted switch you prefer.

I like these buttons - in whatever color ring you prefer.

But I've also got these buttons that I did my own indicators on:

 

[larry barello]

Ok, I finally figured out that the shelly 1 is the module to use. Can also be flashed with ESPHome if I prefer. Thanks for the pointer to the illuminated buttons. I might have to get a handful of the shellys and rewire my power control system. Automation + local control. Whoohoo.

Any idea of 12v (nominal) current draw? Will they run in 24v mode off of an LPF battery?

 

[Irontent]

The Shelly’s typically draw in the neighborhood of 10-20 ma. Most of the ones capable of running on DC power will run on 24v. I’m running several RGBW2 on 12v (but they will also work on 24v) and a Shelly Plus 1 UL on 12v as well. You can use the Plus one on 12v, 24-48V, or 120/240VAC.

 

[larry barello]

The RGBW also looks attractive. Four SSR + switch inputs. Does cost 50% more... but allows for expansion using a single unit.

 

[gregoryx]

The RGBW also looks attractive. Four SSR + switch inputs. Does cost 50% more... but allows for expansion using a single unit.

I had trouble using the RGBW-PM for our Starlink - didn't act on/off like a relay; but I did wire it in on the ground leg to gather power monitoring. Others have reported it working well. The downside to the Shelly-1 is no power monitoring - even if you get one of the PM units, it only works on AC power, not DC.

If you're looking to do more relay-based stuff, I'd move away from Shelly to ESP32 based - you can get a 4-relay board for $10-20 or so on Amazon or Aliexpress. You can get a 6-channel or 8-channel from Kincony or Waveshare for ~$40 or something like that.

I want power monitoring as well, though... and not much combines both well. So I separated the two - using a Kincony board/box for 16 channels of DC power monitoring.

If you want something clean / attractive AND decent support, either Kincony or Waveshare work. They'll both be running ESPHome once up and going - meaning you can programmatically do whatever you want that they don't by default. And they both have exposed pins that you can do whatever ELSE you want to with them. So... in our case, I used some pins in the Waveshare to drive the indicator lights and others to drive the switches.

For dimming lights, I still prefer the Shelly RGBW-PM. For individual loads without power monitoring, the Shelly-1 or -2 - assuming it's more power than the RGBW-PM will handle OR the RGBW-PM doesn't work quite right.


Something to look into for Shelly if you consider flashing ESPHome: I don't think you can flash back.