Konwerter USB-RS485 (który? FT232RL vs CH340) poprawne działanie i błędy w logach

Cześć.

Szukam dobrego rozwiązania do sieci RS485. W tak owej obecnie falownik Growatta, regulator grzałek CWU oraz miernik EASTRON SDM630.

Testowo odpytuję tylko miernik SDM630 (oddzielny wątek jest tutaj: RS485: Energia + Growatt + Eastron SDM630 Modbus V2) ale nadszedł czas by rozwiązać zagadkę która pojawia się w logach.

Otóż widzę w nich takie oto zapisy:

Logger: homeassistant.components.modbus.modbus
Source: components/modbus/modbus.py:291
Integration: Modbus (documentation, issues)
First occurred: 20:59:53 (2 occurrences)
Last logged: 20:59:54

Pymodbus: rs485_rtu: Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response

Logger: homeassistant.components.modbus.validators
Source: components/modbus/validators.py:84
Integration: Modbus (documentation, issues)
First occurred: 20:59:49 (36 occurrences)
Last logged: 20:59:49

SDM630 L2 export kWh with float is not valid, trying to convert
SDM630 L3 export kWh with float is not valid, trying to convert
SDM630 L1 total kWh with float is not valid, trying to convert
SDM630 L2 total kWh with float is not valid, trying to convert
SDM630 L3 total kWh with float is not valid, trying to convert

Logger: pymodbus.client.sync
Source: /usr/local/lib/python3.9/site-packages/pymodbus/client/sync.py:707
First occurred: 20:59:52 (10 occurrences)
Last logged: 21:01:21

Cleanup recv buffer before send: 0xff

i nic nie przychodzi mi do głowy co mógłbym zrobić aby ten problem rozwiązać. Kombinowałem z konfiguracją i finalnie zostałem przy takiej:

modbus:

- name: rs485_rtu
  type: serial
  method: rtu
  port: /dev/ttyUSB1
  baudrate: 38400
  # baudrate: 19200
  # baudrate: 9600
  # baudrate: 4800
  # baudrate: 2400
  bytesize: 8
  parity: N
  # Error Check Field: 2 byte Cyclical Redundancy Check (CRC)
  # Framing: 1 start bit
  # 8 data bits, least significant bit sent first
  # 1 bit for even/odd parity (or no parity)
  # 1 stop bit if parity is used; 1 or 2 bits if no parity
  stopbits: 2

Zatem pomyślałem, że jeżeli kupiłem najtańszy konwerter USB-RS485 to może w nim tkwi problem?

Posiadam coś takiego co jest sprzedawane jako " Konwerter USB - RS485 CH340 Modbus Profibus PLC" i w popularnym pomarańczowym serwisie kosztuje jakieś 7,80 zł
image

Droższa wersja posiada dodatkowo rezystor równoważący 120R i jest sprzedawana pod nazwą “Konwerter przemysłowy USB - RS485 FT232”. Wygląda tak:
image

Jest też oczywiście wersja sieciowa którą można wpiąć w dowolnym miejscu sieci LAN " Konwerter RS485 na Ethernet Converter" ale trzeba ją dodatkowo zasilić 5V:
image

Już po samym wyglądzie można przypuszczać, że urządzenia marki Waveshare są po prostu lepsze. No ale czy napewno? I to pytaniem kieruję właśnie do Was.

PYTANIA:

  1. Czy odpytujecie u siebie urządzenia po RS485? Jeżeli tak to jaki macie do tego konwerter?

  2. A może to nie w sprzęcie problem lecz w konfiguracji?

  3. Może problem tkwi w braku rezystora 120 Ohm w tym moim tanim chińskim wynalazku?

[Wejście/Wyjście] Brak odpowiedzi z jednostki zdalnej/Nie można zdekodować odpowiedzi czyli problem z komunikacją po RS485.

Mam taki sam konwerter, na razie testuję moduł rozszerzeń MR-DIO-1 firmy F&F, wszystko działa poprawnie. Kolejny w kolejce czeka licznik SDM630. Docelowo jednak jako konwerter Modbus na etnernet będzie moduł firmy ZLAN albo USR montowany na szynie DIN.

Coś dziwnie wygląda ta Twoja konfiguracja, może popraw formatowanie tekstu w poście bo teraz to jakiś misz-masz.

@bielen2k
Nie wklejaj jakiegokolwiek kodu jako cytowania - to powoduje taki bałagan jak widać u góry
zamiast tego użyj linijki tylko z ``` (to 3 apostrofy odwrotne spod “klawisza tyldy”) wrzuconej przed oraz po fragmencie kodu/konfiguracji - wtedy to mogłoby wyglądać tak (wydaje się że przykleiłeś windowsowy plik w linuxie lub odwrotnie, bo pustych linii od groma):

modbus:

- name: rs485_rtu

  type: serial

  method: rtu

  port: /dev/ttyUSB1

  baudrate: 38400

  # baudrate: 19200

  # baudrate: 9600

  # baudrate: 4800

  # baudrate: 2400

  bytesize: 8

  parity: N

  # Error Check Field: 2 byte Cyclical Redundancy Check (CRC)

  # Framing: 1 start bit

  # 8 data bits, least significant bit sent first

  # 1 bit for even/odd parity (or no parity)

  # 1 stop bit if parity is used; 1 or 2 bits if no parity

  stopbits: 2

Podejrzewam że problem leży po stronie tego adaptera USB-RS485.

@macek
Jak podepniesz SDM630 to daj znać czy przy losowych encjach masz zamiast danych napis “niedostępna”. Mimo zadbania o maksymalną ilość odczytów z SDM630 to co kilka minut taki zapis się pojawia.

@macek @szopen dzięki za zwrócenie uwagi, formatowanie zostało poprawione (przyczyną było to , że markdown odczytał znak “#” jako BOLD :slight_smile: )

Proszę podaj całą konfigurację tego sensora, Twoje logi są podobne do tych z tego problemu EPever Modbus RTU - #11 by chukaonline - Configuration - Home Assistant Community - spróbuj dodać:

data_type: float32

Zakładam, że ten sensor ma “przecinek” w wyniku.

U mnie z tym chińskim na CH340 były problemy… zmieniłem na taki na: FT232RL i śmiga. Nie polecam tych CH340, cena mówi sama za siebie :stuck_out_tongue:

@dar3k
a masz wersję USB czy sieciową ETH?

USB, ale ja mam USB-232-IND, USB-422-IND, USB-485-IND, USB-422-485-IND - ACCES I/O Products taki konwerter.

@macek Zmiana typu danych na float32 jak najbardziej pomogła. Od 2 dni w/w komunikat w logach nie występuje.

@dar3k zamówiłem konwerter USB-RS485 oparty o FT232RL. Dam znać jak się sprawuje.

U mnie z tym chińskim na ch340 był problem taki, że Ubuntu chyba go źle rozpoznawał, tak jakby kernel go w 100% nie wspierał. Z samego Ubuntu działał dobrze, ale już udostępniony do VM nie.
Ja mam HA na wirtualnej maszynie postawiony, właśnie na tym Ubuntu i udostępniłem do niej ten port ale nie dało się jako USB tylko widział to jako RS i nie chciało działać, na tej opartej na FT śmiga, rozpoznaje normalnie jak powinien, udostępnia dla VM port USB i HA widzi go jako /dev/ttyUSB.
Ale co ciekawe porobiłem testy to o wiele stabilniej działa modbus po TCP w HA (nawet jak masz finalnie RS to lepiej będzie działać przez konwerter TCP <> RS485 niż po samym RS485), jak chodzi po RS to w logach jest dużo wpisów o błędach komunikacji, jak leci przez TCP (przez mbusd na Ubuntu GitHub - 3cky/mbusd: Open-source Modbus TCP to Modbus RTU (RS-232/485) gateway.), to tych wpisów nie ma (również w logach mbusd nie ma błędów) i wrażenie mam, że płynniej to działa, chociaż daleko do płynności działania urządzeniu co ma 9600 prękdość transmisji (1KB/s) w dzisiejszych czasach :wink:

Robiłeś testy na większych prędkościach, np. 19200, 38400, 57600, 115200 B/s? Zaznaczam, że ramka Modbus może mieć max 256 bajtów więc przy takim poziomie danych naprawdę nie są potrzebne ogromne prędkości.

Niestety nie bo nie mam jak przełączyć urządzenia na wyższą prędkość.,
Ramka ramką ale między każdym pytaniem a odpowiedzią musi być przerwa w komunikacji, przez co jak pytasz o kilka ramek jedna za drugą robią się opóźnienia, które widać niestety na wizualizacji. Ale w moim przypadku nie przeskoczę tego i tak optymalizuję aby najpotrzebniejsze rzeczy pytać co 1s a resztę w większych odstępach czasu.

@macek @dar3k mam do Was pytanie dotyczące prędkości RS485. Licznik Eastron SDM630 może o ile dobrze pamiętam wysłać na raz 40 odczytów/wartości(?). I jak się to ma do prędkości? Nie potrzebuję odczytywać co sekundę tych parametrów. Mam ustawione różne czasy dla różnych grup (np napięcie co 30 sekund, prąd co 59 sekund itd). Ustawiałem tak aby nie zazębiały się te odczyty ale bez wchodzenia w szczegóły. Tzn na oko dałem jakieś wartości w sekundach.

Wracając do sedna. Protokół RS485 jest dla mnie nowością więc jak wygląda zachowanie takiego licznika gdy np w jednej sekundzie będę chciał odpytać go o 50 różnych wartości (jego limit to 40). Czy wówczas w jednej ramce leci te 40 wartości czy może jednak leci 40 ramek? Co z pozostałymi 10 (pytałem go o 50 ale jego limit to 40) No i jak to zapytanie ma się do prędkości 9600 bit vs 38400 bit/s?

To już zależy jak jest to po stronie licznika rozwiązane, czasem robi się stos i opóźnienie odpowiedzi, czasem jest ignorowana komunikacja i zwracany błąd (to częściej bo procesor obrobić się nie może). W RS485 prędkość też zależna jest od procesora w urządzeniu i jak on nie obsługuje wyższej to jej nie można zmienić. Czasem się nie zaleca bo wyższa prędkość go za bardzo obciąża w obliczeniach itd. Jak nie ma dokumentacji mówiącej co można a co nie to niestety zostaje testować i metodą prób i błędów wybrać najlepsze rozwiązanie.
Ja tak samo zrobiłem z odczytem parametrów, czytam w różnych okresach tak aby się “nie spotykały” zbyt często.

Proponuje poczytać ten artykuł - https://ntronic.pl/jak-dziala-modbus/ - w miarę prosto i technicznie to tłumaczy.

Z dokumentacji SDM630:
“SDM630 może przesłać maksymalnie 40 wartości w jednej transakcji; dlatego maksymalna liczba wymaganych rejestrów wynosi 80. Przekroczenie tego limitu powoduje, że SDM630 generuje odpowiedź wyjątku.”
ale w konfiguracji HA jak tworzysz sensory to z reguły pytasz tylko o jeden rejestr (adres) a nie o kilka rejestrów (podaje się adres rejestru początkowego i ilość rejestrów do odczytania - to realizuje funkcja #03h - odczyt rejestrów) więc nie przekraczasz tej wartości. Ograniczenie jest w postaci wielkośc ramki a nie ilości tych ramek.

Poleci 50 ramek.

W skrócie, upraszczając: 9600 b/s = 1200 bajtów/s (1 bajt to 8 bitów), jedna ramka Modbus to minimum 5 bajtów czyli w ciągu 1s można przesłać 240 ramek, na każdą wysłaną ramkę z mastera dostajesz jedną ramkę odpowiedzi ze slave więc w ciągu 1s można wysłać i otrzymać 120 informacji. Zwiększając prędkość zwiększamy “przepustowość” wymiany danych - więcej danych możemy wysłać i szybciej je otrzymamy.
Modbus jest protokołem asynchronicznym tzn. wysyłasz zapytanie o dane i czekasz na odpowiedź, potem wysyłasz i czekasz na odpowiedź, nie możesz do wszystkich slave wysłać zapytania i czekać na ich odpowiedzi.

2 polubienia

Dzięki za obszerne wyjaśnienie. Doczytam jeszcze o modbusie by lepiej go zrozumieć.

A teraz pochwalę się, że PROBLEM ZOSTAŁ ROZWIĄZANY :slight_smile:

W skrócie:

  • zamówiłem konwerter Waveshare USB to RS485" (54 zł z dobrym przedłużaczem USB oraz śrubokręcikiem w zestawie :slight_smile: )
  • wywaliłem ten tani (kosztował jakieś 7 zł)

Wszystko zaczęło działać poprawnie. W logach od 3 godzin czysto a sensory nawet mimo zmiany częstotliwości odpytywania co 5 sekund ani razu jeszcze nie pokazały statusu “niedostępny”.

Dodatkowo dokonałem kilku małych zmian z tego względu że po RS485 chcę podłączyć inverter PV.
EASTRON SDM630 przestawiłem na “slave 2” (czyli adres to 002) oraz zmieniłem prędkosć na 9600 bit/s. Falownik Growatta bedzie pod “slave 1” a on też działa na 9600. Poza tym bity stopu również przestawiłem z 2 na 1 bo inwerter chyba tylko taką opcję przyjmuje.

Obecnie wygląda to tak:

modbus:
- name: rs485_rtu
  type: serial
  method: rtu
  port: /dev/ttyUSB1
  baudrate: 9600
  bytesize: 8
  parity: N
  stopbits: 1
  sensors: !include modbus_sensor.yaml

I przykładowy sensor:

- name: SDM630 L1 Power
  address: 12
  unit_of_measurement: W
  slave: 2
  input_type: input
  count: 2
  data_type: float32
  precision: 0
  scan_interval: 5
  device_class: power

A co do konwerterów to ten trzeci z pierwszego postu (RS485 to ETH) niestety nie obsługuje modbus. Konwertery działające po LAN/WiFi to kwota rzędu 150-200 zł. Ponieważ mam dociągniętą dedykowaną pod RS485 skrętkę do serwera to zostałem przy opcji na USB.

Dzięki wszystkim za zaangażowanie i pomoc w tym temacie!

To jest oczywiste, w dokumentancji http://www.waveshare.com/wiki/RS485_TO_ETH jest to napisane.

Docelowo takie coś napewno pojawi się u mnie na szynie DIN (np. https://www.pusr.com/products/din-rail-rs485-serial-to-ethernet-converter-usr-dr302.html), na potrzeby testów te tanie z ali za 6 zł są wystarczające, mam ich kilka.

Możesz też spróbować zrobić taki samemu na esp32 → GitHub - harihanv/esp32-modbus-gateway: esp32 port of modbus RTU to TCP Arduino gateway

2 polubienia