January 29, 20233 yr Author Additionally I've incorporated an RTC and SD card. I use the EEPROM to record hourly and daily statistics and the SD card to record solar and system performance that can be shown on a graph via the system web interface.
January 30, 20233 yr 10 hours ago, BritishRacingGreen said: Attached is protocol. Thanks. I find that I already have this manual, and didn't realise that it's LIB protocol. Sigh.
January 30, 20233 yr On 2023/01/24 at 11:04 PM, Coulomb said: My guess (it's late and I'm waay behind on posts) is that the display isn't sending the command through to the DSP. I'm able to confirm that in display firmware version 122.15, this is the case. The display firmware doesn't send any PBATxxx commands through, apart from PBATMAXDISC.
January 30, 20233 yr On 2022/12/08 at 4:16 PM, Acuario said: Firmware that seems broken and does not work with Pylontech: U30000 U2:22 12 (the 2 dots are actually 4 in a vertical line..) It seems that there are dsp firmwares that respond to PBMS and those that don't. Main firmware version 81.05 does not respond to PBMS, yet display firmware 122.15 sends it. So that probably explains why that combination is broken for any BMS, including Pylontech. Edited January 30, 20233 yr by Coulomb
January 30, 20233 yr Author After running some tests today it seems the CAN data does not change the charge current limitation value when it approaches 100% SOC so it's not possible to use this as a way to regulate the charger on the inverter. It seems this is only available on the RS485 protocol. However, it seems the BMS automatically limits the charge when the battery approaches 100% - the readings from register 356 reduce down at the battery approaches 100% and finally drop and stay between 0A and 2.1A (no load on the inverter). This is good news as my concern was overcharging. I set the maximum voltage to 53.0V and it holds steady and charges to 100% at this voltage. The CAN data is useful as it can be used to set the charge limit of the inverter based on the BMS charge limit X number of batteries (both of which are on the CAN data). It also reports the real SOC, the inverter reports much lower as soon as the voltage drops from 53.0V Edited January 30, 20233 yr by Acuario
February 1, 20233 yr On 2023/01/29 at 6:23 PM, BritishRacingGreen said: Well done, You beat me to it😎 I am reffering to the Rpi PICO W. Its an embedded controller not unlike the ESP32, less hardware resources, but goes for 5 dollar. So my budget is about R120 rand for the pico and 180 rand for a carrier pcb with CAN PHY and RS485. EDIT: the pico lacks can controller, but a clever engineet from UK has implemented a PIO driven MAC layer and some soft bit banging, all within the pico, with an overhead of only 30% load on one of 2 Cortex cpu cores. This is what inspired me to go this route. The advantage of esp32 approach is that i guess it possible when you can connect diy-style batteries with Bluetooth bms to an inverter with LIB or some other proto emulation
March 16, 20233 yr On 2023/01/29 at 5:13 PM, Acuario said: It sounds roughly the same as what I have designed/developed. This is with an ESP32. The white sockets are for an LCD display and a touch switch. The user relay can be programmed to switch on/off depending on the SOC. I don't know how much 300 rands is - but according to the currency calculator it's just over 16 euros - I don't know the price of the raspberry pi but I thought they were more than that. I am working on something similar with use of ESP32-S3. It is in early development process, but it can get data from Seplos BMSes in slave mode. Right now I am trying to emulate "master" BMS against Axpert King set in "PYL" mode. The idea is that charge/discharge voltage/current limits will be reported to the inverter by my device, not by the Seplos BMS. My expectation is that if I manage to support Pylontech protocol (V3.3) the device will be compatible with more inverters. The are also CAN ports for future developments of CAN protocols. Basic specification of the device: Integrated 48VDC DC-DC converter (device is powered by battery pack voltage) 4x RS485/RS232 interfaces (connection of BMSes, inverters, smart meters or other BMS master devices) 2x CANBUS interface (connection with inverters) 8x digital input (e.g. control switches, storage system enclosure tamper switches, DC contactor state switches, etc.) 4x analog inputs (e.g. auxiliary thermistors) 4x 5V output (e.g. auxiliary LED indicators) 2x relay output (e.g. for generator control) 2x bi-stable relay output (for main DC contactors) 2x 48VDC FAN output with PWM speed control and RPM monitoring (forced cooling if required) Ethernet interface (connectivity to backend cloud services and IoT platforms) Wifi interface (connectivity to backend cloud services and IoT platforms) Bluetooth LE interface (future smartphone apps possible) miniPCIe slot (optional cellular modem -2G/4G, NB-IoT, LTE-M) 7” 800x480 touchscreen 10x RGB LEDs (SoC and alarm state indication) 2x backlit panel switches (START/STOP – emergency galvanic disconnect from the load using DC contactors) USB (type A connector) for connection of mass storage devices (long term logs, etc.) Edited March 16, 20233 yr by DaMar42
March 29, 20233 yr I using ESP32 with program in ESPhome for monitoring JBD BMS in Home Assistant and for a week ago I made connection to MAX 8k over CAN bus with protocol Soltaro (thank Coulomb and other users for information about this protocol). Function of connection is good, atfer some seconds flashing battery icon on inverter LCD and in information menu is new information about numbers of battery pack. One problem is with setting voltages because max charging voltage is setting for absorption voltage and for float voltage (boath is the same) in inverter. I was must made a small controling in ESP32 which change voltage from 55V after charge battery to 53,6V (and back tu 55V when battery is discharged) but this was not problem and all function verry well.
March 29, 20233 yr 33 minutes ago, PetrDubi said: battery icon on inverter LCD and in information menu is new information about numbers of battery pack What information is displayed for battery packs, can you provide an example image
March 29, 20233 yr On 2023/03/16 at 3:30 PM, DaMar42 said: I am working on something similar with use of ESP32-S3. It is in early development process, but it can get data from Seplos BMSes in slave mode. Right now I am trying to emulate "master" BMS against Axpert King set in "PYL" mode. The idea is that charge/discharge voltage/current limits will be reported to the inverter by my device, not by the Seplos BMS. My expectation is that if I manage to support Pylontech protocol (V3.3) the device will be compatible with more inverters. The are also CAN ports for future developments of CAN protocols. Basic specification of the device: Integrated 48VDC DC-DC converter (device is powered by battery pack voltage) 4x RS485/RS232 interfaces (connection of BMSes, inverters, smart meters or other BMS master devices) 2x CANBUS interface (connection with inverters) 8x digital input (e.g. control switches, storage system enclosure tamper switches, DC contactor state switches, etc.) 4x analog inputs (e.g. auxiliary thermistors) 4x 5V output (e.g. auxiliary LED indicators) 2x relay output (e.g. for generator control) 2x bi-stable relay output (for main DC contactors) 2x 48VDC FAN output with PWM speed control and RPM monitoring (forced cooling if required) Ethernet interface (connectivity to backend cloud services and IoT platforms) Wifi interface (connectivity to backend cloud services and IoT platforms) Bluetooth LE interface (future smartphone apps possible) miniPCIe slot (optional cellular modem -2G/4G, NB-IoT, LTE-M) 7” 800x480 touchscreen 10x RGB LEDs (SoC and alarm state indication) 2x backlit panel switches (START/STOP – emergency galvanic disconnect from the load using DC contactors) USB (type A connector) for connection of mass storage devices (long term logs, etc.) That FramesPerSecond indicator at the bottom right suggest that you using LVGL graphics library engine. Is it? Well done, very comptehensive. How did to manage 2 CAN channels. Using external CAN controller?
March 29, 20233 yr 46 minutes ago, PetrDubi said: I made connection to MAX 8k over CAN bus with protocol Soltaro (thank Coulomb Good to know someone implemented the Soltaro CAN as reverse engineered by @Coulomb
March 29, 20233 yr 3 hours ago, BritishRacingGreen said: That FramesPerSecond indicator at the bottom right suggest that you using LVGL graphics library engine. Is it? Well done, very comptehensive. How did to manage 2 CAN channels. Using external CAN controller? Yes, exactly, LVGL is used in the project. There are 2x MCP2515 CAN controllers used in the PCB design. ESP32-S3 actually does not have any CAN peripheral, only "old" ESP32 does. But that one does not have hardware support for parallel LCD connection.
March 29, 20233 yr 57 minutes ago, DaMar42 said: Yes, exactly, LVGL is used in the project. Great. I will always hold LVGL dear, that was keeping me busy during many hours and days of 2020 Lockdown. As a test, I ported it to an old ARM Atmel evaluation board dated 2004 just because I had the time 😁) . Its a very undetestimated baremetal windowing grafics framework, I see though its gained a lot of traction in 3D printing HMI, as well as industrial measurement products, amongst many other. Edited March 29, 20233 yr by BritishRacingGreen
March 30, 20233 yr On 2023/03/29 at 3:24 PM, BritishRacingGreen said: Good to know someone implemented the Soltaro CAN as reverse engineered by @Coulomb
April 29, 20233 yr Hello. I also managed to implement the SOLTARO protocol! I use JK-bms. I considered it important that the Axpert max II does not charge the battery to 100%. I added CAN communication to the syssi/esphome-jk-bms project and added the sending of messages to the inverter. Charge the battery for as long as I specified. Thanks for the great information on the forum. Thanks to Coulomb for a lot of work and information!
May 5, 20233 yr On 2023/04/29 at 8:41 PM, Rozsda said: Hello. I also managed to implement the SOLTARO protocol! I use JK-bms. I considered it important that the Axpert max II does not charge the battery to 100%. I added CAN communication to the syssi/esphome-jk-bms project and added the sending of messages to the inverter. Charge the battery for as long as I specified. Thanks for the great information on the forum. Thanks to Coulomb for a lot of work and information! Hello, @BritishRacingGreen, @Rozsda, @PetrDubi could you share your implementations? I'm also trying to implement something to connect JKBMS to Axpert, I tried with LIB. It works perfectly if I use pymodbus to ask values, but inverter doesn't ask for ModBus on BMS RS485 port (setting battery type to LIB). Attached my EspHome yaml file (values are for test only, if it works I will try to take data from BMS). The relevant part is under "modbus_server". Thanks modbus_server: - id: modbuserver uart_id: intmodbus address: 1 # slave address holding_registers: - start_address: 0x30 # 0x0030 | 2 | Module charge current | 0.1A | Summary data of all packs Sum of charge current, is 0 when discharging default: 100 # 10 A default value number: 1 on_read: | ESP_LOGI("ON_READ", "This is a lambda. address=0x%x, value=%d", address, value); return value; - start_address: 0x31 # 0x0031 | 2 | Module discharge current | 0.1A | Summary data of all packs Sum of discharge current, is 0 when charging default: 0 # 0 A default value number: 1 on_read: | ESP_LOGI("ON_READ", "This is a lambda. address=0x%x, value=%d", address, value); return value; - start_address: 0x32 # 0x0032 | 2 | Module voltage | 0.1V | Summary data of all packs Average voltage of all packs default: 48 # 48 V default value number: 1 on_read: | ESP_LOGI("ON_READ", "This is a lambda. address=0x%x, value=%d", address, value); return value; - start_address: 0x33 # 0x0033 | 2 | SOC | % default: 50 # 50% default value number: 1 # number of registers in the range on_read: | # called whenever a register in the range is read // 'address' contains the requested register address // 'value' contains the stored register value ESP_LOGI("ON_READ", "This is a lambda. address=0x%x, value=%d", address, value); return value; // you can return the stored value or something else. TODO: take values from BMS - start_address: 0x35 # 0x0034 | 4 | Module total capacity | mAH default: 0x45C0 # 280 Ah default value | 280000 = 0x4 0x45C0 = 4 17856 number: 1 on_read: | ESP_LOGI("ON_READ", "This is a lambda. address=0x%x, value=%d", address, value); return value; - start_address: 0x34 # 0x0034 | 4 | Module total capacity | mAH default: 0x4 # 280 Ah default value number: 1 on_read: | ESP_LOGI("ON_READ", "This is a lambda. address=0x%x, value=%d", address, value); return value; - start_address: 0x36 # 0x0036 | 2 | Pack parallel number | Number of online packs default: 16 # 16 default value number: 1 on_read: | ESP_LOGI("ON_READ", "This is a lambda. address=0x%x, value=%d", address, value); return value; - start_address: 0x70 # 0x0070 | 2 | Charge voltage limit | 0.1V default: 580 # 58.0V number: 1 on_read: | # ESP_LOGI("ON_READ", "This is a lambda. address=0x%x, value=%d", address, value); return value; - start_address: 0x71 # 0x0071 | 2 | Discharge voltage limit | 0.1V default: 480 # 48.0V number: 1 on_read: | ESP_LOGI("ON_READ", "This is a lambda. address=0x%x, value=%d", address, value); return value; - start_address: 0x72 # 0x0072 | 2 | Charge current limit | 0.1A default: 500 # 50.0A number: 1 on_read: | ESP_LOGI("ON_READ", "This is a lambda. address=0x%x, value=%d", address, value); return value; - start_address: 0x73 # 0x0073 | 2 | Discharge current limit | 0.1A default: 1000 # 100.0A number: 1 on_read: | ESP_LOGI("ON_READ", "This is a lambda. address=%x, value=%d", address, value); return value; - start_address: 0x74 # 0x0074 | 2 | Charge, discharge status # Bit: 7 | 1 | Charge enable | 1: yes 0: request stop charge # Bit: 6 | 1 | Discharge enable | 1: yes 0: request stop discharge # Bit: 5 | 1 | Charge immediately | 1: yes 0: no (SOC <= 9%) # Bit: 4 | 1 | Charge immediately2 | 1: yes 0: no (9<SOC<=14%) # Bit: 3 | 1 | Full charge request | 1: yes 0: no # Bit: 2 | 1 | Small current charge request | small current charge request, allways 0 # Bit: 1 | 1 | | # Bit: 0 | 1 | | default: 192 # 0xC0 1100 0000 number: 1 # number of registers in the range on_read: | # called whenever a register in the range is read ESP_LOGI("ON_READ", "This is a lambda. address=0x%x, value=%d", address, value); return value; // you can return the stored value or something else. jkbms-voltronic.yaml Edited May 5, 20233 yr by pongo
May 5, 20233 yr 57 minutes ago, pongo said: inverter doesn't ask for ModBus on BMS RS485 port (setting battery type to LIB Dont give up on LIB, it works well. Yes the inverter is master so it initiates the request. Under this circumstance there surely must be an issue on the physical link layer. Have you connected on pins 3 and 5 on the RJ45 on the axpert BMS port? Is A and B polarity correct? Is your baud rate correct.? You can always connect to RealTerm serial terminal app on win10 and view raw hex activity. It also helps if your RS485 dongle has an activity led, but of course its not a prerequisite. A terminating resistor is also not required, but it helps for longer cable lengths. Edited May 5, 20233 yr by BritishRacingGreen
May 5, 20233 yr 49 minutes ago, BritishRacingGreen said: Dont give up on LIB, it works well. Yes the inverter is master so it initiates the request. Under this circumstance there surely must be an issue on the physical link layer. Have you connected on pins 3 and 5 on the RJ45 on the axpert BMS port? Is A and B polarity correct? Is your baud rate correct.? You can always connect to RealTerm serial terminal app on win10 and view raw hex activity. It also helps if your RS485 dongle has an activity led, but of course its not a prerequisite. A terminating resistor is also not required, but it helps for longer cable lengths. @pongo I am more than willing to share my implementation, but I am using the Qt cpp library framework. So its not generic cpp ansi/iso libs. Having said that, I am more than willing to share some of the protocol handler files, you may find it usefull as a resource. If interested, I will share tommorrow. Edited May 5, 20233 yr by BritishRacingGreen
May 6, 20233 yr It needs to connect battery to see inverter asking modbus values. Now it works. These are registers my Axpert Max 7200 is asking: 01:03:00:01:00:02:95:CB 01:03:00:33:00:01:74:05 01:03:00:34:00:02:85:C5 01:03:00:70:00:01:85:D1 01:03:00:71:00:01:D4:11 01:03:00:72:00:01:24:11 01:03:00:73:00:01:75:D1 01:03:00:74:00:01:C4:10 01:03:02:00:32:39:91 01:03:02:00:C0:B8:14 01:03:02:01:E0:B8:5C 01:03:02:01:F4:B8:53 01:03:02:02:44:B9:17 01:03:02:03:E8:B8:FA 01:03:04:00:04:45:C0:89:32 Continuing testing and trying to send BMS values Thanks
May 8, 20233 yr I implemented dynamic data from BMS to ModBus github/gianfrdp/esphome_yaml/jkbms-voltronic.simple.yaml. EspHome reads relevant BMS data from MQTT and sends over RS485 ModBus RTU. Tested reading values with a python script and it works. Now I'm going to attach it to inverter. I cannot use esphome-jkbms and this implementation on the same ESP32 because esphome-jkbms use framework esp-idf, instead modbus-server component I'm using is only compatible with framework arduino. If I can port modbus-server to esp-idf, maybe I could use just one ESP32, without reading values from MQTT (another possible point of failure). EDIT: I connected ESP32 to inverter, Axpert asks data, ESP32 responses but after some time goes in error 61 (communication lost). Maybe I'm sending something wrong. [15:12:58][I][ON_READ:187]: address=0x33, value=61 [15:12:58][D][uart_debug:114]: <<< 01:03:00:33:00:01:74:05 [15:12:58][D][uart_debug:114]: >>> 01:03:02:00:3D:79:95 This is from LIB protocol documentation: But searching in another project I saw: Response format is different: | Slave Address | Function | Data Len n (1 byte) | n * bytes | CRC (2 bytes) | vs | Slave Address | Function | Data Len n (2 bytes) | 2 * n * bytes | CRC (2 bytes) | Using "Modbus Slave" fot test: DEBUG:pymodbus.transaction:Current transaction state - IDLE DEBUG:pymodbus.transaction:Running transaction 1 DEBUG:pymodbus.transaction:SEND: 0x1 0x3 0x0 0x33 0x0 0x1 0x74 0x5 DEBUG:pymodbus.client.sync:New Transaction state 'SENDING' DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY' DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY' DEBUG:pymodbus.transaction:RECV: 0x1 0x3 0x2 0x0 0x3d 0x79 0x95 DEBUG:pymodbus.framer.rtu_framer:Getting Frame - 0x3 0x2 0x0 0x3d seems response format ESP32 is sending is correct... so I don't understand why Voltronic reports error 61 jkbms-voltronic.simple.yaml Edited May 8, 20233 yr by pongo
May 10, 20233 yr Just realised I have 2 accounts on this forum, apologies. Will post again from other account. Edited May 10, 20233 yr by Enrico Zanolin Just realised I have 2 accounts on this forum apologies.
May 10, 20233 yr Just my 2 cents on what you are seeing. These seem to be requests from the Modbus master to the device with address 1 asking for data 01:03:00:01:00:02:95:CB 01:03:00:33:00:01:74:05 01:03:00:34:00:02:85:C5 01:03:00:70:00:01:85:D1 01:03:00:71:00:01:D4:11 01:03:00:72:00:01:24:11 01:03:00:73:00:01:75:D1 01:03:00:74:00:01:C4:10 01:03:00:01:00:02:95:CB 01: Device address 01 03: Read multiple Holding Registers (this is a ModBus Defined Function). 00:01 Register address 1 (the "variable" that we are after). 00:02 Number of registers (this would get 2 16 bit registers and would result in a 4 byte response). So actually you would be getting register 1 and 2 95:CB CRC Checksum of whole message. Given their structure these ones look like they could be responses from the Device on address 1 01:03:02:00:32:39:91 01:03:02:00:C0:B8:14 01:03:02:01:E0:B8:5C 01:03:02:01:F4:B8:53 01:03:02:02:44:B9:17 01:03:02:03:E8:B8:FA 01:03:04:00:04:45:C0:89:32 01:03:02:00:32:39:91 01: Device Address 01 03: Response to "Read multiple Holding Registers" 02: Length. (qty of bytes to follow) 00:32: first value of 50 39:91: CRC checksum 01:03:04:00:04:45:C0:89:32 01: Device Address 01 03: Response to "Read multiple Holding Registers" 04: Length. (qty of bytes to follow) 00:04: first value of 4 45:C0: second value of 17856 89:32: CRC checksum I have just completed building a rudimentary Modbus class and RS485 sniffer for ESP32 on Arduino for my own nefarious purposes. I would be more than happy to share it if you want to go that route (you will need an ESP32 and a RS485 transceiver). In practice I have noticed that the length stipulated in frame responses is for X octets not X words so if the length is 8 its 8 bytes or 4 int16's whereas in the request you ask for X registers which will return X 16 bit words or X*2 bytes. I find the documentation around this to be unclear so I am leaning on what I see on the bus for the meantime.
May 10, 20233 yr Hello, @Enrico Zanolin I know ModBus protocol... in the past I already developed RTU master clients in C or python. In response, data length should be 1 byte long and should indicate how many bytes contains, as my responses are written. You are right, these are requests from inverter 01:03:00:01:00:02:95:CB 01:03:00:33:00:01:74:05 01:03:00:34:00:02:85:C5 01:03:00:70:00:01:85:D1 01:03:00:71:00:01:D4:11 01:03:00:72:00:01:24:11 01:03:00:73:00:01:75:D1 01:03:00:74:00:01:C4:10 and these are some responses from my ESP32 to those requests 01:03:02:00:32:39:91 01:03:02:00:C0:B8:14 01:03:02:01:E0:B8:5C 01:03:02:01:F4:B8:53 01:03:02:02:44:B9:17 01:03:02:03:E8:B8:FA 01:03:04:00:04:45:C0:89:32 You can see better here [15:12:58][I][ON_READ:187]: address=0x33, value=61 [15:12:58][D][uart_debug:114]: <<< 01:03:00:33:00:01:74:05 [15:12:58][D][uart_debug:114]: >>> 01:03:02:00:3D:79:95 <<< means request from inverter (asking SoC) >>> means response from ESP32 (sendig 61 %). The problem is that inverter didn't accept my responses (they are correct in my opinion) showing error 61. Connection is correct, because ESP32 receives requests from inverter. I don't know if I'm missing some important information that inverter needs or if my responses are not accepted for their format. I don't understand if LIB protocol description is wrongly written or if it really expects response in that format: LEN 2 bytes long, data 2*LEN bytes long (not standard in my opinion). As device I'm using an ESP32 M5Stack Atom RS485 (used also in other projects). Did your code work to communicate with inverter? I would be happy to look at you code, thanks. @Rozsda could you share your solution, please? I never developed CAN protocol. EspHome is my preferred way to proceed, thanks.
May 11, 20233 yr Checking on official ModBus specification document MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1b3, on page 15: my conclusion is that LIB protocol is not a standard ModBus protocol implementation, but a custom protocol. For standard modbus protocol, request 01:03:00:33:00:01:74:05 expects response 01:03:02:00:3D:79:95 Looking on another python implementation from @googy (https://powerforum.co.za/topic/10545-bms-communication-with-axpert-max/?do=findComment&comment=112805) response is 01:03:00:01:00:3D:D5:DB Completely different from standard ModBus. So, my assumption that this is modbus was wrong. My conclusions are: I cannot use modbus, I have to implement directly LIB serial protocol on my own. Edited May 11, 20233 yr by pongo
May 11, 20233 yr On 2023. 05. 05. at 18:22, pongo said: Helló, @BritishRacingGreen,@Rozsda,@PetrDubi megosztanád a megvalósításaidat? Én is próbálok valamit megvalósítani, hogy a JKBMS-t az Axperthez kössem, próbáltam LIB-vel. Tökéletesen működik, ha pymodbus-szal kérek értékeket, de az inverter nem kér ModBust a BMS RS485 porton (akkumulátor típusának beállítása LIB-re). Csatoltam az EspHome yaml fájlomat (az értékek csak tesztelésre szolgálnak, ha működik, megpróbálok adatokat venni a BMS-ből). A megfelelő rész a "modbus_server" alatt található. Kösz jkbms-voltronic.yaml 8,49 kB · 2 letöltés Hello. I implemented the SOLTARO protocol. Communicates on the SOLTARO CAN bus! I tried to implement the LIB protocol, but it didn't accept my response message either. That's why I decided on the SOLTARO protocol on the CAN bus. My goal was that the battery should not be charged 100% by the inverter.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.