ESP32 pipsolar parsowanie QPIGS

Witam,
potrzebuję pomocy przy w zasadzie gotowym projekcie z github ( GitHub - syssi/esphome-pipsolar: ESPHome component to monitor and control a pipsolar inverter via RS232)

wszystko śmiga tylko problem z parsowaniem odpowiedzi na QPIGS

przekroczony czas raczej wynika z przekroczeniem czasu biblioteki pipsolar a nie odczytem z portu który wygląda poprawnie.

Sending polling command : QPIGS with length 5 17:59:04 [D] [uart_debug:114] >>> 51:50:49:47:53:B7:A9:0D 17:59:05 [D] [uart_debug:114] <<< 28:32:31:37:2E:31:20:35:30:2E:30:20:32:31:37:2E:31:20:35:30:2E:30:20:30:31:39:35:20:30:31:38:31:20:30:30:33:20:32:39:39:20:30:30:2E:34:30:20:30:30:30:20:30:30:30:20:30:30:32:30:20:30:30:2E:30:20:30:30:30:2E:30:20:30:30:2E:30:30:20:30:30:30:30:30:20:30:30:30:31:30:30:30:30:20:30:30:20:30:30:20:30:30:30:30:30:20:30:31:30:20:30:20:30:31:20:30:30:30:30:44:E3:0D 17:59:05 [VV ][scheduler:226] Running interval ‘update’ with interval=1000 last_execution=5664057 (now=5665057) 17:59:06 [VV ][scheduler:226] Running interval ‘update’ with interval=1000 last_execution=5665057 (now=5666061) 17:59:07 [VV ][scheduler:226] Running interval ‘update’ with interval=1000 last_execution=5666057 (now=5667057) 17:59:08 [VV ][scheduler:226] Running interval ‘update’ with interval=1000 last_execution=5667057 (now=5668062) 17:59:09 [VV ][scheduler:226] Running interval ‘’ with interval=10000 last_execution=5658901 (now=5668901) 17:59:09 [VV ][scheduler:226] Running interval ‘update’ with interval=1000 last_execution=5668057 (now=5669057) 17:59:09 [D] [pipsolar:759] timeout command to poll: QPIGS 17:59:09 [D] [pipsolar:842]

Analiza QPIGS

(217.1 50.0 217.1 50.0 0195 0181 003 299 00.40 000 000 0020 00.0 000.0 00.00 00000 01 0 01 0000D)

Podział na pola (przykład):

  1. Grid voltage: 217.1
  2. Grid frequency: 50.0
  3. AC output voltage: 217.1
  4. AC output frequency: 50.0
  5. AC output apparent power: 0195
  6. AC output active power: 0181
  7. Output load percent: 003
  8. Bus voltage: 299
  9. Battery voltage: 00.40
  10. Battery charging current: 000
  11. Battery capacity: 000
  12. Inverter heat sink temperature: 0020
  13. PV input current: 00.0
  14. PV input voltage: 000.0
  15. SCC battery voltage: 00.00
  16. Battery discharge current: 00000
  17. Flags (b7b6b5b4b3b2b1b0): 01 0 01
  18. Extra: 0000D

Jak to mogę naprawić?

Nie wiem czy mnie oczy nie mylą, odpytujesz co sekundę?
(przez taki czas przy prędkości 2400bps daje się przepchnąć przez port zaledwie 300 bajtów)

jakby co to jest to ten komponent

ale odpowiedź wygląda prawidłowo :upside_down_face:

Prędkość wpisałem z dokumentacji

Nie mogę pobrać tego z GitHuba nie widzę opcji

Pytałem czy odpytujesz co sekundę…
Jeśli tak, to odpytuj co 10 sekund albo co minutę (nie wiem co potrafi ten sterownik falownika) i zobacz czy to zmienia sytuację.

A co chcesz pobierać? to jest wbudowany komponent ESPHome,
jeśli chcesz się dowiedzieć coś od kogoś, kto ma podobny sprzęt, to pokop po issues (również zamknietych) na repo, na które się powołujesz, może przy okazji zrozumiesz co robisz źle pokazując tylko jakieś wyrwane logi bez kontekstu.

czas odpowiedzi miałem co 5s przy 2400 i bez zmian
co do samej dopowiedzi z falownika jes ona poprawna tylko chyba problem leży na przetworzeniu jej.

Mogę podać więcej informacji jeśli powiesz co jeszcze potrzeba?
W logu jest jakie polecenie wyszło, że dotarło i uzyskało odpowiedź zgodną z szablonem a mimo wszystko na tym etapie poległo. Jak dla mnie to problem nie jest na etapie pobrania odpowiedzi czy przejścia miedzy systemami a już samym podziałem odpowiedzi na paczki ich przypisaniem do konkretnej zmiennej.

Rozumiem że to wszystko przeczytałeś.

Known issues

Jeśli skonfigurujesz wiele możliwych czujników itp., może się okazać, że zabraknie Ci pamięci (w esp32). Jeśli skonfigurujesz prawie wszystkie czujniki itp., napotkasz problem z rozmiarem stosu. W takim przypadku musisz zwiększyć rozmiar stosu.

Debugging

Jeżeli ten komponent nie działa od razu w Twoim urządzeniu, zaktualizuj konfigurację, aby włączyć wyjście debugowania komponentu UART i zwiększ poziom rejestrowania, aby zobaczyć ruch szeregowy przychodzący i wychodzący.

logger:
  level: DEBUG
  # Don't write log messages to UART0 (GPIO1/GPIO3) if the inverter is connected to GPIO1/GPIO3
  baud_rate: 0

uart:
  id: uart_0
  baud_rate: 2400
  tx_pin: ${tx_pin}
  rx_pin: ${rx_pin}
  debug:
    direction: BOTH
    dummy_receiver: false
    after:
      delimiter: "\r"
    sequence:
      - lambda: UARTDebug::log_string(direction, bytes);

Tak to były jedne z pierwszych kwestia jakie zostały poruszone w walce z problemem.

Nie wiem czy jest sens pisać komunikację od zera bez tej biblioteki jest to dziwne inne polecenia działają a tu wygląda jakby dostał odpowiedź niezgodną z szablonem i nie potrafił jej podzielić choć patrząc po dokumentacji wszystko się zgadza począwszy od serca aż po dane jakie pobiera

Prawdopodobnie rozwiązanie problemu jest banalne ale poza zakresem mojego wzroku

Dodatkowo zwiększyłem pamięć buforu JSON na 1024 oraz RX bufor na 256

Olałem bibliotekę i napisałem sobie komunikacje od nowa
Temat nieaktualny