Axpert Max-komunikace RS485 s BMS JBD-AP20S003-P20S-200A-B-C

[PetrDubi]

No jo, ale ty víš, co SA očekává na RS485? Já teda ne. A pokud to není zprasený jako v Dali, tak se na RS485 očekává protokol typu MODBUS, což znamená úplně jinou komunikaci než na UART (jen namátkou více zařízení na jedné sběrnici, adresování jednotlivých zařízení a podobně).
Takže já osobně nevím, co tam má běhat.
Jedině vyzkoušet a pak se uvidí - maximálně mu zbyde ten převodník v šuplíku a bude hkedat něco jiného.
Ale rozhodně mu neporadím, že to bude fungovat, protože jsem žádné informace k tomu RS485 u JBD neviděl.

[PavlikT]

No, proto ten dotaz byl na Mikela

[antoni_sk]

z JBD BMS normálne vyčítavame Modbus protokolom cca 30 hodnôt (registrov)... vid moje vlákno.
RS485 aj UART je len fyzická špecifikácia akým spôsobom údaje "cestujú" po vodičoch.
Prevodník je síce pripojený do UART konektoru ale protokol používame štandard Modbus.

[PavlikT]

z JBD BMS normálne vyčítavame Modbus protokolom cca 30 hodnôt (registrov)... vid moje vlákno.
RS485 aj UART je len fyzická špecifikácia akým spôsobom údaje "cestujú" po vodičoch.
Prevodník je síce pripojený do UART konektoru ale protokol používame štandard Modbus.

Supr, muzes, pls, poslat link na to vlakno? Vim, ze je tu jedno podobne, ale prislo mi, ze je to trosku jina BMSka. Ja jsem ji kupoval pred rokem a byla to takova cerna cihla. Dnesni JBD BMS vypada jak bez sasi. Treba funguji vnitne stejne, ale to ja netusim.
Jaky kabel k tomu pouzivas?
Diky

[gold1]

z JBD BMS normálne vyčítavame Modbus protokolom cca 30 hodnôt (registrov)... vid moje vlákno.
RS485 aj UART je len fyzická špecifikácia akým spôsobom údaje "cestujú" po vodičoch.
Prevodník je síce pripojený do UART konektoru ale protokol používame štandard Modbus.

Supr, muzes, pls, poslat link na to vlakno? Vim, ze je tu jedno podobne, ale prislo mi, ze je to trosku jina BMSka. Ja jsem ji kupoval pred rokem a byla to takova cerna cihla. Dnesni JBD BMS vypada jak bez sasi. Treba funguji vnitne stejne, ale to ja netusim.
Jaky kabel k tomu pouzivas?
Diky

Uz se ti to podarilo zprovoznit?Taky by mne zajimalo jestli ta bmska jde propojit s SA.

[PavlikT]

Jj, povedlo!

Diky Cipisovi:

https://forum.mypower.cz/viewtopic.php ... 7#p181166

Musel ksem odpojit BT modul a napojit to misto nej. Staci GND, Rx a Tx. Ale pak uz to slo, jal po dratkach. V SA zvolis JBD RS232/485 a jede to na prvni dobrou.

[gold1]

Dik za odpoved,pokusim se o to,ale vypada to az prilis snadno.Ani se mi nechce verit.)

[jeroslav]

Podařilo se vám rozjet komunikaci mezi Axpertem a JBD BMS? Axpert mi zbytečně brzo utahuje nabíjení, tak si od komunikace s BMS slibují vyřešení problémů.
Zkoušel jsem připojovat přes RS485, ale narazil jsem na stejné problémy.

Díky,
J.

[PetrDubi]

Ahoj,
tak jsem včera zprovoznil komunikaci mezi JBD BMS a MAXem přes CAN. Mezi BMS a měničem je ESP32, na který je připojený CAN bus transiever na 3,3V SN65HND230 a používám interní CAN controller, který v sobě ESP32 má.
ESP32 je napojené na BMS přes její UART port (místo bluetooth modulu) a na měnič přes CAN transiever do portu pro BMS.
V ESP32 je nahraný program pro ESPhome od Syssi z githubu:
https://github.com/syssi/esphome-jbd-bms
Dále jsem doplnil odesílání přes CAN protokolem Soltaro.
Popis protokolou zde:
https://forums.aeva.asn.au/viewtopic.ph ... 1b3#p88506
a například zde:
https://powerforum.co.za/topic/10545-bm ... xpert-max/
Použil jsem Soltaro, protože s Weco byly podle popisu nějaký problémy.
Na adresu 0x1872 posílám informace každých 5s a na 0x1874 každé 2s.
Po změně typu baterie v měniči po spojení s BMS začne blikat na displeji ikona baterie a u informací o verzi firmware měniče se objeví nová informace o Number of packs and groups.
Po propojení veškerý nabíjení řídí BMS, takže se odesílají povolené proudy i napětí a v měniči se objeví hodnoty, ale nejdou změnit.
Zjistil jsem, že se napětí pro bulk i pro float nastaví na stejnou hodnotu, která odpovídá maximum charge voltage z 0x1872, takže po nabití baterie je nutné poslat do měniče nové požadované napětí, které odpovídá float.
Momentálně mám nastavené, že pokud je SOC pod 98%, tak se nastaví napětí na 55V a když SOC dosáhne 100% a nabíjecí výkon do BMS klesne pod 50W (mám to připojené na 150A BMS, která měří i pod 2A narozdíl od té 200A), tak nastaví napětí 53,6V. Budu to dál sledovat a podle provozu to případně upravím. Mělo by to i vyřešit problém, že měnič občas zůstává dlouho v bulk i když nabíjecí proud klesne na nulu.

[PavlikT]

To zní skvěle! Náhodou se Ti nechce nasdilet tu cast s tim protokolem Soltaro?...

[PetrDubi]

Tak by jsi tam měl mít všechno, co je k tomu potřeba. Jsou tam hodnoty z BMS který používám, pomocný senzory, prodloužený timeout pro komunikaci s BMS (aby nevypadávala komunikace s BMS při odesílání na CAN) a podobně. Odesílání na CAN je ve dvou intervalech, protože když jsem to měl hned za sebou, tak fungovalo (podle logu) posílání i komunikace s BMS, ale zmizely mi všechny sensory od BMS v HA (když jsem to takhle rozhodil, tak už to bylo dobrý).
Ty napětí a proudy jsou s desetinama, proto tam jsou takový čísla a napětí baterie se násobí 10.

Kód: Vybrat vše

jbd_bms:
  rx_timeout: 500ms

canbus:
  - platform: esp32_can
    tx_pin: GPIO5
    rx_pin: GPIO4
    can_id: 0x1fff
    id: canbus0
    use_extended_id: true
    bit_rate: 500kbps

interval:
  - interval: 5s
    then:
          - canbus.send:
              use_extended_id: true
              can_id: 0x00001872
              canbus_id: canbus0
# charging voltage, minimal voltage,  charging current,  discharging current
              data: !lambda |-
                uint8_t can_mesg[8] { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
                uint16_t bms_max_v = id(bms_charg_v).state;
                uint16_t bms_min_v = 490;
                uint16_t bms_max_ch = 1200;
                uint16_t bms_max_d = 1500;
                can_mesg[1] = bms_max_v & 0x00FF;
                can_mesg[2] = (bms_max_v >> 8) & 0x00FF;
                can_mesg[3] = bms_min_v & 0x00FF;
                can_mesg[4] = (bms_min_v >> 8) & 0x00FF;
                can_mesg[5] = bms_max_ch & 0x00FF;
                can_mesg[6] = (bms_max_ch >> 8) & 0x00FF;
                can_mesg[7] = bms_max_d & 0x00FF;
                can_mesg[8] = (bms_max_d >> 8) & 0x00FF;
                ESP_LOGI("main", "send can id: 0x00001872 hex: %x %x %x %x %x %x %x %x", can_mesg[1], can_mesg[2], can_mesg[3], can_mesg[4], can_mesg[5], can_mesg[6], can_mesg[7], can_mesg[8]);
                return {can_mesg[1], can_mesg[2], can_mesg[3], can_mesg[4], can_mesg[5], can_mesg[6], can_mesg[7], can_mesg[8]};

  - interval: 2s
    then:
          - canbus.send:
              use_extended_id: true
              can_id: 0x00001874
              canbus_id: canbus0
# battery voltage, absorption voltage (not function), battery SOC, number of battery packs
              data: !lambda |-
                uint8_t can_mesg[8] { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
                uint16_t bms_compl_v = (id(fv_baterie2_complete_voltage).state * 10.0f);
                uint16_t bms_abs = 552;
                uint16_t bms_soc = id(fv_baterie2_soc).state;
                uint8_t bms_num_pack = 1;
                id(bms_charging_comp).publish_state(true);
                can_mesg[1] = bms_compl_v & 0x00FF;
                can_mesg[2] = (bms_compl_v >> 8) & 0x00FF;
                can_mesg[3] = bms_abs & 0x00FF;
                can_mesg[4] = (bms_abs >> 8) & 0x00FF;
                can_mesg[5] = bms_soc & 0x00FF;
                can_mesg[6] = (bms_soc >> 8) & 0x00FF;
                can_mesg[7] = 0x00;
                can_mesg[8] = bms_num_pack;
                ESP_LOGI("main", "send can id: 0x00001874 hex: %x %x %x %x %x %x %x %x", can_mesg[1], can_mesg[2], can_mesg[3], can_mesg[4], can_mesg[5], can_mesg[6], can_mesg[7], can_mesg[8]);
                return {can_mesg[1], can_mesg[2], can_mesg[3], can_mesg[4], can_mesg[5], can_mesg[6], can_mesg[7], can_mesg[8]};




binary_sensor:
  - platform: template
    id: bms_charging_comp
    internal: true

  - platform: template
    id: bms_charging_bulk
    internal: true
    lambda: |-
      if ((id(fv_baterie2_soc).state <= 98) && (id(bms_charging_comp).state == true)) {
        id(bms_charg_v).publish_state(550);
        id(bms_charging_comp).publish_state(false);
        return true;  
        } else {
        return false;
        }

  - platform: template
    id: bms_charging_float
    internal: true
    lambda: |-
      if ((id(fv_baterie2_soc).state == 100) && (id(fv_baterie2_charging_power).state < 50)  && (id(bms_charging_comp).state == true)) {
        id(bms_charg_v).publish_state(536);
        id(bms_charging_comp).publish_state(false);
        return true;  
        } else {
        return false;
        }

sensor:
  - platform: jbd_bms
    charging_power:
      name: "${name} mabíjecí výkon"
      id: fv_baterie2_charging_power
    state_of_charge:
      name: "${name} stav nabití SOC"
      id: fv_baterie2_soc
    total_voltage:
      name: "${name} celkové napětí"
      id: fv_baterie2_complete_voltage
  
  - platform: template
    name: "bms_charg_v"
    id: bms_charg_v
    internal: true

[PavlikT]

Skvělé! Moc děkuji. Dal jsem hned bodík Jak budu mit zejtra čas, tak to hned prubnu. Už dlouho hledám podobné řešení, aby měnič o baterce věděl. Zatim to mám přes Solar-assistant, ale pořád ta komunikace tomu chybí... I když aspoň vidím oba batery packy. Takhle to bude dokonalé Mám dva Battery packy (oba JBD, ale rozdilne generace). Mysliš, že menič si může povídat se dvěma zároveň, když bude mít druha bms_num_pack =2? Nebo uvažuji špatně?

[PetrDubi]

Ahoj,
možná jo, nezkoušel jsem to. Ale dal jsem to na baterku s novější BMS, která měří prakticky od nuly, protože to SOC je na ní přesnější.
Jinak není problém si to z jediný baterky s ESPhome přetáhnout do druhý baterky s ESPhome, už to takhle na některých zařízeních mám udělaný (všechny sensory je možný použít i v jiných zařízeních s ESPhome). Mám takhle vlastně přetáhnutý i SOC a napětí nejvybitějšího článku z téhle BMS do té první, protože ta první podle stavu baterií vypíná přes relátko měnič.

[PetrDubi]

Tak už to běží 5 dní v kuse a bez jediného výpadku (když by ESP přestalo pravidelně posílat informace do měniče, tak měnič nejdřív zobrazí chybu komunikace s BMS a po nějaké době bez nových informací vypne měnič).
Regulace nabíjecího napětí vypadá že funguje dobře, když se nabije baterka (klesne proud), tak se přepne do floatu a tam se udržuje dokud neklesne SOC pod těch 98% a potom zase začne nabíjet na 55V (aby se dobila rychleji).

[jeroslav]

Suprová práce! Zkusil jsem to přidat ke stávající konfiguraci s ESP, ale bohužel jsem zatím u Kinga skončil s nezdarem. Prvně se teda komunikace chytla, ale nastavilo se float a cutoff napětí na 51.2V. Po chvíli komunikace skončila a vyskočil warning 61. Potom již bez úspěchu.
V kódu by se toho tedy moc měnit nemělo, ne? V zásadě jsem jen změnil mapování na GPIO a změnil názvy senzorů, které tahám z BMS. Pouze si říkám, že pokud jsou lambdy v C++, tak jestli by se mělo indexovat od 0.
Přikládám ještě ilustraci zapojení:

[PetrDubi]

To s těma lambdama jsem si taky myslel, ale od nuly mi to nefungovalo a po předělání od jedničky už to šlo (byl snad problém s kompilací - už si to přesně nepamatuju, laboroval jsem s tím s přestávkama snad dva týdny).
Jo změnit jenom gpio a názvy proměnných a mělo by to běhat.
Pokud vyskočí chyba 61, tak zmizela komunikace - měnič nedostává informace. Pak se jedině podívat do logu, jestli ukazuje posílání dat přes can.

[PetrDubi]

Jinak já používám na ESP32 tenhle převodník:
https://esphome.io/_images/canbus_esp32_3v3.png

Jo a na tom tvém zapojení máš obráceně vodiče, CAN H má být pin 6 a CAN L pin 7 (pokud to nemá King jinak, ale moc tomu nevěřím).

[GsPiDeR]

Dovolím si zareagovat k tématu CAN u Aexpert Kinga II a zapojení pinů ... snažím se marně dohledat co vlastně platí (potřebuji se rozměhnout malinko jiný projekt - Uksa007/esphome-jk-bms-can). Je to tak že AE KII používá CAN H - 6pin a CAN L - 7pin a GND 8? Máte někdo zkušenost?

[PetrDubi]

Jen malý detail, Voltronics podporuje komunikaci protokolem Pylontech pouze po RS485 a po CANu umí komunikovat pouze s Weco nebo Soltaro...
Tohle jsou informace, který jsou uvedený všude možně (včetně tohohle fóra a možná dokonce i v tomhle vlákně)..
To fakt nikdo neumí číst????

[k3ivi]

Ahoj,
tak jsem včera zprovoznil komunikaci mezi JBD BMS a MAXem přes CAN. Mezi BMS a měničem je ESP32, na který je připojený CAN bus transiever na 3,3V SN65HND230 a používám interní CAN controller, který v sobě ESP32 má.
ESP32 je napojené na BMS přes její UART port (místo bluetooth modulu) a na měnič přes CAN transiever do portu pro BMS.
V ESP32 je nahraný program pro ESPhome od Syssi z githubu:
https://github.com/syssi/esphome-jbd-bms
Dále jsem doplnil odesílání přes CAN protokolem Soltaro.
Popis protokolou zde:
https://forums.aeva.asn.au/viewtopic.ph ... 1b3#p88506
a například zde:
https://powerforum.co.za/topic/10545-bm ... xpert-max/
Použil jsem Soltaro, protože s Weco byly podle popisu nějaký problémy.
Na adresu 0x1872 posílám informace každých 5s a na 0x1874 každé 2s.
Po změně typu baterie v měniči po spojení s BMS začne blikat na displeji ikona baterie a u informací o verzi firmware měniče se objeví nová informace o Number of packs and groups.
Po propojení veškerý nabíjení řídí BMS, takže se odesílají povolené proudy i napětí a v měniči se objeví hodnoty, ale nejdou změnit.
Zjistil jsem, že se napětí pro bulk i pro float nastaví na stejnou hodnotu, která odpovídá maximum charge voltage z 0x1872, takže po nabití baterie je nutné poslat do měniče nové požadované napětí, které odpovídá float.
Momentálně mám nastavené, že pokud je SOC pod 98%, tak se nastaví napětí na 55V a když SOC dosáhne 100% a nabíjecí výkon do BMS klesne pod 50W (mám to připojené na 150A BMS, která měří i pod 2A narozdíl od té 200A), tak nastaví napětí 53,6V. Budu to dál sledovat a podle provozu to případně upravím. Mělo by to i vyřešit problém, že měnič občas zůstává dlouho v bulk i když nabíjecí proud klesne na nulu.

Super práce, mohl bych poprosit ještě o trochu vedení za ručičku, jak doplnit ten kód do projektu od Syssi a nacpat to do ESP32? Klidně SZ. Potřeboval bych to na propojení s Deye, jestli je to možné nějak nadrátovat. Na Githubu jsou dva projekty, které řeší JBD po CAN na hybridy s pylontech protokolem např.. Jeden placený od Uksa007. Druhý přes diysolarforum - mrconstantin se celkem rozjíždí, ale moc součástek na sestavení.