SolarConvert

Hi @Gerrie and everyone else.
I am not an electrician so forgive the possible silly question, but would a changeover switch make sense to use with the aux load feature?
So for position A of the changeover switch, the geyser/stove/non-essentials are before the inverter, therefore are not connected to the aux port of the inverter. Excess PV can still be used to reduce the costs of the non-essentials. However, in this position, if grid goes out, the inverter cannot power the non-essentials. The advantage though is that the non-essential loads to not count towards the inverter load limit (for example, 5kW on the 5kW inverter).
For position B of the changeover switch, the non-essentials are then transferred to the aux port of the inverter. Excess PV can still be used to decrease the costs of the non-essentials. However, in this position, when there is no grid, the non-essentials can still run under "favourable conditions" aka inverter aux settings, but the non-essentials now count towards the inverter load limit (eg 5kW) so one must be extra careful to not overload the inverter.
Position B would be used during load shedding / major outages and one would need to watch the inverter usage closely. Position A would be used at all other times.
What do you think of the above?

Hi all, I thought I would document my findings of the Tian Power BMS protocol used in my Narada 48NPFC100 battery whilst I was attempting to establish why it did not work with my Deye inverter. Of note is that the exact same battery model is known to use a Shinwa BMS as well, but mine uses a Tian Power one, specifically TP-ND1530.
Firstly I wanted to thank @shanghailoz for documenting the same thing here for the Revov batteries, which also use a Tian Power BMS, without which I would have struggled a lot more. Also thank you @zivva for pointing me in the right direction for the BMS manufacturer.
I also peeked at the code of the BMS software to decipher how certain fields are calculated.
The protocol follows.
 
Preamble
Firstly, all data sent appears to have a header, body and CRC check. For example:
7e 01 01 00 fe 0d The first byte is either 7c or 7e according to the software. In my case it is always 7e.
The second byte is the DIP switch setting on the battery and corresponds to the following in the software:

The third byte is the function code, which you will see several examples of below, such as "read data", "read BMS time", "read BMS version", "read serial number".
The fourth byte is the length of the payload supplied as part of the function call - most "read" type functions will not include a payload and this parameter will be 00, but the "write" functions would have a payload. If there is a payload, it would follow this byte.
The last two bytes are the CRC check.
The response is structured in a similar way:
7e 01 01 56 ... f2 0d The first three bytes are an echo of what the request was, the fourth byte indicates the response length followed by the response bytes, and finally we have the CRC check.
 
Function 1 - Read data
7e 01 01 00 fe 0d This allows you to read almost everything that is displayed on the first tab of the BMS software.
The response will look as follows:
7e 01 01 56 01 0f 0c e1 0c e2 0c e2 0c e3 0c e3 0c e5 0c e5 0c e4 0c e4 0c e4 0c e2 0c e2 0c e2 0c e3 0c e5 02 01 75 30 03 01 16 74 04 01 27 10 05 06 00 44 00 45 00 45 00 44 40 46 20 45 06 05 00 00 00 00 00 00 00 00 00 00 07 01 00 81 08 01 13 54 09 01 27 10 0a 01 00 00 f2 0d The response body for this function is a data map structured as follows: data entry index, number of high/low byte pairs, the high/low byte pairs.
Data 1 - Cell count and cell voltages
01 0f 0c e1 0c e2 0c e2 0c e3 0c e3 0c e5 0c e5 0c e4 0c e4 0c e4 0c e2 0c e2 0c e2 0c e3 0c e5 The second byte is the number of cells - this is 15 for a 15 cell battery like mine or 16 cells for Revov. The individual cell voltages follow as high/low pairs which need to be divided by 1000, for example, 0ce1 maps to 3297 which means 3.297V. Since my battery has 15 cells, there would be 15 individual cell voltages.
Data 2 - Current
02 01 75 30 This is a tricky one. 7530 hex maps to 30000 decimal. The BMS software works it out as:
current_in_amps = (30000 - value_of_item_2) / 100 This item therefore has an offset of 30000 and a scaling factor of 0.01. So when the charge current is 0, the BMS will return 30000, therefore (30000 - 30000) / 100 = 0 amps. When the charge current is 10 amps, the BMS would return 29000, therefore (30000 - 29000) / 100 = 10 amps. When the charge current is -10 amps, the BMS would return 31000, therefore (30000 - 31000) / 100 = -10 amps. Furthermore, charge/discharge time remaining is calculated based on max battery capacity in amps divided by current in amps.
Data 3 - Remaining capacity
03 01 16 74 This value needs to be divided by 100 to get Ah. In this case I have 1674 hex or 5748 decimal, so 57.48Ah left of my 100Ah battery, therefore the SOC is 57.48%.
Data 4 - Full capacity
04 01 27 10 Divide by 100 to get full battery capacity in Ah. 2710 in hex is 10000 in decimal, so I have a 100Ah battery.
Data 5 - Temperatures
05 06 00 44 00 45 00 45 00 44 40 46 20 45 In my case there are 6 temperatures corresponding to the following screenshot:

In the Revovs the number of temperatures listed are different. The last two appear to be important ones.
Each temperature value is calculated as:
temp_value = (bms_temp_value & 0xFF) - 50 Data 6 - Alarm bits
06 05 00 00 00 00 00 00 00 00 00 00 These can be mapped to (a) very specific alarm code(s). I can get these if there is interest.
Data 7 - Cycles
07 01 00 81 This represents the number of cycles of the battery, so 129 in my case.
Data 8 - Voltage
08 01 13 54 The total voltage of the battery. The number needs to be divided by 100, so 49.48V in my case.
Data 9 - State of Health
09 01 27 10 The SOH of the battery. Needs to be divided by 100, so 100% in my case.
Data 10 - ALM bytes
0a 01 00 00 This corresponds to the ALM light on the battery and what it means.
 
Function 67 - Read protection parameters
Request:
7e 01 43 00 fe 0d Response:
7e 01 43 94 00 02 0e 10 01 02 03 e8 02 02 0d ac 03 02 0a f0 04 02 03 e8 05 02 0c 1c 06 02 15 4a 07 02 03 e8 08 02 14 c8 09 02 11 94 0a 02 03 e8 0b 02 13 88 0c 02 1f 40 0d 02 03 e8 0e 02 1b 58 0f 02 1f 40 10 02 03 e8 11 02 1b 58 12 02 00 69 13 02 0f a0 14 02 00 5f 15 02 00 32 16 02 0f a0 17 02 00 3c 18 02 00 69 19 02 0f a0 1a 02 00 5f 1b 02 00 32 1c 02 0f a0 1d 02 00 3c 1e 02 00 8c 1f 02 0f a0 20 02 00 87 21 02 00 0a 22 02 00 0f 23 02 03 20 24 02 01 f4 de 0d This is another data map which ultimately gets translated into the following, with the necessary scaling factors applied:
{ "cell_ov_start": 3.6, "cell_ov_delay": 1000, "cell_ov_stop": 3.5, "cell_uv_start": 2.8, "cell_uv_delay": 1000, "cell_uv_stop": 3.1, "pack_ov_start": 54.5, "pack_ov_delay": 1000, "pack_ov_stop": 53.2, "pack_uv_start": 45.0, "pack_uv_delay": 1000, "pack_uv_stop": 50.0, "charge_oc_start": 80.0, "charge_oc_delay": 1000, "charge_oc_stop": 70.0, "discharge_oc_start": 80.0, "discharge_oc_delay": 1000, "discharge_oc_stop": 70.0, "cell_ot_start": 55, "cell_ot_delay": 4000, "cell_ot_stop": 45, "cell_ut_start": 0, "cell_ut_delay": 4000, "cell_ut_stop": 10, "env_ot_start": 55, "env_ot_delay": 4000, "env_ot_stop": 45, "env_ut_start": 0, "env_ut_delay": 4000, "env_ut_stop": 10, "mos_ot_start": 90, "mos_ot_delay": 4000, "mos_ot_stop": 85, "capacity_low_start": 10, "capacity_low_stop": 15, "volt_diff_start": 800, "volt_diff_stop": 500 }  
Function 51 - Read BMS version
The request is as follows:
7e 01 33 00 fe 0d The response body is a string, such as:
7e 01 33 18 54 50 2d 4e 44 31 35 33 30 2d 31 35 53 31 30 30 41 2d 56 31 2e 30 2e 30 2e 0d Which in my case maps to: TP-ND1530-15S100A-V1.0.0
 
Function 66 - Read PCB barcode
Request:
7e 01 42 00 fc 0d Response body is a string as above.
 
Function 220 - Read serial number
Request:
7e 01 dc 03 06 00 00 c2 0d Response body is a string as above.
 
Function 69 - Read BMS time
Request:
7e 01 45 00 fe 0d Response:
7e 01 45 06 16 07 08 14 3b 16 48 0d To convert the above to a valid date time, prepend "20" and then concatenate the rest of the bytes which represent yy, MM, dd, hh, mm, ss, so in the above example: 2022-07-08 20:59:22.
 
There are many "write"-type functions too but I would be wary of using those.
I hope the above is useful to someone. I will post more useful ones if I find any.

Hi all, I thought I would document my findings of the Tian Power BMS protocol used in my Narada 48NPFC100 battery whilst I was attempting to establish why it did not work with my Deye inverter. Of note is that the exact same battery model is known to use a Shinwa BMS as well, but mine uses a Tian Power one, specifically TP-ND1530.
Firstly I wanted to thank @shanghailoz for documenting the same thing here for the Revov batteries, which also use a Tian Power BMS, without which I would have struggled a lot more. Also thank you @zivva for pointing me in the right direction for the BMS manufacturer.
I also peeked at the code of the BMS software to decipher how certain fields are calculated.
The protocol follows.
 
Preamble
Firstly, all data sent appears to have a header, body and CRC check. For example:
7e 01 01 00 fe 0d The first byte is either 7c or 7e according to the software. In my case it is always 7e.
The second byte is the DIP switch setting on the battery and corresponds to the following in the software:

The third byte is the function code, which you will see several examples of below, such as "read data", "read BMS time", "read BMS version", "read serial number".
The fourth byte is the length of the payload supplied as part of the function call - most "read" type functions will not include a payload and this parameter will be 00, but the "write" functions would have a payload. If there is a payload, it would follow this byte.
The last two bytes are the CRC check.
The response is structured in a similar way:
7e 01 01 56 ... f2 0d The first three bytes are an echo of what the request was, the fourth byte indicates the response length followed by the response bytes, and finally we have the CRC check.
 
Function 1 - Read data
7e 01 01 00 fe 0d This allows you to read almost everything that is displayed on the first tab of the BMS software.
The response will look as follows:
7e 01 01 56 01 0f 0c e1 0c e2 0c e2 0c e3 0c e3 0c e5 0c e5 0c e4 0c e4 0c e4 0c e2 0c e2 0c e2 0c e3 0c e5 02 01 75 30 03 01 16 74 04 01 27 10 05 06 00 44 00 45 00 45 00 44 40 46 20 45 06 05 00 00 00 00 00 00 00 00 00 00 07 01 00 81 08 01 13 54 09 01 27 10 0a 01 00 00 f2 0d The response body for this function is a data map structured as follows: data entry index, number of high/low byte pairs, the high/low byte pairs.
Data 1 - Cell count and cell voltages
01 0f 0c e1 0c e2 0c e2 0c e3 0c e3 0c e5 0c e5 0c e4 0c e4 0c e4 0c e2 0c e2 0c e2 0c e3 0c e5 The second byte is the number of cells - this is 15 for a 15 cell battery like mine or 16 cells for Revov. The individual cell voltages follow as high/low pairs which need to be divided by 1000, for example, 0ce1 maps to 3297 which means 3.297V. Since my battery has 15 cells, there would be 15 individual cell voltages.
Data 2 - Current
02 01 75 30 This is a tricky one. 7530 hex maps to 30000 decimal. The BMS software works it out as:
current_in_amps = (30000 - value_of_item_2) / 100 This item therefore has an offset of 30000 and a scaling factor of 0.01. So when the charge current is 0, the BMS will return 30000, therefore (30000 - 30000) / 100 = 0 amps. When the charge current is 10 amps, the BMS would return 29000, therefore (30000 - 29000) / 100 = 10 amps. When the charge current is -10 amps, the BMS would return 31000, therefore (30000 - 31000) / 100 = -10 amps. Furthermore, charge/discharge time remaining is calculated based on max battery capacity in amps divided by current in amps.
Data 3 - Remaining capacity
03 01 16 74 This value needs to be divided by 100 to get Ah. In this case I have 1674 hex or 5748 decimal, so 57.48Ah left of my 100Ah battery, therefore the SOC is 57.48%.
Data 4 - Full capacity
04 01 27 10 Divide by 100 to get full battery capacity in Ah. 2710 in hex is 10000 in decimal, so I have a 100Ah battery.
Data 5 - Temperatures
05 06 00 44 00 45 00 45 00 44 40 46 20 45 In my case there are 6 temperatures corresponding to the following screenshot:

In the Revovs the number of temperatures listed are different. The last two appear to be important ones.
Each temperature value is calculated as:
temp_value = (bms_temp_value & 0xFF) - 50 Data 6 - Alarm bits
06 05 00 00 00 00 00 00 00 00 00 00 These can be mapped to (a) very specific alarm code(s). I can get these if there is interest.
Data 7 - Cycles
07 01 00 81 This represents the number of cycles of the battery, so 129 in my case.
Data 8 - Voltage
08 01 13 54 The total voltage of the battery. The number needs to be divided by 100, so 49.48V in my case.
Data 9 - State of Health
09 01 27 10 The SOH of the battery. Needs to be divided by 100, so 100% in my case.
Data 10 - ALM bytes
0a 01 00 00 This corresponds to the ALM light on the battery and what it means.
 
Function 67 - Read protection parameters
Request:
7e 01 43 00 fe 0d Response:
7e 01 43 94 00 02 0e 10 01 02 03 e8 02 02 0d ac 03 02 0a f0 04 02 03 e8 05 02 0c 1c 06 02 15 4a 07 02 03 e8 08 02 14 c8 09 02 11 94 0a 02 03 e8 0b 02 13 88 0c 02 1f 40 0d 02 03 e8 0e 02 1b 58 0f 02 1f 40 10 02 03 e8 11 02 1b 58 12 02 00 69 13 02 0f a0 14 02 00 5f 15 02 00 32 16 02 0f a0 17 02 00 3c 18 02 00 69 19 02 0f a0 1a 02 00 5f 1b 02 00 32 1c 02 0f a0 1d 02 00 3c 1e 02 00 8c 1f 02 0f a0 20 02 00 87 21 02 00 0a 22 02 00 0f 23 02 03 20 24 02 01 f4 de 0d This is another data map which ultimately gets translated into the following, with the necessary scaling factors applied:
{ "cell_ov_start": 3.6, "cell_ov_delay": 1000, "cell_ov_stop": 3.5, "cell_uv_start": 2.8, "cell_uv_delay": 1000, "cell_uv_stop": 3.1, "pack_ov_start": 54.5, "pack_ov_delay": 1000, "pack_ov_stop": 53.2, "pack_uv_start": 45.0, "pack_uv_delay": 1000, "pack_uv_stop": 50.0, "charge_oc_start": 80.0, "charge_oc_delay": 1000, "charge_oc_stop": 70.0, "discharge_oc_start": 80.0, "discharge_oc_delay": 1000, "discharge_oc_stop": 70.0, "cell_ot_start": 55, "cell_ot_delay": 4000, "cell_ot_stop": 45, "cell_ut_start": 0, "cell_ut_delay": 4000, "cell_ut_stop": 10, "env_ot_start": 55, "env_ot_delay": 4000, "env_ot_stop": 45, "env_ut_start": 0, "env_ut_delay": 4000, "env_ut_stop": 10, "mos_ot_start": 90, "mos_ot_delay": 4000, "mos_ot_stop": 85, "capacity_low_start": 10, "capacity_low_stop": 15, "volt_diff_start": 800, "volt_diff_stop": 500 }  
Function 51 - Read BMS version
The request is as follows:
7e 01 33 00 fe 0d The response body is a string, such as:
7e 01 33 18 54 50 2d 4e 44 31 35 33 30 2d 31 35 53 31 30 30 41 2d 56 31 2e 30 2e 30 2e 0d Which in my case maps to: TP-ND1530-15S100A-V1.0.0
 
Function 66 - Read PCB barcode
Request:
7e 01 42 00 fc 0d Response body is a string as above.
 
Function 220 - Read serial number
Request:
7e 01 dc 03 06 00 00 c2 0d Response body is a string as above.
 
Function 69 - Read BMS time
Request:
7e 01 45 00 fe 0d Response:
7e 01 45 06 16 07 08 14 3b 16 48 0d To convert the above to a valid date time, prepend "20" and then concatenate the rest of the bytes which represent yy, MM, dd, hh, mm, ss, so in the above example: 2022-07-08 20:59:22.
 
There are many "write"-type functions too but I would be wary of using those.
I hope the above is useful to someone. I will post more useful ones if I find any.

I went ahead and did this two months ago:
Hooked up stove and oven (they didn’t have separate circuit breakers) to the aux port of my Deye, behind a changeover switch. So when there is no load shedding, the stove and oven are non-essentials, but if there is load shedding the changeover switch is flipped and they become aux loads and they can work from solar + battery.
What a massive difference. This has enhanced the relationship with the wife.

I have one of those locally manufactured Opensprinkler boards available for sale if you are looking for one (not Zigbee). I bought two a long time ago and the second ended up never getting used. PM me if interested.
Edit: It was sold.

Try this software instead for LM-M01A.

Hi all, I thought I would document my findings of the Tian Power BMS protocol used in my Narada 48NPFC100 battery whilst I was attempting to establish why it did not work with my Deye inverter. Of note is that the exact same battery model is known to use a Shinwa BMS as well, but mine uses a Tian Power one, specifically TP-ND1530.
Firstly I wanted to thank @shanghailoz for documenting the same thing here for the Revov batteries, which also use a Tian Power BMS, without which I would have struggled a lot more. Also thank you @zivva for pointing me in the right direction for the BMS manufacturer.
I also peeked at the code of the BMS software to decipher how certain fields are calculated.
The protocol follows.
 
Preamble
Firstly, all data sent appears to have a header, body and CRC check. For example:
7e 01 01 00 fe 0d The first byte is either 7c or 7e according to the software. In my case it is always 7e.
The second byte is the DIP switch setting on the battery and corresponds to the following in the software:

The third byte is the function code, which you will see several examples of below, such as "read data", "read BMS time", "read BMS version", "read serial number".
The fourth byte is the length of the payload supplied as part of the function call - most "read" type functions will not include a payload and this parameter will be 00, but the "write" functions would have a payload. If there is a payload, it would follow this byte.
The last two bytes are the CRC check.
The response is structured in a similar way:
7e 01 01 56 ... f2 0d The first three bytes are an echo of what the request was, the fourth byte indicates the response length followed by the response bytes, and finally we have the CRC check.
 
Function 1 - Read data
7e 01 01 00 fe 0d This allows you to read almost everything that is displayed on the first tab of the BMS software.
The response will look as follows:
7e 01 01 56 01 0f 0c e1 0c e2 0c e2 0c e3 0c e3 0c e5 0c e5 0c e4 0c e4 0c e4 0c e2 0c e2 0c e2 0c e3 0c e5 02 01 75 30 03 01 16 74 04 01 27 10 05 06 00 44 00 45 00 45 00 44 40 46 20 45 06 05 00 00 00 00 00 00 00 00 00 00 07 01 00 81 08 01 13 54 09 01 27 10 0a 01 00 00 f2 0d The response body for this function is a data map structured as follows: data entry index, number of high/low byte pairs, the high/low byte pairs.
Data 1 - Cell count and cell voltages
01 0f 0c e1 0c e2 0c e2 0c e3 0c e3 0c e5 0c e5 0c e4 0c e4 0c e4 0c e2 0c e2 0c e2 0c e3 0c e5 The second byte is the number of cells - this is 15 for a 15 cell battery like mine or 16 cells for Revov. The individual cell voltages follow as high/low pairs which need to be divided by 1000, for example, 0ce1 maps to 3297 which means 3.297V. Since my battery has 15 cells, there would be 15 individual cell voltages.
Data 2 - Current
02 01 75 30 This is a tricky one. 7530 hex maps to 30000 decimal. The BMS software works it out as:
current_in_amps = (30000 - value_of_item_2) / 100 This item therefore has an offset of 30000 and a scaling factor of 0.01. So when the charge current is 0, the BMS will return 30000, therefore (30000 - 30000) / 100 = 0 amps. When the charge current is 10 amps, the BMS would return 29000, therefore (30000 - 29000) / 100 = 10 amps. When the charge current is -10 amps, the BMS would return 31000, therefore (30000 - 31000) / 100 = -10 amps. Furthermore, charge/discharge time remaining is calculated based on max battery capacity in amps divided by current in amps.
Data 3 - Remaining capacity
03 01 16 74 This value needs to be divided by 100 to get Ah. In this case I have 1674 hex or 5748 decimal, so 57.48Ah left of my 100Ah battery, therefore the SOC is 57.48%.
Data 4 - Full capacity
04 01 27 10 Divide by 100 to get full battery capacity in Ah. 2710 in hex is 10000 in decimal, so I have a 100Ah battery.
Data 5 - Temperatures
05 06 00 44 00 45 00 45 00 44 40 46 20 45 In my case there are 6 temperatures corresponding to the following screenshot:

In the Revovs the number of temperatures listed are different. The last two appear to be important ones.
Each temperature value is calculated as:
temp_value = (bms_temp_value & 0xFF) - 50 Data 6 - Alarm bits
06 05 00 00 00 00 00 00 00 00 00 00 These can be mapped to (a) very specific alarm code(s). I can get these if there is interest.
Data 7 - Cycles
07 01 00 81 This represents the number of cycles of the battery, so 129 in my case.
Data 8 - Voltage
08 01 13 54 The total voltage of the battery. The number needs to be divided by 100, so 49.48V in my case.
Data 9 - State of Health
09 01 27 10 The SOH of the battery. Needs to be divided by 100, so 100% in my case.
Data 10 - ALM bytes
0a 01 00 00 This corresponds to the ALM light on the battery and what it means.
 
Function 67 - Read protection parameters
Request:
7e 01 43 00 fe 0d Response:
7e 01 43 94 00 02 0e 10 01 02 03 e8 02 02 0d ac 03 02 0a f0 04 02 03 e8 05 02 0c 1c 06 02 15 4a 07 02 03 e8 08 02 14 c8 09 02 11 94 0a 02 03 e8 0b 02 13 88 0c 02 1f 40 0d 02 03 e8 0e 02 1b 58 0f 02 1f 40 10 02 03 e8 11 02 1b 58 12 02 00 69 13 02 0f a0 14 02 00 5f 15 02 00 32 16 02 0f a0 17 02 00 3c 18 02 00 69 19 02 0f a0 1a 02 00 5f 1b 02 00 32 1c 02 0f a0 1d 02 00 3c 1e 02 00 8c 1f 02 0f a0 20 02 00 87 21 02 00 0a 22 02 00 0f 23 02 03 20 24 02 01 f4 de 0d This is another data map which ultimately gets translated into the following, with the necessary scaling factors applied:
{ "cell_ov_start": 3.6, "cell_ov_delay": 1000, "cell_ov_stop": 3.5, "cell_uv_start": 2.8, "cell_uv_delay": 1000, "cell_uv_stop": 3.1, "pack_ov_start": 54.5, "pack_ov_delay": 1000, "pack_ov_stop": 53.2, "pack_uv_start": 45.0, "pack_uv_delay": 1000, "pack_uv_stop": 50.0, "charge_oc_start": 80.0, "charge_oc_delay": 1000, "charge_oc_stop": 70.0, "discharge_oc_start": 80.0, "discharge_oc_delay": 1000, "discharge_oc_stop": 70.0, "cell_ot_start": 55, "cell_ot_delay": 4000, "cell_ot_stop": 45, "cell_ut_start": 0, "cell_ut_delay": 4000, "cell_ut_stop": 10, "env_ot_start": 55, "env_ot_delay": 4000, "env_ot_stop": 45, "env_ut_start": 0, "env_ut_delay": 4000, "env_ut_stop": 10, "mos_ot_start": 90, "mos_ot_delay": 4000, "mos_ot_stop": 85, "capacity_low_start": 10, "capacity_low_stop": 15, "volt_diff_start": 800, "volt_diff_stop": 500 }  
Function 51 - Read BMS version
The request is as follows:
7e 01 33 00 fe 0d The response body is a string, such as:
7e 01 33 18 54 50 2d 4e 44 31 35 33 30 2d 31 35 53 31 30 30 41 2d 56 31 2e 30 2e 30 2e 0d Which in my case maps to: TP-ND1530-15S100A-V1.0.0
 
Function 66 - Read PCB barcode
Request:
7e 01 42 00 fc 0d Response body is a string as above.
 
Function 220 - Read serial number
Request:
7e 01 dc 03 06 00 00 c2 0d Response body is a string as above.
 
Function 69 - Read BMS time
Request:
7e 01 45 00 fe 0d Response:
7e 01 45 06 16 07 08 14 3b 16 48 0d To convert the above to a valid date time, prepend "20" and then concatenate the rest of the bytes which represent yy, MM, dd, hh, mm, ss, so in the above example: 2022-07-08 20:59:22.
 
There are many "write"-type functions too but I would be wary of using those.
I hope the above is useful to someone. I will post more useful ones if I find any.

I certainly needed it - but then I have a DIY 2nd life pack. After about 3.5V/cell the imbalance grew quickly until cell protection kicked in and opened the BMS while still under charge, which resulted in quite a voltage spike on the output.
So I added derating to decrease charge current and voltage when any one cell starts approaching full, and this solved the issue.
After a few months, the cells balanced nicely, and it might not even be needed anymore, but I feel it is a healthy bit of paranoia to keep.

So I didn't make much progress in the meantime, but let me post some more detail as promised.
Firstly, the Tian Power output that I was trying to understand:
7e01439400020e10010203e802020dac03020af0040203e805020c1c0602154a070203e8080214c8090211940a0203e80b0213880c021f400d0203e80e021b580f021f40100203e811021b581202006913020fa01402005f1502003216020fa01702003c1802006919020fa01a02005f1b0200321c020fa01d02003c1e02008c1f020fa0200200872102000a2202000f23020320240201f4de0d Means the following:
{ "cell_ov_start": 3.6, "cell_ov_delay": 1000, "cell_ov_stop": 3.5, "cell_uv_start": 2.8, "cell_uv_delay": 1000, "cell_uv_stop": 3.1, "pack_ov_start": 54.5, "pack_ov_delay": 1000, "pack_ov_stop": 53.2, "pack_uv_start": 45.0, "pack_uv_delay": 1000, "pack_uv_stop": 50.0, "charge_oc_start": 80.0, "charge_oc_delay": 1000, "charge_oc_stop": 70.0, "discharge_oc_start": 80.0, "discharge_oc_delay": 1000, "discharge_oc_stop": 70.0, "cell_ot_start": 55, "cell_ot_delay": 4000, "cell_ot_stop": 45, "cell_ut_start": 0, "cell_ut_delay": 4000, "cell_ut_stop": 10, "env_ot_start": 55, "env_ot_delay": 4000, "env_ot_stop": 45, "env_ut_start": 0, "env_ut_delay": 4000, "env_ut_stop": 10, "mos_ot_start": 90, "mos_ot_delay": 4000, "mos_ot_stop": 85, "capacity_low_start": 10, "capacity_low_stop": 15, "volt_diff_start": 800, "volt_diff_stop": 500 } These are the protection parameters that the BMS returns for command 7e 01 43 00 fe 0d.
This allowed me to get the charge and discharge current limits (80A for both) as well as the charge and discharge voltages from the BMS and send them to the inverter. I compared all of the values to my attempt of using Lithium mode 7 a few months back and the results were very similar. Here is a photo from a few months back:

If you recall, Lithium mode 7, which is meant for Revov batteries, didn't work for me at the time because not all of the values interpreted from the BMS by the inverter were correct, for example, the mean temp was wrong and I almost immediately got an error condition on the inverter, likely because it interpreted the alarm bits incorrectly. Nevertheless, the above photo at least gave me a point of comparison and I felt more comfortable with the charging/discharging voltages and currents that i am sending to the inverter now via the CAN port. Here is what the screen looks like with my current script running on my PI which queries the BMS via the battery RS485 port and sends the results to the CAN port of the inverter.

The script has been running well, I made it start automatically when the PI is rebooted. For me, this is a much needed upgrade since I never had BMS comms working before.
However, I cannot figure out in what format I should send the PACK information to the inverter, so you will see above that the Sum Data and Details Data buttons are missing, because the inverter does not know about the individual batteries, just the battery "system" as a whole. This is not a problem for me since I only have one battery anyway, but for those that would like to use this script, you would lose the ability to see the details of the individual battery packs, unless there is some way I can send the pack info to the inverter too. I cannot find any documentation or examples online where pack info is sent on the CAN bus.
 
This is very interesting and I actually didn't know what the derating file was for, but now that you explained it, it makes a lot of sense. I ran my script without any derating functionality and the inverter appeared to do the right thing as per the graph below - note that at the time I took the screenshot I had not even implemented any alarm bits either.

The charge current did decrease as soon as the voltage went past 54.5V. I am actually thinking of using pack_ov_stop instead of pack_ov_start for the voltage limit because pack_ov_start means that 54.5V is already "over voltage" so using the lower value (53.2V) should prevent the pack_ov_start value from being reached. As an aside, if you're wondering why the spike to 100% SOC just before 12:00 and then back down - it is because I switched the inverter from Lithium mode 0 back to Battery % mode (so no more BMS comms via the PI) and the inverter thought that the battery SOC was 100%, then I quickly switched back to Lithium mode.
That being said, do you think derating is needed? On the one hand I think that the derating feature is great since it does a similar thing as the expensive + intelligent BMSes, but on the other hand, does one actually need to worry about derating whether using RS485 or CAN for BMS comms?
 
I am happy to take a stab at getting the Shinwa protocol to work, I'd probably send you a script to test out on the PI to see if the output values make sense. However, please note above that i cannot get the pack information to work at this stage, so you would lose the ability to monitor individual batteries. That may be a deal breaker for you.
Regarding the CAN bus module, I use this the Waveshare RS485 CAN HAT which does both RS486 and CAN, plus it connects directly to the ports, no need for USB. There are many other options for CAN interfaces though, for example on this page.
I am going to keep searching for how to get pack information to the inverter via CAN. Surely it must have been done before. I cannot imagine that if you use the CAN port directly on the inverter with a supported BMS that you cannot monitor the individual batteries irrespective of the BMS manufacturer?

Ok progress made on this. I now know what each of the numbered items mean above and I know the meaning of the alarm bits on the BMS side. What is left to do is to map the BMS alarm bits to CAN 0x359, as well as to get pack info to the inverter - currently the inverter does not allow me to go into the details of each individual battery (even though I have just one), so it's just the summary screen that is available as per my previous screenshot (though the values are now all real values from the BMS).
Will post more info tonight.

Ok progress made on this. I now know what each of the numbered items mean above and I know the meaning of the alarm bits on the BMS side. What is left to do is to map the BMS alarm bits to CAN 0x359, as well as to get pack info to the inverter - currently the inverter does not allow me to go into the details of each individual battery (even though I have just one), so it's just the summary screen that is available as per my previous screenshot (though the values are now all real values from the BMS).
Will post more info tonight.

Thanks for the link @JustinSchoeman.
I managed to get CAN IDs 0x351, 0x355 and 0x356, but 0x359 is the tricky one which I don't find examples of, especially when the alarm/warning bits are set.
By far the best set of docs for the CAN IDs I have found is the SMA CAN protocol one SMA CAN protocol.pdf, but I attach the Sunsynk Sunsynk Battery Compatibility v4.pdf and Pylontech CAN-Bus-protocol-PYLON-low-voltage-V1.2-20180408.pdf docs too.
Whilst 0x351, 0x355 and 0x356 are a huge upgrade for me since I never had BMS comms, I do think that 0x359 is very important because the inverter must know about any fault conditions of the battery. Those who already had proper BMS comms working via RS485 and choose to go with this RS485/CAN translation route (like @Jay-Dee ) should get no less than what they had before when there was direct BMS comms between the inverter and the battery.
Pages 3 of the Pylon CAN protocol doc is what I'm going to tackle next.
The hard part for me is figuring out the Tian Power BMS protocol and mapping it to CAN ID 0x359, including the alarm / warning bits, as well as cherry picking the correct values from an unknown dictionary of data. For example, the following response from my BMS contains a lot of useful information, but deciphering it is hard:
7e01439400020e10010203e802020dac03020af0040203e805020c1c0602154a070203e8080214c8090211940a0203e80b0213880c021f400d0203e80e021b580f021f40100203e811021b581202006913020fa01402005f1502003216020fa01702003c1802006919020fa01a02005f1b0200321c020fa01d02003c1e02008c1f020fa0200200872102000a2202000f23020320240201f4de0d Here it is translated:
{0: (3600,), 1: (1000,), 2: (3500,), 3: (2800,), 4: (1000,), 5: (3100,), 6: (5450,), 7: (1000,), 8: (5320,), 9: (4500,), 10: (1000,), 11: (5000,), 12: (8000,), 13: (1000,), 14: (7000,), 15: (8000,), 16: (1000,), 17: (7000,), 18: (105,), 19: (4000,), 20: (95,), 21: (50,), 22: (4000,), 23: (60,), 24: (105,), 25: (4000,), 26: (95,), 27: (50,), 28: (4000,), 29: (60,), 30: (140,), 31: (4000,), 32: (135,), 33: (10,), 34: (15,), 35: (800,), 36: (500,)} I assume item 6 is charge voltage (54.5V), which plugs into CAN ID 0x351, but I'm not quite sure which one is max charge and discharge current, so I have them hard-coded for now.
 
I don't see why not. If the Shinwa BMS software works for you, it should be fairly easy to get the required protocol. But it will take some time to get this stable enough for you to be able to run it and forget that it's running. I also think that if SolarAssistant supports this down the line, it would be better to use that since it is a supported product, but until they have this feature, an interim solution would work.

Wow this is really great @Jay-Dee! Mission accomplished. I may just try to do the very same thing. Can you share the pins used for the data logger cable?
Yes this is exactly what I wanted to attempt when I mentioned it a few posts back. This week I actually removed the SolarAssistant SD card from my PI and am back to my general purpose one. I created a very rudimentary Python script which can read the BMS parameters via RS485, so that works. Now for the hard part…to get the PI to act like a BMS when connected to the inverter CAN port and translate any inverter requests to the real BMS.

Just a note for anyone who finds there way here and has a similar problem with the Narada and the older (5KW) Axperts. The error I was getting was the BMS going into short circuit protection. This is most likely due to the instantaneous current draw when switching powers source if the capacitors discharge slightly. So .. running a single Narada is a bit hit and miss it seems .. probably going to order a second one to get it going properly

Hi all, I thought I would document my findings of the Tian Power BMS protocol used in my Narada 48NPFC100 battery whilst I was attempting to establish why it did not work with my Deye inverter. Of note is that the exact same battery model is known to use a Shinwa BMS as well, but mine uses a Tian Power one, specifically TP-ND1530.
Firstly I wanted to thank @shanghailoz for documenting the same thing here for the Revov batteries, which also use a Tian Power BMS, without which I would have struggled a lot more. Also thank you @zivva for pointing me in the right direction for the BMS manufacturer.
I also peeked at the code of the BMS software to decipher how certain fields are calculated.
The protocol follows.
 
Preamble
Firstly, all data sent appears to have a header, body and CRC check. For example:
7e 01 01 00 fe 0d The first byte is either 7c or 7e according to the software. In my case it is always 7e.
The second byte is the DIP switch setting on the battery and corresponds to the following in the software:

The third byte is the function code, which you will see several examples of below, such as "read data", "read BMS time", "read BMS version", "read serial number".
The fourth byte is the length of the payload supplied as part of the function call - most "read" type functions will not include a payload and this parameter will be 00, but the "write" functions would have a payload. If there is a payload, it would follow this byte.
The last two bytes are the CRC check.
The response is structured in a similar way:
7e 01 01 56 ... f2 0d The first three bytes are an echo of what the request was, the fourth byte indicates the response length followed by the response bytes, and finally we have the CRC check.
 
Function 1 - Read data
7e 01 01 00 fe 0d This allows you to read almost everything that is displayed on the first tab of the BMS software.
The response will look as follows:
7e 01 01 56 01 0f 0c e1 0c e2 0c e2 0c e3 0c e3 0c e5 0c e5 0c e4 0c e4 0c e4 0c e2 0c e2 0c e2 0c e3 0c e5 02 01 75 30 03 01 16 74 04 01 27 10 05 06 00 44 00 45 00 45 00 44 40 46 20 45 06 05 00 00 00 00 00 00 00 00 00 00 07 01 00 81 08 01 13 54 09 01 27 10 0a 01 00 00 f2 0d The response body for this function is a data map structured as follows: data entry index, number of high/low byte pairs, the high/low byte pairs.
Data 1 - Cell count and cell voltages
01 0f 0c e1 0c e2 0c e2 0c e3 0c e3 0c e5 0c e5 0c e4 0c e4 0c e4 0c e2 0c e2 0c e2 0c e3 0c e5 The second byte is the number of cells - this is 15 for a 15 cell battery like mine or 16 cells for Revov. The individual cell voltages follow as high/low pairs which need to be divided by 1000, for example, 0ce1 maps to 3297 which means 3.297V. Since my battery has 15 cells, there would be 15 individual cell voltages.
Data 2 - Current
02 01 75 30 This is a tricky one. 7530 hex maps to 30000 decimal. The BMS software works it out as:
current_in_amps = (30000 - value_of_item_2) / 100 This item therefore has an offset of 30000 and a scaling factor of 0.01. So when the charge current is 0, the BMS will return 30000, therefore (30000 - 30000) / 100 = 0 amps. When the charge current is 10 amps, the BMS would return 29000, therefore (30000 - 29000) / 100 = 10 amps. When the charge current is -10 amps, the BMS would return 31000, therefore (30000 - 31000) / 100 = -10 amps. Furthermore, charge/discharge time remaining is calculated based on max battery capacity in amps divided by current in amps.
Data 3 - Remaining capacity
03 01 16 74 This value needs to be divided by 100 to get Ah. In this case I have 1674 hex or 5748 decimal, so 57.48Ah left of my 100Ah battery, therefore the SOC is 57.48%.
Data 4 - Full capacity
04 01 27 10 Divide by 100 to get full battery capacity in Ah. 2710 in hex is 10000 in decimal, so I have a 100Ah battery.
Data 5 - Temperatures
05 06 00 44 00 45 00 45 00 44 40 46 20 45 In my case there are 6 temperatures corresponding to the following screenshot:

In the Revovs the number of temperatures listed are different. The last two appear to be important ones.
Each temperature value is calculated as:
temp_value = (bms_temp_value & 0xFF) - 50 Data 6 - Alarm bits
06 05 00 00 00 00 00 00 00 00 00 00 These can be mapped to (a) very specific alarm code(s). I can get these if there is interest.
Data 7 - Cycles
07 01 00 81 This represents the number of cycles of the battery, so 129 in my case.
Data 8 - Voltage
08 01 13 54 The total voltage of the battery. The number needs to be divided by 100, so 49.48V in my case.
Data 9 - State of Health
09 01 27 10 The SOH of the battery. Needs to be divided by 100, so 100% in my case.
Data 10 - ALM bytes
0a 01 00 00 This corresponds to the ALM light on the battery and what it means.
 
Function 67 - Read protection parameters
Request:
7e 01 43 00 fe 0d Response:
7e 01 43 94 00 02 0e 10 01 02 03 e8 02 02 0d ac 03 02 0a f0 04 02 03 e8 05 02 0c 1c 06 02 15 4a 07 02 03 e8 08 02 14 c8 09 02 11 94 0a 02 03 e8 0b 02 13 88 0c 02 1f 40 0d 02 03 e8 0e 02 1b 58 0f 02 1f 40 10 02 03 e8 11 02 1b 58 12 02 00 69 13 02 0f a0 14 02 00 5f 15 02 00 32 16 02 0f a0 17 02 00 3c 18 02 00 69 19 02 0f a0 1a 02 00 5f 1b 02 00 32 1c 02 0f a0 1d 02 00 3c 1e 02 00 8c 1f 02 0f a0 20 02 00 87 21 02 00 0a 22 02 00 0f 23 02 03 20 24 02 01 f4 de 0d This is another data map which ultimately gets translated into the following, with the necessary scaling factors applied:
{ "cell_ov_start": 3.6, "cell_ov_delay": 1000, "cell_ov_stop": 3.5, "cell_uv_start": 2.8, "cell_uv_delay": 1000, "cell_uv_stop": 3.1, "pack_ov_start": 54.5, "pack_ov_delay": 1000, "pack_ov_stop": 53.2, "pack_uv_start": 45.0, "pack_uv_delay": 1000, "pack_uv_stop": 50.0, "charge_oc_start": 80.0, "charge_oc_delay": 1000, "charge_oc_stop": 70.0, "discharge_oc_start": 80.0, "discharge_oc_delay": 1000, "discharge_oc_stop": 70.0, "cell_ot_start": 55, "cell_ot_delay": 4000, "cell_ot_stop": 45, "cell_ut_start": 0, "cell_ut_delay": 4000, "cell_ut_stop": 10, "env_ot_start": 55, "env_ot_delay": 4000, "env_ot_stop": 45, "env_ut_start": 0, "env_ut_delay": 4000, "env_ut_stop": 10, "mos_ot_start": 90, "mos_ot_delay": 4000, "mos_ot_stop": 85, "capacity_low_start": 10, "capacity_low_stop": 15, "volt_diff_start": 800, "volt_diff_stop": 500 }  
Function 51 - Read BMS version
The request is as follows:
7e 01 33 00 fe 0d The response body is a string, such as:
7e 01 33 18 54 50 2d 4e 44 31 35 33 30 2d 31 35 53 31 30 30 41 2d 56 31 2e 30 2e 30 2e 0d Which in my case maps to: TP-ND1530-15S100A-V1.0.0
 
Function 66 - Read PCB barcode
Request:
7e 01 42 00 fc 0d Response body is a string as above.
 
Function 220 - Read serial number
Request:
7e 01 dc 03 06 00 00 c2 0d Response body is a string as above.
 
Function 69 - Read BMS time
Request:
7e 01 45 00 fe 0d Response:
7e 01 45 06 16 07 08 14 3b 16 48 0d To convert the above to a valid date time, prepend "20" and then concatenate the rest of the bytes which represent yy, MM, dd, hh, mm, ss, so in the above example: 2022-07-08 20:59:22.
 
There are many "write"-type functions too but I would be wary of using those.
I hope the above is useful to someone. I will post more useful ones if I find any.

Hi all, I thought I would document my findings of the Tian Power BMS protocol used in my Narada 48NPFC100 battery whilst I was attempting to establish why it did not work with my Deye inverter. Of note is that the exact same battery model is known to use a Shinwa BMS as well, but mine uses a Tian Power one, specifically TP-ND1530.
Firstly I wanted to thank @shanghailoz for documenting the same thing here for the Revov batteries, which also use a Tian Power BMS, without which I would have struggled a lot more. Also thank you @zivva for pointing me in the right direction for the BMS manufacturer.
I also peeked at the code of the BMS software to decipher how certain fields are calculated.
The protocol follows.
 
Preamble
Firstly, all data sent appears to have a header, body and CRC check. For example:
7e 01 01 00 fe 0d The first byte is either 7c or 7e according to the software. In my case it is always 7e.
The second byte is the DIP switch setting on the battery and corresponds to the following in the software:

The third byte is the function code, which you will see several examples of below, such as "read data", "read BMS time", "read BMS version", "read serial number".
The fourth byte is the length of the payload supplied as part of the function call - most "read" type functions will not include a payload and this parameter will be 00, but the "write" functions would have a payload. If there is a payload, it would follow this byte.
The last two bytes are the CRC check.
The response is structured in a similar way:
7e 01 01 56 ... f2 0d The first three bytes are an echo of what the request was, the fourth byte indicates the response length followed by the response bytes, and finally we have the CRC check.
 
Function 1 - Read data
7e 01 01 00 fe 0d This allows you to read almost everything that is displayed on the first tab of the BMS software.
The response will look as follows:
7e 01 01 56 01 0f 0c e1 0c e2 0c e2 0c e3 0c e3 0c e5 0c e5 0c e4 0c e4 0c e4 0c e2 0c e2 0c e2 0c e3 0c e5 02 01 75 30 03 01 16 74 04 01 27 10 05 06 00 44 00 45 00 45 00 44 40 46 20 45 06 05 00 00 00 00 00 00 00 00 00 00 07 01 00 81 08 01 13 54 09 01 27 10 0a 01 00 00 f2 0d The response body for this function is a data map structured as follows: data entry index, number of high/low byte pairs, the high/low byte pairs.
Data 1 - Cell count and cell voltages
01 0f 0c e1 0c e2 0c e2 0c e3 0c e3 0c e5 0c e5 0c e4 0c e4 0c e4 0c e2 0c e2 0c e2 0c e3 0c e5 The second byte is the number of cells - this is 15 for a 15 cell battery like mine or 16 cells for Revov. The individual cell voltages follow as high/low pairs which need to be divided by 1000, for example, 0ce1 maps to 3297 which means 3.297V. Since my battery has 15 cells, there would be 15 individual cell voltages.
Data 2 - Current
02 01 75 30 This is a tricky one. 7530 hex maps to 30000 decimal. The BMS software works it out as:
current_in_amps = (30000 - value_of_item_2) / 100 This item therefore has an offset of 30000 and a scaling factor of 0.01. So when the charge current is 0, the BMS will return 30000, therefore (30000 - 30000) / 100 = 0 amps. When the charge current is 10 amps, the BMS would return 29000, therefore (30000 - 29000) / 100 = 10 amps. When the charge current is -10 amps, the BMS would return 31000, therefore (30000 - 31000) / 100 = -10 amps. Furthermore, charge/discharge time remaining is calculated based on max battery capacity in amps divided by current in amps.
Data 3 - Remaining capacity
03 01 16 74 This value needs to be divided by 100 to get Ah. In this case I have 1674 hex or 5748 decimal, so 57.48Ah left of my 100Ah battery, therefore the SOC is 57.48%.
Data 4 - Full capacity
04 01 27 10 Divide by 100 to get full battery capacity in Ah. 2710 in hex is 10000 in decimal, so I have a 100Ah battery.
Data 5 - Temperatures
05 06 00 44 00 45 00 45 00 44 40 46 20 45 In my case there are 6 temperatures corresponding to the following screenshot:

In the Revovs the number of temperatures listed are different. The last two appear to be important ones.
Each temperature value is calculated as:
temp_value = (bms_temp_value & 0xFF) - 50 Data 6 - Alarm bits
06 05 00 00 00 00 00 00 00 00 00 00 These can be mapped to (a) very specific alarm code(s). I can get these if there is interest.
Data 7 - Cycles
07 01 00 81 This represents the number of cycles of the battery, so 129 in my case.
Data 8 - Voltage
08 01 13 54 The total voltage of the battery. The number needs to be divided by 100, so 49.48V in my case.
Data 9 - State of Health
09 01 27 10 The SOH of the battery. Needs to be divided by 100, so 100% in my case.
Data 10 - ALM bytes
0a 01 00 00 This corresponds to the ALM light on the battery and what it means.
 
Function 67 - Read protection parameters
Request:
7e 01 43 00 fe 0d Response:
7e 01 43 94 00 02 0e 10 01 02 03 e8 02 02 0d ac 03 02 0a f0 04 02 03 e8 05 02 0c 1c 06 02 15 4a 07 02 03 e8 08 02 14 c8 09 02 11 94 0a 02 03 e8 0b 02 13 88 0c 02 1f 40 0d 02 03 e8 0e 02 1b 58 0f 02 1f 40 10 02 03 e8 11 02 1b 58 12 02 00 69 13 02 0f a0 14 02 00 5f 15 02 00 32 16 02 0f a0 17 02 00 3c 18 02 00 69 19 02 0f a0 1a 02 00 5f 1b 02 00 32 1c 02 0f a0 1d 02 00 3c 1e 02 00 8c 1f 02 0f a0 20 02 00 87 21 02 00 0a 22 02 00 0f 23 02 03 20 24 02 01 f4 de 0d This is another data map which ultimately gets translated into the following, with the necessary scaling factors applied:
{ "cell_ov_start": 3.6, "cell_ov_delay": 1000, "cell_ov_stop": 3.5, "cell_uv_start": 2.8, "cell_uv_delay": 1000, "cell_uv_stop": 3.1, "pack_ov_start": 54.5, "pack_ov_delay": 1000, "pack_ov_stop": 53.2, "pack_uv_start": 45.0, "pack_uv_delay": 1000, "pack_uv_stop": 50.0, "charge_oc_start": 80.0, "charge_oc_delay": 1000, "charge_oc_stop": 70.0, "discharge_oc_start": 80.0, "discharge_oc_delay": 1000, "discharge_oc_stop": 70.0, "cell_ot_start": 55, "cell_ot_delay": 4000, "cell_ot_stop": 45, "cell_ut_start": 0, "cell_ut_delay": 4000, "cell_ut_stop": 10, "env_ot_start": 55, "env_ot_delay": 4000, "env_ot_stop": 45, "env_ut_start": 0, "env_ut_delay": 4000, "env_ut_stop": 10, "mos_ot_start": 90, "mos_ot_delay": 4000, "mos_ot_stop": 85, "capacity_low_start": 10, "capacity_low_stop": 15, "volt_diff_start": 800, "volt_diff_stop": 500 }  
Function 51 - Read BMS version
The request is as follows:
7e 01 33 00 fe 0d The response body is a string, such as:
7e 01 33 18 54 50 2d 4e 44 31 35 33 30 2d 31 35 53 31 30 30 41 2d 56 31 2e 30 2e 30 2e 0d Which in my case maps to: TP-ND1530-15S100A-V1.0.0
 
Function 66 - Read PCB barcode
Request:
7e 01 42 00 fc 0d Response body is a string as above.
 
Function 220 - Read serial number
Request:
7e 01 dc 03 06 00 00 c2 0d Response body is a string as above.
 
Function 69 - Read BMS time
Request:
7e 01 45 00 fe 0d Response:
7e 01 45 06 16 07 08 14 3b 16 48 0d To convert the above to a valid date time, prepend "20" and then concatenate the rest of the bytes which represent yy, MM, dd, hh, mm, ss, so in the above example: 2022-07-08 20:59:22.
 
There are many "write"-type functions too but I would be wary of using those.
I hope the above is useful to someone. I will post more useful ones if I find any.

Ok I have done some more serial port sniffing. I should have done this long ago - I would have saved myself countless hours and wasted RJ45 cable crimps.
On the Deye inverter, if I set lithium mode to 16, it emits the following with a 1 second gap in between each line:
27 04 0f ff 00 09 04 2e 28 04 0f ff 00 09 04 d1 29 04 0f ff 00 09 05 00 2a 04 0f ff 00 09 05 33 2b 04 0f ff 00 09 04 e2 2c 04 0f ff 00 09 05 55 2d 04 0f ff 00 09 04 84 2e 04 0f ff 00 09 04 b7 2f 04 0f ff 00 09 05 66 30 04 0f ff 00 09 07 09 31 04 0f ff 00 09 06 d8 32 04 0f ff 00 09 06 eb 33 04 0f ff 00 09 07 3a 34 04 0f ff 00 09 06 8d And then this is repeated from the start. Knowing this now, I can see how the inverter would have never communicated with my Narada battery with a Tian Power BMS with lithium mode 16. I take it the above commands are Shinwa BMS ones, not Tian Power ones. The inverter appears to be scanning for a Shinwa BMS.
I still intend on creating the separate thread about my Narada with the Tian Power BMS, but suffice is to say, the BMS responds to the following totally different commands:
7e 01 01 00 fe 0d 7e 01 06 00 fc 0d 7e 01 33 00 fe 0d 7e 01 42 00 fc 0d 7e 01 45 00 fe 0d 7e 01 dc 03 06 00 00 c2 0d Now if I switch the inverter to lithium mode 9, the scanning commands more closely resemble the ones that my battery's BMS responds to:
7e 01 43 00 fe 0d 7e 32 32 30 32 34 41 34 32 45 30 30 32 30 31 46 44 32 37 0d 7e 02 43 00 fc 0d 7e 32 32 30 33 34 41 34 32 45 30 30 32 30 31 46 44 32 36 0d 7e 03 43 00 fa 0d 7e 32 32 30 34 34 41 34 32 45 30 30 32 30 31 46 44 32 35 0d 7e 04 43 00 fc 0d 7e 32 32 30 35 34 41 34 32 45 30 30 32 30 31 46 44 32 34 0d 7e 05 43 00 fe 0d 7e 32 32 30 36 34 41 34 32 45 30 30 32 30 31 46 44 32 33 0d 7e 06 43 00 fc 0d 7e 32 32 30 37 34 41 34 32 45 30 30 32 30 31 46 44 32 32 0d 7e 07 43 00 f2 0d 7e 32 32 30 38 34 41 34 32 45 30 30 32 30 31 46 44 32 31 0d 7e 08 43 00 fc 0d 7e 32 32 30 39 34 41 34 32 45 30 30 32 30 31 46 44 32 30 0d 7e 09 43 00 fe 0d 7e 32 32 31 30 34 41 34 32 45 30 30 32 30 31 46 44 32 38 0d 7e 0a 43 00 fc 0d 7e 32 32 31 31 34 41 34 32 45 30 30 32 30 31 46 44 32 37 0d 7e 0b 43 00 fa 0d 7e 32 32 31 32 34 41 34 32 45 30 30 32 30 31 46 44 32 36 0d 7e 0c 43 00 fc 0d 7e 32 32 31 33 34 41 34 32 45 30 30 32 30 31 46 44 32 35 0d 7e 0d 43 00 fe 0d 7e 32 32 31 34 34 41 34 32 45 30 30 32 30 31 46 44 32 34 0d 7e 0e 43 00 fc 0d 7e 32 32 31 35 34 41 34 32 45 30 30 32 30 31 46 44 32 33 0d 7e 0f 43 00 e2 0d 7e 32 32 30 31 34 41 34 32 45 30 30 32 30 31 46 44 32 38 0d The above repeat from the start until a battery is found.
I will go into more detail around what the Tian Power commands do once I have a solid understanding, but at least I can now prove that Deye/Sunsynk lithium mode 16 is not for Narada batteries with a Tian Power BMS. I don't know if I should be sad or happy at this point.

For me, I turned the inverter off on the switch at the bottom... Then dropped AC input, turn the PV and batteries off and within a few seconds that inverter turns off completely. Then turned it all back on.
I dont know if this is needed but from reading the thread before I got it working, it mentioned to reboot... So this is my reboot
 
I dont know if it is needed on the inverter too but definitely the batteries when changing the dip switches

I wish you all good luck. My Narada Red batteries have different ports  2 x RS-485 and 1 x LAN, no serial, and apparently uses a different baud rate to the white batteries, 9600 baud vs 14400 baud, I have been told. Then again, during this journey I have been told a lot of things! From my understanding the battery type sets the baud rate for the communication, so I am poked. I have managed to arrange a credit for my 3 x 7.2KWh Naradas, getting them replaced by 4 x 5.1 Shoto batteries on Wednesday, ones that work on CAN bus.
 
All the best and thanks so much for all the conversations and tips. It kept me busy for a while and I had a lot of fun in the process. For anyone that maybe interested, I have 1 of each of the suggested cable configs lying around now
 
What bothers me the most is that so called experts, supply combinations of equipment that do not work correctly. That is 1 aspect. The next is the configs of the "off the grid" systems. I have a 8KWh Deye, 24 x 455 Watt panels (the max that the 8KW Deye can take), and 22KWh of battery, and i cannot run a heater in winter. Also interesting, in summer I could generate 73KWh on a sunny day, at the moment that number has dropped to 34Kwh, so even if i added more batteries, i could not charge them in winter to cater for the longest nights.... and my house is optimised, LED globes, gas stove, inverter fridges, washing machine, heat pump tumble dryer. During the day my house idles at about 135 watts and at night when we go to bed about 350 watts (lots of LED lights around the house). Then of course using appliances and running the pool pump and stuff goes on top.
My household uses 800 KWh per month in total for everything.
This has been a most interesting exercise, and my personal perception of what it means to be "off the grid" has changed completely. I have learnt a lot!!!
All the best

Some of the experts said that with my Narada Red batteries, the baud rate for Rs485 is 9600,but with the white Naradas it is 14400, and this apparently matches type 16. Maybe there is hope for the non-red ones. Apparently the battery type on the Deye is a baud rate setting more than anything else..... Good luck. I hope it works out

Update. I had both cables discussed here made up and tried them both with my 8KW. No luck :(. I did have a mishap last weekend where my batteries went down to Zero SOC. On the Narada red batteries I have, there is a display. I then sat and recorded the % SOC and the voltage at every 10% change in SOC according to the batteries  and discovered that the voltages specified in the manuals appears to be very different to reality. Previously I set the Deye inverter Battery settings to Shutdown at 42V and Low battery at 44V as this was quite close to what I saw in the manuals I read. When my batteries went to 0% SOC, the moment that batteries started charging the panel on the batteries indicated 49.3V, so Zero SOC would be around 48.7 Volts, and not 44 as I though. I also compared and recorded the voltage on the inverter vs the voltage on the batteries. This was pretty close.
Another interesting aspect, throughout the charging cycle, the voltage difference at a specific % is 0.6V higher when charging compared to discharging. I chose to use the discharging voltage for settings, as I assumed that this would be what would trigger actions. This is the list of voltages I recorded and use now for my settings.
So batteries 0% is around 48.7 volts, and batteries full is 52.5, that is 3.2 volts difference, and then the 0.6V variance depending on charging or not changes the voltage by 19%
This is the table I now use to estimate levels when i do my settings, specifically on the time of use function. I use the Inverter reading for items that must happen while charging and the "settings on Deye) calculated values when i describe a low threshold.
 
  Batteries Charging Inverter Reading Setting on Deye 10% 49.30     20% 50.06 50.4 49.8 30% 50.33 50.6 50.0 40% 50.35 60.5 59.9 50% 50.50 50.8 50.2 60% 50.77 51.1 50.5 70% 50.86 51.2 50.6 80% 50.98 51.3 50.7 90% 51.30 51.6 51.0 100% 52.50 52.5 51.9 I also changed Battery settings on the inverter to:
Shutdown 48V
Batt low 49V
I suspect this may change, i am monitoring this closely during use. I also learnt that changing these parameters does not automatically update the Time of Use settings. Over the raining weekend I had my batteries drop to 18%, and then realised that my minimum voltage was still set to 42.5V. I have now shifted this to 49V. Will see where it goes now. I really enjoy being able to see my SOC and i suspect these values are used to calculate the SOC % from volts, so I am carefull to change them. I do not want to break someting that is working.
I am working slowly with these, as one of the benefits the panic brought is that the SOC on my Solarman app is now within 2% of what is indicated on the batteries themselves and this is amazing. Prior to this exercise, the app would say 93% and on the batteries I often found them to be 28 or 18%. Now for the 1st time I have some realistic indication. I really enjoy being able to see my SOC and i suspect these battery settings values are used by the app to calculate the SOC % from volts, so I am careful to change them. I do not want to break something that is working.
This was my main reason for wanting BMS.
I am going to give the BMS story one more shot, I am going to have a cable made up with pin 2 and 3 connected both sides but crossover, old RS232 type of cable, just for the hell of it and will let you know what happens.
If anyone has success with the BMS thing, please let me know!
This has been an interesting and very time consuming exercise, but it does feel like progress
Have an awesome day!

The original I got was 5.3MB so I had to run it through Adobe's site to compress it and fit within the 3MB upload limit on this forum. I don't see any difference between the original and the compressed version. It is attached to this post.
Please let me know if you figure out how to read values from the battery!
Note the following important bits:

I tried with Modbus slave 0, 1, 38 and 39 when my single Narada battery dip switch was set to 0 and 1, but still couldn't read data from the battery. This was a few months ago - I haven't tried again since then due to time constraints.
narada-bms-modbus-v16_compressed_high.pdf

@SolarConvert I added some details on [deployment options](https://github.com/kellerza/sunsynk#add-on-deployment)
@mauriciosti you probably got your setup working, but you can find details on pinouts that I used [here](https://github.com/kellerza/sunsynk#hardware)

Depending on how into home automation you are, you could use Home Assistant to send yourself a push notification to your (or several) phone(s).
Currently I have 2 ways to detect a grid outage - grid voltage drops to 0 on my inverter (the inverter is integrated into Home Assistant), or my CBI ASC for my geyser becomes unavailable (it is not connected to the inverter). I am sure there are other signals to detect a grid outage. Once the signal triggers an automation, you can pretty much do anything. Right now I just send myself a push notification to my phone, but could flash lights in the house, make a light a certain colour, play a sound on a smart speaker, or any combination of these.

You have a valid point that aux function can be set to preserve the battery when it reaches let’s call it the “lowest allowable SOC” 
In other words you could set Aux load to always be “on”. And it should only switch “off” when lowest allowable SOC is set for example to 40%. That last 40% is than strictly preserved for essential loads. 
The aux load has some merit if you can find the right use, it could possibly even be integrated into home automation or something where SOC and solar PV levels could come in handy.