Witam męcze się już trochę aby połączyć magazyn energii przewodowo z esp32
Z pomocą chata gpt niestety i nie mogę sobie poradzić
Kupiłem konwerter TTL który polaczylem z esp tak jak na zdjeciu
Chat wygenerował mi kod
Piny z rj 45 1 i 2 tj pomarańczowy i pomarańczowo biały podpinam do konwertera
I za cholere nie chce to ruszyć
Czy ktoś może pomóc?
Po pierwsze wklej Yaml bo nikt nie będzie czytał że zdjęcia.
Po drugie podałeś znikome informacje. Podaj trochę więcej. Jaki masz model BMSa, do jakiego portu podpinasz, czy podpinasz bezpośrednio do BMSa czy do płytki komunikacyjnej z portami RJ45 które zazwyczaj są w gotowych zestawach ?
Przepraszam ale z telefonu nie chciało się skopiować
Magazyn to
To wygenerował mi chat gpt
Wpinam do portu praktycznie każdego rs485 RS 485a rs485b i nic
esphome:
name: jkbms
esp32:
board: esp32dev
framework:
type: arduino
external_components:
* source: github://syssi/esphome-jk-bms
logger:
api:
ota:
platform: esphome
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
uart:
tx_pin: GPIO17
rx_pin: GPIO16
baud_rate: 115200
jk_bms:
* id: bms0
address: 0x4E
sensor:
* platform: jk_bms
jk_bms_id: bms0
total_voltage:
name: “JK Voltage”
To są ligi z esp
INFO ESPHome 2026.3.1
INFO Reading configuration /config/esphome/esp32a.yaml…
INFO Starting log output from jkbms.local using esphome API
INFO Successfully resolved jkbms.local in 1.252s
INFO Successfully connected to jkbms @ 192.168.1.189 in 0.008s
INFO Successful handshake with jkbms @ 192.168.1.189 in 0.023s
\[10:16:05.828\]\[I\]\[app:231\]: ESPHome version 2026.3.1 compiled on 2026-03-31 23:34:45 +0200
\[10:16:05.829\]\[I\]\[app:238\]: ESP32 Chip: ESP32 rev3.1, 2 core(s)
\[10:16:05.829\]\[W\]\[app:247\]: Set minimum_chip_revision: “3.1” to reduce binary size
\[10:16:05.829\]\[C\]\[logger:229\]: Logger:
\[10:16:05.829\]\[C\]\[logger:229\]: Max Level: DEBUG
\[10:16:05.829\]\[C\]\[logger:229\]: Initial Level: DEBUG
\[10:16:05.832\]\[C\]\[logger:236\]: Log Baud Rate: 115200
\[10:16:05.832\]\[C\]\[logger:236\]: Hardware UART: UART0
\[10:16:05.832\]\[C\]\[logger:246\]: Task Log Buffer Size: 768 bytes
\[10:16:05.850\]\[C\]\[uart.idf:247\]: UART Bus 1:
\[10:16:05.851\]\[C\]\[uart.idf:152\]: TX Pin: GPIO17
\[10:16:05.854\]\[C\]\[uart.idf:152\]: RX Pin: GPIO16
\[10:16:05.855\]\[C\]\[uart.idf:252\]: RX Buffer Size: 256
\[10:16:05.855\]\[C\]\[uart.idf:252\]: RX Full Threshold: 114
\[10:16:05.855\]\[C\]\[uart.idf:252\]: RX Timeout: 2
\[10:16:05.855\]\[C\]\[uart.idf:261\]: Baud Rate: 115200 baud
\[10:16:05.855\]\[C\]\[uart.idf:261\]: Data Bits: 8
\[10:16:05.855\]\[C\]\[uart.idf:261\]: Parity: NONE
\[10:16:05.855\]\[C\]\[uart.idf:261\]: Stop bits: 1
\[10:16:05.855\]\[C\]\[uart.idf:261\]: Wake on data RX: ENABLED
\[10:16:05.873\]\[C\]\[jk_modbus:121\]: JkModbus:
\[10:16:05.879\]\[C\]\[jk_modbus:122\]: RX timeout: 50 ms
\[10:16:05.885\]\[C\]\[jk_bms:550\]: JkBms:
\[10:16:05.885\]\[C\]\[jk_bms:551\]: Address: 0x4E
\[10:16:05.885\]\[C\]\[jk_bms:017\]: Total Voltage ‘JK Voltage’
\[10:16:05.885\]\[C\]\[jk_bms:017\]: State Class: ‘measurement’
\[10:16:05.885\]\[C\]\[jk_bms:017\]: Unit of Measurement: ‘V’
\[10:16:05.885\]\[C\]\[jk_bms:017\]: Accuracy Decimals: 2
\[10:16:05.898\]\[C\]\[jk_bms:237\]: Device Class: ‘voltage’
\[10:16:05.906\]\[C\]\[wifi:1510\]: WiFi:
\[10:16:05.906\]\[C\]\[wifi:1510\]: Local MAC: 28:05:A5:35:EA:D8
\[10:16:05.906\]\[C\]\[wifi:1510\]: Connected: YES
\[10:16:05.907\]\[C\]\[wifi:1221\]: IP Address: 192.168.1.189
\[10:16:05.907\]\[C\]\[wifi:1232\]: SSID: ‘tuya’\[redacted\]
\[10:16:05.907\]\[C\]\[wifi:1232\]: BSSID: BA:FB:E4:C4:21:75\[redacted\]
\[10:16:05.907\]\[C\]\[wifi:1232\]: Hostname: ‘jkbms’
\[10:16:05.907\]\[C\]\[wifi:1232\]: Signal strength: -43 dB ▂▄▆█
\[10:16:05.907\]\[C\]\[wifi:1232\]: Channel: 6
\[10:16:05.907\]\[C\]\[wifi:1232\]: Subnet: 255.255.255.0
\[10:16:05.907\]\[C\]\[wifi:1232\]: Gateway: 192.168.1.1
\[10:16:05.907\]\[C\]\[wifi:1232\]: DNS1: 192.168.1.1
\[10:16:05.907\]\[C\]\[wifi:1232\]: DNS2: 0.0.0.0
\[10:16:05.926\]\[C\]\[esphome.ota:071\]: Over-The-Air updates:
\[10:16:05.926\]\[C\]\[esphome.ota:071\]: Address: jkbms.local:3232
\[10:16:05.926\]\[C\]\[esphome.ota:071\]: Version: 2
\[10:16:05.975\]\[C\]\[safe_mode:026\]: Safe Mode:
\[10:16:05.975\]\[C\]\[safe_mode:026\]: Successful after: 60s
\[10:16:05.975\]\[C\]\[safe_mode:026\]: Invoke after: 10 attempts
\[10:16:05.975\]\[C\]\[safe_mode:026\]: Duration: 300s
\[10:16:05.975\]\[C\]\[safe_mode:043\]: Bootloader rollback: support unknown
\[10:16:05.975\]\[C\]\[api:237\]: Server:
\[10:16:05.975\]\[C\]\[api:237\]: Address: jkbms.local:6053
\[10:16:05.975\]\[C\]\[api:237\]: Listen backlog: 4
\[10:16:05.975\]\[C\]\[api:237\]: Max connections: 8
\[10:16:05.981\]\[C\]\[api:249\]: Noise encryption: NO
\[10:16:05.982\]\[C\]\[mdns:194\]: mDNS:
\[10:16:05.982\]\[C\]\[mdns:194\]: Hostname: jkbms
\[10:16:41.164\]\[W\]\[jk_modbus:071\]: Invalid header: 0x4E 0x88
\[10:17:30.451\]\[W\]\[jk_modbus:071\]: Invalid header: 0x4E 0x2C
Też piszę z telefonu więc narazie nie będzie wszystko idealne.
Tu sprawdź sobie czy masz dobrze podłączone(trochę po chińsku, ale są się rozczytać), chodzi oczywiście o RS485:
Oraz tu masz cały PDF:
https://share.google/i36S6mGUBrJO2p3Jl
Z tego co się orientuję to chyba nic nie zmieniałem w ustawieniach. Ale nie jestem pewny…
Robiłem według tego 1 i drugi pin czyli pomarańczowy i biało pomarańczowy przewód do konwertera
Czat mi pisze ze wszystko jest git tylko mój bms nie obsługuje jakiegoś protokołu choć najpierw pisał że obsługuje
Mam go już dosyć
To może poświęć kilka dni na samodzielne czytanie dokumentacji projektu, za który chcesz się brać… bo jak tam zajrzałem to metod jest wiele, ale jak dotąd nie znalazłem takiej kombinacji jak próbujesz używać
Wrzuciłem Twój problem do AI i wypluł:
Problem jest wielowarstwowy
Twój BMS to JK-PB (ESS series) — to zupełnie inny sprzęt niż zwykły JK BMS B-series, do którego pisany był komponent syssi/esphome-jk-bms.
Warstwa 1 — okablowanie RS485
Z manuala (str. 8/13): RJ45 RS485-1 pinout to:
Kolory standardowego kabla sieciowego:
To brzmi poprawnie, ALE jeśli Twój konwerter TTL→RS485 ma oznaczenia A i B, to upewnij się że masz: BMS-A → konwerter-A i BMS-B → konwerter-B. Wiele tanich konwerterów ma A i B odwrócone od standardu. Spróbuj zamienić.
Warstwa 2 — zły komponent ESPHome
Do JK-PB z RS485 nie używasz jk_bms + jk_modbus, tylko:
jk_rs485_bms:
- id: bms0
address: 0x01 # ← adres z DIP switchy na adapterze
I sensor platform też się zmienia na jk_rs485_bms.
Warstwa 3 — adres BMS
Z manuala (str. 11): adres ustawiają DIP switche na adapterze. 0x4E w YAML to 78 dziesiętnie — sprawdź czy DIP switche faktycznie dają taki adres. Dla pojedynczego BMS (master) adres powinien być 0 (wszystkie OFF).
Jaki adres masz ustawiony na DIP switchach?
Początek brzmi sensownie, ale reszta już zakrawa na bredzenie AI (na moje oko taki komponent jk_rs485_bms nie istnieje, a przynajmniej nie widzę go na repozytorium @syssi)
Yaml dla tej serii (UWAGA to jest przykład, a nie gotowiec do copy+paste i trzeba go zmodyfikować)
@Krzyszof_K Twoje AI (przynajmniej według mojej wiedzy) mówi pół prawdę…
Prawdą raczej jest że jest to inna wersja BMSa niż standardowe w seri B.
A to do czego mam uwagę
Częściowo prawda.
Istnieje komponent, który działa w trybie sniffing na magistrali RS ( gdy kilka BMS jest połączonych równolegle).
Ale nie zawsze jest to wymagane.
Dla pojedynczego używaja się raczej modbus przez RS485-1 (protocol 001 = JK BMS RS485 Modbus v1.0).
W repo esphome-jk-bms jest przykład właśnie pod PB serię.
Adres 0x01 Jeśli masz pojedynczy BMS, to lepiej ustawić adres 0 (wszystkie DIP OFF) i w YAML podać address 0x00. Adres 1 jest dla slavea w układzie równoległym
W tym przykładzie jest nawet komentarz:„Don’t turn off all dip switches / don’t use device address 0x00. This is the Modbus Master mode. You must select a device address between 0x01 and 0x0f so the BMS acts as Modbus Slave.”
OFF TOPIC:
Nie wiem jakiego AI używasz bo mi się zdaje że taki komponent jak jk_rs485_bms , chyba nie istnieje.(Ale po takim stylu wypowiedzi myslę że może to być Cloude ale trochę podrasowany przez użytkownika).
OFF TOPIC 2:
Tą odpowiedź pisałem chyba 30min, a teraz widzę że @szopen dał prawie wszystko to co ja 
Mówi półprawdę. Przeprosił mnie za halucynacje - @szopen miał racje.
Cisne go o rozwiązanie
Pierwotnie wrzuciłem do Claude - teraz wrzuciłem do Chat GPT.
EDIT - no i wymyślił. Wstawiam do jakich wniosków doszedł Chat GPT.
Oczywiście to żadna wyrocznia:
Jasne. Masz to zebrane w jedną, spójną całość:
To, co napisał użytkownik o przewodach, czyli że brał pierwszy i drugi pin z RJ45, samo w sobie nie wygląda źle. W manualu JK-PB dla portu RS485-1 jest pokazane, że pin 1/8 = RS485-B1, pin 2/7 = RS485-A1, a RS485-1 to port komunikacyjny, natomiast RS485-2 służy do pracy równoległej między bateriami. Czyli jeśli siedział na parze 1–2, to elektrycznie mógł być w dobrym miejscu.
Druga sprawa to adres. Tu wcześniejsze 0x4E było po prostu błędne dla JK-PB. Manual mówi, że adres ustawia się 4 DIP-ami, a ich wartości to 1, 2, 4 i 8, więc realnie mówimy o zakresie 0–15. Dodatkowo instrukcja dla pracy równoległej mówi jasno, że adres 0 jest używany dla mastera w układzie równoległym, a pozostałe urządzenia mają mieć różne adresy slave. Czyli 0x00 istnieje, ale nie jako zwykły adres do odczytu pojedynczego BMS-a przez ESP, tylko jako tryb master w określonym scenariuszu.
I tu dochodzimy do najważniejszego błędu Claude’a: pomieszał zwykły komponent jk_bms z obsługą JK-PB po prawdziwym Modbus RS485. Repozytorium syssi/esphome-jk-bms w README opisuje główny komponent jako rozwiązanie do monitorowania JK-BMS przez UART-TTL albo BLE, a nie jako uniwersalny driver do każdego JK po każdym możliwym interfejsie. Jednocześnie w repo są osobne pliki przykładowe dla PB, w tym esp8266-jk-pb-modbus-example.yaml, więc sam maintainer wyraźnie rozdziela zwykłe JK od serii PB po Modbus. (GitHub)
To oznacza wprost: dla JK-PB nie powinno się iść ścieżką „standardowy jk_bms + jk_modbus”, tylko ścieżką z modbus: + modbus_controller: opartą o przykład jk-pb-modbus. W samym pliku przykładowym jest to napisane wprost: „Monitor a JK-BMS (JK-PB series) via Modbus”. (GitHub)
Dalej jest już całkiem klarownie. W przykładzie syssi dla JK-PB masz komentarz, że przy pojedynczym pakiecie i adresie 0x01 DIP ma być ustawiony na 1 = ON, reszta OFF, oraz że nie wolno używać 0x00, bo to jest Modbus Master mode. Wprost pada tam zdanie, że trzeba wybrać adres od 0x01 do 0x0f, żeby BMS działał jako Modbus Slave. To się idealnie spina z manualem JK-PB, gdzie adres 0 jest zarezerwowany dla mastera przy pracy równoległej. (GitHub)
Czyli końcowy wniosek jest taki:
Masz rację, że wcześniejsze odpowiedzi AI były niespójne. Fizyczne podłączenie mogło być dobre, ale AI błędnie uznało, że problem leży tylko w „nieobsługiwanym protokole” albo że zwykły jk_bms wszystko załatwi. Nie załatwi. W przypadku JK-PB trzeba użyć wariantu PB po Modbus, a nie standardowego przykładu dla UART/BLE. 0x4E było błędne. Dla pojedynczego BMS-a sensowny i zgodny z przykładem jest adres 0x01. 0x00 nie jest „złym adresem zawsze”, tylko oznacza tryb master, więc do zwykłego odczytu przez ESP się nie nadaje. (GitHub)
Dodatkowo manual JK-PB mówi, że w PC software adres po stronie programu ma być ustawiony tak samo jak adres wydialowany na BMS-ie, więc znów: nie ma tu żadnej magii z 0x4E, tylko zwykłe dopasowanie do DIP-ów.
W praktyce poprawny kierunek testu wygląda więc tak:
DIP = 1,
BMS jako slave, nie master,
port RS485-1,
ESPHome na bazie esp32/esp8266-jk-pb-modbus-example.yaml,
modbus_controller z adresem 0x01,
a nie zwykły przykład jk_bms. (GitHub)
Oraz zaproponowane rozwiązanie :
Masz. To jest prosty YAML startowy pod JK-PB + RS485 + MAX485 + ESP32. Bazuje na oficjalnym przykładzie esp32-jk-pb-modbus-example.yaml z repo syssi: komunikacja idzie przez modbus_controller, UART ma 115200, rx_buffer_size: 384, a dla pojedynczego pakietu startujesz od adresu 0x01. Manual JK-PB potwierdza też, że do takiej komunikacji używasz portu RS485-1; na RJ45 masz 1/8 = B, 2/7 = A, 3/6 = GND, a adres 0 jest zarezerwowany dla mastera przy pracy równoległej. (GitHub)
substitutions:
name: jk-pb-bms
friendly_name: JK PB BMS
# ZMIEŃ pod swoje GPIO
tx_pin: GPIO16
rx_pin: GPIO17
de_re_pin: GPIO4
esphome:
name: ${name}
friendly_name: ${friendly_name}
comment: "JK-PB via RS485 Modbus"
esp32:
board: esp32dev
framework:
type: esp-idf
external_components:
- source: github://syssi/esphome-jk-bms@main
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
logger:
level: DEBUG
api:
ota:
- platform: esphome
uart:
- id: uart_0
baud_rate: 115200
rx_buffer_size: 384
tx_pin: ${tx_pin}
rx_pin: ${rx_pin}
modbus:
- id: modbus0
uart_id: uart_0
flow_control_pin: ${de_re_pin}
modbus_controller:
- id: bms0
address: 0x01
modbus_id: modbus0
setup_priority: -10
update_interval: 5s
command_throttle: 50ms
sensor:
- platform: modbus_controller
modbus_controller_id: bms0
name: "JK PB MOSFET temperature"
address: 0x128A
register_type: holding
value_type: S_WORD
unit_of_measurement: "°C"
state_class: measurement
accuracy_decimals: 1
filters:
- multiply: 0.1
- platform: modbus_controller
modbus_controller_id: bms0
name: "JK PB total voltage"
address: 0x1290
register_type: holding
value_type: U_DWORD
unit_of_measurement: "V"
device_class: voltage
state_class: measurement
accuracy_decimals: 3
filters:
- multiply: 0.001
- platform: modbus_controller
modbus_controller_id: bms0
name: "JK PB total runtime"
address: 0x12BC
register_type: holding
value_type: U_DWORD
unit_of_measurement: "s"
accuracy_decimals: 0
state_class: total_increasing
binary_sensor:
- platform: status
name: "JK PB ESP status"
Podłączenie:
BMS RS485-1 pin 1/8 (B) → MAX485 B
BMS RS485-1 pin 2/7 (A) → MAX485 A
BMS RS485-1 pin 3/6 (GND) → GND
MAX485 RO → ESP RX (${rx_pin})
MAX485 DI → ESP TX (${tx_pin})
MAX485 DE + RE razem → ESP ${de_re_pin}
Przed testem ustaw:
DIP: 1 = ON, reszta OFF,
adres = 0x01,
port = RS485-1,
w aplikacji protokół 001. Repo syssi dla PB pokazuje właśnie adres 0x01 dla single-pack i ostrzega, żeby nie używać 0x00, bo to tryb master; instrukcja JK-PB potwierdza, że adresy ustawia się DIP-ami, a 0 służy do pracy równoległej jako master. (GitHub)
To jest wersja na rozruch komunikacji, nie pełny 1800-linijkowy kombajn z całego przykładu syssi. Podaj model ESP i konkretne GPIO, a złożę ci wersję 1:1 pod twoją płytkę.
Świetne streszczenie, jednak dokumentację radzę najpierw czytać samodzielnie.
YAML jest nadał zły tzn. nie pasuje do ledwo widocznego konwertera RS485 ze zdjęcia w 1 poście.
(@Andrzejzako skąd w ogóle pomysł, aby zamiast zdjęcia zapewne zrobionego telefonem, wstawić jego skrinszot z telefonu - to mi się w głowie nie mieści…)
Cudotwórcą nie jestem. Chat zadał takie pytanie na końcu : dasz płytkę zrobię YAML.
A zrobił tylko na podstawie co mu dałem.
A Tu na Forum często się przewija że wróżymy z kuli albo z fusów
Lol jestem pod wrażeniem twojej wiedzy
Moje esp
ESP32 30pin, WiFi, Bluetooth, USB-C, CH340. ESP-WROOM-32 DevKitC-v1
A co do AI to najpierw próbowałem z chatem gpt potem use AI czyli niby wszystkie w jednym a i tak okazuje się że do dupy
To nie moja wiedza tylko AI. Zadałem mu pytanie i tyle 
AI nie jest do dupy. To kwestia jak zadasz mu pytanie i co dostanie.
Jak mu przykładowo napiszesz : napisz mi kod = >On Ci napisze. Tylko jakość tego kodu będzie nijaka.
EDIT :
Dla Twojego zdania :
ESP32 30pin, WiFi, Bluetooth, USB-C, CH340. ESP-WROOM-32 DevKitC-v1
Sformułowałem pytanie : To Ci wystarczy?
GPT pomyślał 13 minut - efekt:
Tak. To wystarczy.
Dla ESP-WROOM-32 DevKitC-v1 dałbym na start taki minimalny, sensowny YAML pod JK-PB po RS485/Modbus. Oparłem go o oficjalny przykład PB z repo syssi: tam masz tx_pin: GPIO16, rx_pin: GPIO17, baud_rate: 115200, rx_buffer_size: 384, address 0x01 dla pojedynczego pakietu i command_throttle: 50ms. Manual JK-PB potwierdza też, że do komunikacji używasz RS485-1, a adres 0x00 jest trybem master do pracy równoległej, więc do zwykłego odczytu trzeba ustawić 0x01–0x0F. (GitHub)
substitutions:
name: jk-pb-bms
friendly_name: JK PB BMS
# ESP-WROOM-32 DevKitC-v1
tx_pin: GPIO16
rx_pin: GPIO17
de_re_pin: GPIO4
device_addr: "0x01"
esphome:
name: ${name}
friendly_name: ${friendly_name}
comment: "JK-PB via RS485 Modbus"
esp32:
board: esp32dev
framework:
type: esp-idf
external_components:
- source: github://syssi/esphome-jk-bms@main
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
logger:
level: DEBUG
api:
ota:
- platform: esphome
uart:
- id: uart_0
baud_rate: 115200
rx_buffer_size: 384
tx_pin: ${tx_pin}
rx_pin: ${rx_pin}
modbus:
- id: modbus0
uart_id: uart_0
flow_control_pin: ${de_re_pin}
modbus_controller:
- id: bms0
address: ${device_addr}
modbus_id: modbus0
setup_priority: -10
update_interval: 5s
command_throttle: 50ms
binary_sensor:
- platform: status
name: "${friendly_name} ESP status"
# z oficjalnego przykładu PB
- platform: modbus_controller
modbus_controller_id: bms0
name: "${friendly_name} charging float mode"
address: 0x1114
register_type: holding
bitmask: 0x0200
sensor:
# pomocniczy sensor żeby widzieć, że urządzenie żyje
- platform: uptime
name: "${friendly_name} uptime"
# z oficjalnego przykładu PB
- platform: modbus_controller
modbus_controller_id: bms0
name: "${friendly_name} smart sleep"
address: 0x1000
register_type: holding
value_type: U_DWORD
register_count: 4
response_size: 4
unit_of_measurement: "V"
device_class: voltage
state_class: measurement
accuracy_decimals: 3
filters:
- multiply: 0.001
Podłączenie zrób tak:
Przed odpaleniem ustaw:
Ten YAML jest celowo prosty: najpierw ma ruszyć komunikacja. Jak zacznie gadać, to wtedy dorzuca się pełen zestaw sensorów z pliku PB zamiast wrzucać od razu 1800 linii i zgadywać, gdzie się wywala.
Wrzuć potem log z bootu i z pierwszych odczytów.
to trzeba wywalić, bo nie pasuje do tego konwertera RS485 ze zdjęcia, na resztę nie mam czasu
nie wiem na jakie prędkości jest ten konwerter (bo ma układ auto-zmiany kierunku) ale mam obawy czy będzie działał przy 115200, to trzeba sprawdzić w jego dokumentacji (albo rypać się organoleptycznie beż żadnej gwarancji działania)
więc możliwe, że trzeba BMS skonfigurować do znacznie wolniejszej transmisji (no chyba, że ktokolwiek potwierdza działanie tego konwertera z taką prędkością, bo ja znam działający przypadek bodajże przy 9600 z oczywiście innym sprzętem, więc od takiej konfiguracji BMSa i YAMLa bym zaczął, jeśli będzie transmisja, to można próbować po kroczku szybciej)
edit 2 dni później w związku z innym wątkiem, gdzie jest używana bliźniacza konstrukcja tego konwertera UART-RS485
piny na zdjęciu są odwrotnie, więc albo je przelutować, albo zdefiniować inaczej (na krzyż), swoją drogą to nie jest domyśle położenie pinów UART1 (domyśle dla UART1 to Tx na 17 i Rx na 18, ale na MCU S3 można je przemapować w inne miejsce)
Napisałem że wróżenie z fusów.
Pokazałem również jak GPT pracuje z danymi jakie ma.
GPT już mi napisał że sam nie stwierdzi czy ten konkretny model ma auto-kierunek , czy to zwykły RS-485 i sterowanie z ESP.
Brak danych.
Stąd zaproponował taki kod oraz ewentualnie zmianę :
substitutions:
tx_pin: GPIO16
rx_pin: GPIO17
device_addr: "1"
uart:
- id: uart_0
baud_rate: 115200
rx_buffer_size: 384
tx_pin: ${tx_pin}
rx_pin: ${rx_pin}
modbus:
- id: modbus0
uart_id: uart_0
modbus_controller:
- id: bms0
address: ${device_addr}
modbus_id: modbus0
setup_priority: -10
update_interval: 5s
command_throttle: 50ms
Wtyczkę wpinasz do pierwszego rj45 potem masz can, rs232 i dwa porty do ktorych wlaśnie wpinasz a one służą do komunikacji między magazynami tylko i wyłącznie, poza tym muszisz w bms przez aplikację ustawić protokół komunikacji na 1 i lecisz z kodem
2 posty zostały podzielonye na nowy temat: Bezrzewodowe połączenie (Bluetooth) JK BSM z HA
