Potential ESP32 comms interface

[Can]

Hi StealthChesnut

Reaching out on here regarding this post on your HA repo https://github.com/StealthChesnut/HA-Fo ... nt-4818239

Would you be interested in a collaborative project to develop a custom interface? There appears to be quite a few V2 issues that can be tweaked with minimal effort, with the right team I think there’s an opportunity to create something quite interesting. Protocols are already known and tested here for V1, I have a few installation running with 36 and 50kW packs using a custom BMS master. What’s missing is details of the cell level data reported by the new V2 setup.

My own projects are bare metal Rust which isn’t community friendly. However, I’ve recently helped another FoxESS user setup a dual can gateway using ESPhome which uses C++ in lambda functions via YAML configs. Not my area but it does address the community aspect.

Goals:

Powered by inverter (EPS friendly)
Modbus TCP (wifi) to RTU interface
Cell level data in HA via modbus
Customisation of charge/discharge rates vs temps
Artificial max SoC upper and lower limits
Manual override of force charging, enable/disable/passthru/time window

Thoughts?

[StealthChesnut]

It sounds very interesting as a project, but I do have some reservations about folding it into the HA-modbus integration.

There's a good few people struggle with the modbus integration as it is, and if they tinkered around with things they might inadvertently mess something up. I would expect the bar-to-entry for battery control would be made sufficiently high with the hardware build requirements, but even so it might benefit being a separate integration.

I would like to contribute if I can, time is a pressing factor for me however (hence why my integration hasn't moved much recently!).

Have you so far worked with wholly v1 or v2 battery stacks, or have you looked at mixed stacks?

[Can]

Appols for the late reply, didn't enable notifications!

As I see it, the operation of such a device would be transparent as the primary goal would be to map the RTU registers to TCP. Configuring the HA integration would be a matter of setting it up as per the TCP template. There may be one or two discrepancies though if some TCP registers are missing on RTU.

For additional features, I think a separate add-on would suffice. I'm assuming that HA supports non-persistent TCP, this would permit add ons to block rather than have async calls. Not sure whether ESPHome supports multiple connections as yet, I will ask.

Regarding BMS V1 & V2, I haven't looked at the stacks per-se just replicated the function of the BMS master using V1 as a template. There's been little interest in analysing the slaves as that function is already being performed by automotive grade devices on our setups. We have a few H1s and ACs running with EV batteries, full cell level monitoring etc etc.with a gateway device acting as BMS master.

As an aside, if users want help with their V2 devices I will be able to help, just need some reliable can bus logs first. None of our kit shipped with any V2 ancillaries so we have nothing to go on.

I've asked the ESPHome guy to join us here.

Update: Dual can proof of concept is now in full time operation on a H1. Working fine

[fox123]

Hello,

Sorry for the delay in posting.

It's me who has a working setup of both Modbus RS485 and CanBus using ESPHome on ESP32 (Lilygo CAN485) and ESP8266 for the FOXESS.

Happy to share my yaml code if you think it would be useful? Can share a repo and then we can decide the best approach but I agree it might be going a bit beyond the original project you have on github.

My setup is actually sending custom BMS data from a HV EV battery to the FOX over Can but if we had some FOX BMS v2 Can telemetry recorded then could basically the same code to read the cell level data etc and publish to HA as a supplement to the Modbus data.

I also found much more data hidden in other Modbus address ranges just not had time to reverse engineer them all yet.

Has anyone figured out how to change the work mode or forced charging via Modbus/CAN yet?

Cheers
Chris

[fox123]

OK I tidied up my code for the ESPHome Modbus setup and here is a starter for 10:

https://github.com/mypi-home/HA-ESPHome ... ter-Modbus

[usus]

Hello,

Sorry for the delay in posting.

It's me who has a working setup of both Modbus RS485 and CanBus using ESPHome on ESP32 (Lilygo CAN485) and ESP8266 for the FOXESS.

Happy to share my yaml code if you think it would be useful? Can share a repo and then we can decide the best approach but I agree it might be going a bit beyond the original project you have on github.

My setup is actually sending custom BMS data from a HV EV battery to the FOX over Can but if we had some FOX BMS v2 Can telemetry recorded then could basically the same code to read the cell level data etc and publish to HA as a supplement to the Modbus data.

I also found much more data hidden in other Modbus address ranges just not had time to reverse engineer them all yet.

Has anyone figured out how to change the work mode or forced charging via Modbus/CAN yet?

Cheers
Chris

Hi Chris,

I would like to see the code.
I you may write me on private. I just register.

BR,
usus

[Alextrical]

Also very interested in this, It would be nice to get a Wemos D1 Mini running the communication with an off the shelf MAX485 breakout board as shown in the GitRepo.
I will give that a try tomorrow, this project is my first dip into the world of RS485 But I'm happy to report back any issues or possibly try to submit improvements

[v1lad]

Hi !
I have very simple integration based on ESP8266 :
https://github.com/mypi-home/HA-ESPHome ... ter-Modbus
I have to change just script from H1 to H3. It is working fine. The device is placed in a DIN rail case. After debugging I will install it to the Electrical Control Panel.