Exposing some unused ESP32 Pins so the SBMS can be expanded further

[Charles Gomes]

Dacian,

Not sure if anybody else mentioned this before, but I think It would be awesome to get access to some of the ESP32 PINs that are not in use.  They could be wired to temperature sensors, Can Bus, or I2C that would bring a whole lot of extra functionality.

The ESP32 is so powerful that it could run so many other things.

Yes the user will need to be responsible for the software changes but the software is the easy part.

Thank you,

Your opinion would be much appreciated.

[Dacian Todea]

Charles,

The ESP32 has no control over anything on the SBMS0 it is there just for the WiFi access.  The main SBMS0 software is ruining on the STM32F373 and from that you have access to I2C and UART both of them properly isolated so you do not risk damaging the SBMS0.

ESP32 is powerful in therms of hardware but the hardware is closed source and so is most of the firmware thus you can not properly take advantage of that hardware thus the reason I never wrote any software for the ESP32. First I used the provided AT-Firmware that has plenty of bugs and now on the last SBMS0 version is ruining an option made by Robert that is done using platform-IO probably using arduino platform so still not something that you can properly control.

The STM32F373 has all the hardware documentation provided and since I wrote all the software (nothing hidden or closed source) I can trust that will do exactly what I expect and while in theory way weaker than ESP32  just a single cortex M4 core running at 40MHz vs 2x 240MHz cores on the ESP32.

The STM32F373 is doing so much more than ESP32 can hope to do with his theoretical 12x or more powerful hardware.   The STM32F373 is doing all the work on the SBMS0 meaning handling the capacitive buttons,  the 320x240 LCD multiple 16bit ADC's the communication with ISL94203 over I2C communication with ESP32 converting all data in to human readable format and storing the data in to external SPI flash plus creating the graphs (more limited by the 32KB of RAM)

Since this is a safety critical device ESP32 has no control over SBMS0 thus you adding a say temperature sensor to the ESP32 will not be able to do anything. The ESP32 has access to the I2C port but currently it is not used for anything other than used by the STM32F373 in older models of SBMS40/SBMS120 to communicate with the DMPPT450.

The reason to have the I2C connected to ESP32 was that in future I may be able to interrogate the ESP32 and provide some data to the STM32F373 but ESP32 will need to be slave on this I2C and maybe it can spy on this if it want to read some data but should not intervene as master.

Also ESP32 is powered by the internal 3.3V DC-DC converter that powers everything in the SBMS0 so if you want to connect anything to any of the ESP32 pins then there will need to be some sort of isolation not to damage the ESP32 and possibly much more. The UART (also available as USB to UART) and the I2C available on the WiFi/USB module are properly isolated by the MAX14851

[Charles Gomes]

Thank you very much for the in depth explanation. I've not installed mine yet but once I've more time I will read more on the STM32F373 and the I2C integration with the ESP32. Perhaps could use the ESP32 to publish data on Can Bus so Victron devices could pickup.

[Dacian Todea]

It will not be useful to use Can as all Victron devices have remote ON/OFF port that will integrate with the EXT IOx on the SBMS and thus truly turning them off protecting the battery. If the EXT IOx wires get broken devices will default to safe OFF. 

[GLASHINC Developments]

I have a use case that using a pin from the ESP32 would be helpful with.

Essentially I want to perform "AC diversion".  

My current settings are:

- Cell Type 1 (LFP)

- End of Charge 3.53V

- Over Voltage 3.55V

- Max SOC 90%

How this would work is that when the SBMS0 reaches EOC and sets the SOC to 100% I want to turn on an optional AC load that would be fed from the inverter.  When the SOC falls to 87% I would turn that optional AC load off.  With a properly sized AC load the system would be able to use a lot of the PV energy that would otherwise not be available while the regular AC loads pull the SOC from 100% down to 86%.  In my installation that is about 2 hours of sunlight energy because the system is reaching 100% SOC on many days by about 1:30 pm.

I can see how to implement this easily in the ESP32 as it has all of the information necessary in the "sbms" variable that is parsed to create the MQTT output.

I note the safety concerns that Dacian has about the isolation or lack thereof of the ESP32.  Is there a way to achieve this without risking damage to the SMBS0 hardware?

[Dacian Todea]

In any properly designed system the battery will be full at around noon and there will be a lot of unused solar energy in most days.

No matter what you do you can not get rid of that.

What will that AC load be ? Probably some sort of water heater and that is no different from a thermal battery and so also have a limited storage capacity.

What SBMS version do you have ?  There are EXT IOx pins that are isolated and controlled by the micro-controller.  You can set those as type 4 and set a limit of say 87% that means EXT IOx will be close circuit when SOC above 87% and open circuit when below with a 3% hysteresis.

There is the risk that battery will never get to full charge if AC load is more than PV array produces.  That is why there is the DSSR20 with diversion for such applications where excess PV energy can directly be used for heating water or space heating.

No other application other than heating is suitable for something like this as you can not start your oven or TV :) it will make no sense to use those unless you need them.

[GLASHINC Developments]

I am using a SMBS0 with HW version 0.3d and SW version 5.0d with the WiFi module

The load would be a water pump to lift water to a tank. Technically, however, with creative use of a small automatic transfer switch and a small UPS it could be any AC load that has a somewhat constant current draw profile, including a TV :)

Using EXT IOx as type 4 does not achieve the same thing.  As you indicate there is the risk that the battery will never get to full charge.  I know that it is important for calibration of SOC that this is done periodically (daily if possible).

I currently use :

• EXTIO3 - Type 2
• EXTIO4 - Type 1   
• EXTIO6 - Type 5
• Over Voltage Delay - 6s

In the future I might want to use EXTIO5 as Type 6 and so I don't want to tie it up using it as Type 4 anyway.

With the solution that I am proposing the diversion AC load will be activated only after the battery gets to full charge (EOC & OV flags set for 3s) but before charging sources are turned off (OV flag is set for 6s).  As far as I am seeing it I should have a 3s window to turn on the diversion AC load and thus be able to slow the rate of charging of the cells such that no cell causes the OV flag to be set for 6s thus leaving the charging sources enabled while 100% SOC has been achieved.

If I am understanding the code correctly this is the section that sets the SOC to 100%:

  if (EF[13]==1 && EF[0]==1){EOC++;} else {EOC=0;if (EOC2!=0){EOC2--;}} //see if end of charge flag is ON and also OverVoltage for more than 3 seconds in order to set the SOC at 100%

  if (EOC>=3) {EOC=3;}

  if (EOC==3 && EOC2==0){BatterySOC=BattCapacity*2;dmpptnewday=0;sbms0newday=0;EOC2=3;} //End of Charge will reset the SOC to 100%

And this is the section that turns off charging for EXTIO4 - Type 1:

if (CFET==0){CFETerror++;}

else {CFETerror=0;}

.

.

.

if (ERROR5==0){ERROR55++;}

else {ERROR55=0;}

if (CFETerror>=3){CFETerror=3;}

if (DFETerror>=3){DFETerror=3;}

if (ERROR55>=3){ERROR55=3;DFETerror=3;CFETerror=3;}

.

.

.

if (EXT[2]==1){if (CFETerror<=1 && sbms0charge>0 && (sbms0dualPV==1||sbms0dualPV==3))    {EXT4_ON;}           else {EXT4_OFF;}}

   

Given that there is no more EXTIO available on the SMBS0 can you assist with advice on how I can safely use the ESP32 to drive an external isolation board to achieve the desired outcome.

[Dacian Todea]

That 3 second idea is not good as it can be triggered just by cell balancing that is active for 3 seconds.  Is best to wait until OverVoltage flag is set as SOC is reset to 100% so charging is stopped then you can enable a Load

You can use any sort of isolation you want probably an optoisolator exactly the way it is used on the EXT IOx where the Toshiba TLP172GM is used and a 390Ohm resistor.

So connect the unused IO pin from the ESP32 to a 390Ohm pin then connect that to TLP172GM pin 1 and pin 2 will connect to GND.  Then pin's 3 and 4 are for you to use as you want as that will be an isolated switch capable of max 50mA

[Troy Gordon]

There are 12 and 24 volt DC pumps available.  Would it be an option to connect one to the diversion from a DSSR?  You gain the simplicity of only having the pump and drop the price and additional complexity of a second inverter.  

[GLASHINC Developments]

Hi Troy,

Pump is 3HP (~2240W). That cannot be powered from a DSSR.  

My solution would leverage the existing inverter, no additional inverter required.