No to pytaj osoby od której kopiujesz IDENTYCZNĄ konfigurację jakim cudem to nie pasuje do twojego sprzętu.
Może nie bierzesz pod uwagę, że np. ten sam model falownika nie oznacza identyczności 2 różnych egzemplarzy (bo np. różnią się firmware lub po prostu konfiguracją)?
dokładnie na tym się wzorowałem i tu gość nie ma takich problemów z odpaleniem tego jakie się pojawiają u mnie, dlatego nie wiem co jest grane
nawet kompilacji na płytkę nie musiał robić tak jak ja tylko normalnie poprzez USB laptopa
@hazibi jeśli ktoś miał by pomóc to przydały by się konkrety m.in.
A tak wogule to polecam Solar assistant
Połaczyć przez MQTT do HA i działa bez problemu.
Nie sądzę żeby komuś się chciało ogladać filmik (przynajmniej tyle że ma 13 minut)
Ale Ty nie masz problemów z odpaleniem - to działa, a tylko częściowo nie pasuje do mapy rejestrów twojego falownika.
Chociaż przepuść swoje logi przez AI i idę o zakład, że dostaniesz jakieś wskazówki na co zwrócić uwagę i jak to dostosować (jak dasz AI-kowi też YAMLa).
Oczywiście nie będę oglądał wideo, ale może nie rozumiesz, że gość który je nakręcił najpierw usiadł do mapy rejestrów swojego falownika (i tego jak zakładam nie ma w filmiku, bo i po co - gdyby filmik trwał 3 tygodnie, to byś go nie obejrzał).
Solar Assistant ma swoje ograniczenia dlatego bezpośrednie czytanie danych jest lepsze, zgłębiałem ten temat, poza tym nie chodzi o samo czytanie ale o późniejsze automatyzacje
Znam rejestry falownika i mój falownik jest też identyczny,
problem nie leży w rejestrach ale w jakimś konflikcie z Modbusem ale znam się na tym na tyle miernie że sam sobie z tym nie poradzę dlatego pytałem mądrzejszych, przedstawiając z czym jest problem i pokazując przykłady
Dobra wrzucę to w AI
[13:55:39.634][W][modbus_controller:307]: Duplicate modbus command found: type=0x3 address=108 count=2
[13:55:39.634][W][modbus_controller:307]: Duplicate modbus command found: type=0x3 address=201 count=17
[13:55:39.634][W][modbus_controller:307]: Duplicate modbus command found: type=0x3 address=219 count=2
[13:55:39.637][W][modbus_controller:307]: Duplicate modbus command found: type=0x3 address=223 count=5
[13:55:39.637][W][modbus_controller:307]: Duplicate modbus command found: type=0x3 address=229 count=1
[13:55:39.638][W][modbus_controller:307]: Duplicate modbus command found: type=0x3 address=232 count=3
[13:55:39.638][W][modbus_controller:307]: Duplicate modbus command found: type=0x3 address=300 count=4
[13:55:39.643][W][modbus_controller:307]: Duplicate modbus command found: type=0x3 address=305 count=6
Te ostrzeżenia w logach
ESPHome oznaczają, że Twoja konfiguracja definiuje odczyt tych samych rejestrów Modbus w więcej niż jednym miejscu. Kontroler wykrywa te duplikaty i automatycznie je pomija, aby nie przeciążać szyny niepotrzebnymi zapytaniami.
Dlaczego to widzisz?
- Nakładające się sensory: Masz dwa sensory (np.
sensoritext_sensor), które odwołują się do tego samegoaddress.- Zakresy (count): Jeden sensor czyta np. 10 rejestrów zaczynając od adresu 201, a inny sensor czyta pojedynczy rejestr pod adresem 210. ESPHome widzi to jako zdublowane zapytanie o ten sam fragment pamięci.
Jak to naprawić?
- Przejrzyj sekcję
modbus_controllerw swoim pliku YAML.- Znajdź sensory o adresach wymienionych w logach (np. 108, 201, 219).
- Upewnij się, że każdy fizyczny rejestr jest zdefiniowany tylko raz.
- Jeśli potrzebujesz tej samej wartości w dwóch różnych formatach, użyj template sensor, zamiast definiować drugi sensor Modbus dla tego samego adresu.
[13:55:39.662][W][modbus:064]: Stop waiting for response from 1 227ms after last send
[13:55:39.887][W][modbus:064]: Stop waiting for response from 1 220ms after last send
[13:56:12.367][W][modbus:064]: Stop waiting for response from 1 220ms after last send
Te nowe logi (
Stop waiting for response) potwierdzają problem z komunikacją fizyczną lub zbyt ciasnym czasem oczekiwania. ESPHome wysyła zapytanie, ale urządzenie (Slave o ID 1) nie odpowiada w wyznaczonym czasie (~220-227 ms).Dlaczego to się dzieje?
- Zbyt krótki timeout: Domyślny czas oczekiwania w ESPHome to 250 ms. Niektóre urządzenia potrzebują więcej czasu na przetworzenie zapytania i wysłanie odpowiedzi.
- Przeciążenie szyny: Poprzednie błędy o duplikatach sugerują, że ESPHome próbuje wysłać zbyt wiele zapytań jedno po drugim. Urządzenie Slave może nie nadążać z ich obsługą.
- Błędy CRC / Zakłócenia: Jeśli urządzenie wysyła błędną odpowiedź (np. przez zakłócenia na kablach RS485), ESPHome może ją odrzucić i raportować timeout.
- Brak rezystorów terminujących: Przy dłuższych przewodach brak rezystora 120 Ω na końcach linii powoduje odbicia sygnału i błędy komunikacji.
tu ominąłem sugerowane zmiany w konfiguracji (bo nie wierzę do końca AI, nie mam takiego falownika i nie mogę tego testować, a Ty nie wiem czemu zakładasz, że cudzy YAML musi pasować bez dostosowania)
Kroki diagnostyczne:
- Zwiększ
send_wait_time: To najczęstsze rozwiązanie dla wolniejszych liczników energii czy inwerterów.- Sprawdź kable: Upewnij się, że przewody A i B nie są zamienione oraz czy ekran kabla jest uziemiony (tylko z jednej strony).
- Dodaj terminację: Jeśli masz długi kabel, załóż rezystor 120 Ω między liniami A i B przy ostatnim urządzeniu.
moje prywatne spostrzeżenie - czy ustawiłeś sobie prędkość transmisji na falowniku na jakąś rozsądną wartość tak jak sugerowałem wczoraj?
bo
to jest naprawdę mało (nie wiem ile potrafi ten falownik, ale ESP ze sprzętowym UARTem poradzi sobie ze znacznie większymi szybkościami)
[13:59:18.230][E][modbus_controller.select:035]: No option found for mapping 4
[13:59:28.270][E][modbus_controller.select:035]: No option found for mapping 4
[13:59:38.268][E][modbus_controller.select:035]: No option found for mapping 4
[13:59:48.273][E][modbus_controller.select:035]: No option found for mapping 4
[13:59:58.268][E][modbus_controller.select:035]: No option found for mapping 4
[14:00:08.268][E][modbus_controller.select:035]: No option found for mapping 4
[14:00:18.268][E][modbus_controller.select:035]: No option found for mapping 4
[14:00:28.267][E][modbus_controller.select:035]: No option found for mapping 4
[14:00:38.268][E][modbus_controller.select:035]: No option found for mapping 4
[14:00:48.266][E][modbus_controller.select:035]: No option found for mapping 4
[14:00:58.266][E][modbus_controller.select:035]: No option found for mapping 4
[14:01:08.308][E][modbus_controller.select:035]: No option found for mapping 4
[14:01:18.314][E][modbus_controller.select:035]: No option found for mapping 4
Ten błąd (
No option found for mapping 4) oznacza, że Twój komponentselectodczytał z urządzenia wartość 4, ale w konfiguracji YAML nie zdefiniowałeś, co ta czwórka oznacza.ESPHome widzi wartość w rejestrze Modbus, ale nie wie, którą pozycję z listy rozwijanej (menu) ma wyświetlić w Home Assistancie.
Jak to naprawić?
Musisz dodać brakujące mapowanie w sekcji
selectswojego pliku YAML. Prawdopodobnie Twoja listaoptionsjest za krótka lub brakuje w niej indeksu 4.Przykład poprawnej konfiguracji:
tu słowo mojego komentarza - to jest tylko przykład wygenerowany przez AI i on nie ma nic wspólnego z twoją konfiguracją, u siebie musisz znaleźć czego to dotyczy i poprawić samodzielnie (czyli żadnego kopiowania jeden do jednego!!!)
select:
- platform: modbus_controller
name: "Tryb Pracy"
address: 100 # przykładowy adres
options:
0: "Wyłączony"
1: "Auto"
2: "Ręczny"
3: "Eco"
4: "TUTAJ WPISZ NAZWĘ DLA WARTOŚCI 4" # Tego brakuje!
Co sprawdzić?
- Dokumentacja urządzenia: Sprawdź w instrukcji (np. inwertera czy pompy ciepła), co oznacza wartość 4 dla tego konkretnego rejestru.
- Kolejność w YAML: Upewnij się, że w sekcji
optionsmasz zdefiniowane mapowanie dla cyfry 4.- Liczba opcji: Jeśli używasz listy bez numerów (same nazwy), ESPHome przypisuje im numery od 0 wzwyż. Jeśli masz tylko 4 nazwy (indeksy 0, 1, 2, 3), a urządzenie zwraca 4, dostaniesz ten błąd.
Poza konkurencją - z nieznanego mi powodu płytka się w międzyczasie zrestartowała (może było za dużo błędów i jej RAMu brakło?, może problem z zasilaniem itd., no mnie tam nie było, to nie wiem jaka mogła być fizyczna przyczyna - może nawet uszkodzony kabelek USB? a może jeszcze coś innego łącznie z celowym odłączeniem zasilania na chwilę)
INFO Processing unexpected disconnect from ESPHome API for anenji-1 @ 192.168.0.113
WARNING Disconnected from API
INFO Successfully resolved anenji-1 @ 192.168.0.113 in 0.001s
WARNING Can't connect to ESPHome API for anenji-1 @ 192.168.0.113: Error connecting to [AddrInfo(family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, proto=6, sockaddr=IPv4Sockaddr(address='192.168.0.113', port=6053))]: [Errno 113] Connect call failed ('192.168.0.113', 6053) (SocketAPIError)
INFO Trying to connect to anenji-1 @ 192.168.0.113 in the background
INFO Successfully connected to anenji-1 @ 192.168.0.113 in 0.004s
INFO Successful handshake with anenji-1 @ 192.168.0.113 in 0.012s
…
[13:59:15.803][I][safe_mode:091]: Boot seems successful; resetting boot loop counter
pod tym filmikiem jest też plik yamla którego w całości nie mogłem tu zamieścić bo jest za duży
przejrzałem te adresy do których są uwagi w logach i pierwszy z nich 108 wygląda tak:
# Warning code ULong 108 2 R
- platform: modbus_controller
modbus_controller_id: smg0
name: "${name} warning"
address: 108
register_type: holding
register_count: 2
response_size: 4
raw_encode: HEXBYTES
icon: mdi:alert-circle
lambda: |-
static const uint8_t WARNINGS_SIZE = 19;
static const char *const WARNINGS[WARNINGS_SIZE] = {
"Reserve (Bit 0)", // 0000 0000 0000 0000 0000 0000 0000 0001 (1)
"Mains waveform abnormal", // 0000 0000 0000 0000 0000 0000 0000 0010 (2)
"Reserve (Bit 2)", // 0000 0000 0000 0000 0000 0000 0000 0100 (3)
"Mains low voltage", // 0000 0000 0000 0000 0000 0000 0000 1000 (4)
"Mains over frequency", // 0000 0000 0000 0000 0000 0000 0001 0000 (5)
"Mains low frequency", // 0000 0000 0000 0000 0000 0000 0010 0000 (6)
"PV low voltage", // 0000 0000 0000 0000 0000 0000 0100 0000 (7)
"Over temperature", // 0000 0000 0000 0000 0000 0000 1000 0000 (8)
"Battery low voltage", // 0000 0000 0000 0000 0000 0001 0000 0000 (9)
"Battery is not connected", // 0000 0000 0000 0000 0000 0010 0000 0000 (10)
"Overload", // 0000 0000 0000 0000 0000 0100 0000 0000 (11)
"Battery Eq charging", // 0000 0000 0000 0000 0000 1000 0000 0000 (12)
"Battery undervoltage", // 0000 0000 0000 0000 0001 0000 0000 0000 (13)
"Output power derating", // 0000 0000 0000 0000 0010 0000 0000 0000 (14)
"Fan blocked", // 0000 0000 0000 0000 0100 0000 0000 0000 (15)
"PV energy is too low to be use", // 0000 0000 0000 0000 1000 0000 0000 0000 (16)
"Parallel communication interrupted", // 0000 0000 0000 0001 0000 0000 0000 0000 (17)
"Output mode of Single and Parallel systems inconsistent", // 0000 0000 0000 0010 0000 0000 0000 0000 (18)
"Battery voltage difference of parallel system is too large", // 0000 0000 0000 0100 0000 0000 0000 0000 (19)
};
std::string values = "";
uint32_t mask = modbus_controller::dword_from_hex_str(x, 0);
if (mask) {
for (int i = 0; i < WARNINGS_SIZE; i++) {
if (mask & (1 << i)) {
values.append(WARNINGS[i]);
values.append(";");
}
}
if (!values.empty()) {
values.pop_back();
}
}
return values;
Na szybko wrzucone w AI:
Logi, które widzisz, to ostrzeżenia (Warning) komponentu modbus_controller w ESPHome. Nie są to błędy krytyczne, które zatrzymują działanie programu, ale informują o nieoptymalnej konfiguracji.
Co to oznacza? Komunikat “Duplicate modbus command found” oznacza, że ESPHome wykrył wiele encji (sensorów, przełączników itp.), które odpytują ten sam rejestr Modbus lub zakres rejestrów w tym samym czasie. Modbus Controller w ESPHome stara się automatycznie grupować zapytania, aby zamiast wysyłać 10 osobnych pytań o 10 rejestrów, wysłać jedno zapytanie o zakres 10 rejestrów. Jeśli Twoja konfiguracja ma “nakładające się” definicje, kontroler ostrzega, że tworzy zduplikowane kolejki odczytu.
Gdzie leży problem w Twoim kodzie? Głównym powodem są zduplikowane adresy lub nakładające się definicje sensorów. Oto konkretne przykłady z Twojego pliku:
- Bateria (Adres 232 i okolice):
- Masz zdefiniowany sensor battery average current2 na adresie 232.
- Zdefiniowałeś też sensory na adresach 233 i 234.
- W tym samym czasie kontroler prawdopodobnie próbuje czytać większy blok danych (zaczynając od adresu 201), co powoduje nakładanie się zapytań.
- Sekcja Number i Select (Adresy 300+):
- W sekcji select masz encje dla adresów 300, 301, 302, 303, 305.
- W sekcji switch masz encje dla adresów 306, 307…
- ESPHome próbuje utworzyć “batch” (grupę) do odczytu tych ustawień, ale ponieważ są to różne typy encji (select vs switch vs number), a odwołują się do ciągłego bloku pamięci, dochodzi do duplikacji komend w kolejce.
- Błędy i Ostrzeżenia (108, 201):
- Adres 108 (Warning code) ma register_count: 2. Jeśli inny sensor zaczyna się np. na 109, następuje kolizja.
- Adres 201 (Operation Mode) jest początkiem długiej listy sensorów (202, 203, 204…). ESPHome tworzy zapytanie zbiorcze, a potem widzi osobne zapytanie dla sensora 201 i zgłasza duplikat.
Jak to naprawić? Choć logi wyglądają groźnie, urządzenie prawdopodobnie działa. Aby się ich pozbyć i zoptymalizować komunikację, możesz zrobić dwie rzeczy:
- Ustaw force_new_range (Najszybsza metoda): Jeśli konkretny sensor powoduje problemy, możesz dodać do niego force_new_range: true. To powie ESPHome, żeby nie próbował łączyć tego odczytu z innymi.
- Dostosuj update_interval: Upewnij się, że sensory, które są blisko siebie w rejestrach, mają taki sam update_interval (u Ciebie większość dziedziczy 10s z kontrolera, co jest dobre, ale warto to sprawdzić przy encjach typu number czy select).
- Sprawdź czy nie masz fizycznych duplikatów: Przeszukaj plik pod kątem powtarzających się adresów. Na przykład:
- Masz sensor battery average current na adresie 216.
- Masz sensor battery average current2 na adresie 232. To są dwa różne rejestry, więc tu jest OK, ale jeśli np. w sekcji sensor i number użyjesz tego samego adresu, system zgłosi duplikat.
Podsumowując: Możesz zignorować te ostrzeżenia, jeśli dane w Home Assistant odświeżają się poprawnie. Jeśli jednak komunikacja z falownikiem “haczy” lub jest wolna, spróbuj pogrupować sensory w bloki lub użyć wspomnianego force_new_range: true przy sensorach wymienionych w logu (108, 201, 219, 223…).
Skoro już lecimy tym AI, to wrzuciłem też YAMLa (zakłądam, że skopiowałeś żywcem z gdrive autora filmiku)
- Naprawa “No option found for mapping 4”
Prawdopodobnie używasz pełnego projektu
syssi, a wkleiłeś tylko fragment. W swoim pliku YAML znajdź sekcjęselect:i uzupełnij opcje o numer 4. Najczęściej dotyczy to priorytetu ładowania. Dodaj te linie:
select:
- platform: modbus_controller
name: "${name} Output source priority"
address: 108
options:
0: Utility first
1: Solar first
2: SBU priority
3: SUB priority
4: Solar and Utility # <--- DODAJ TO
- platform: modbus_controller
name: "${name} Charger source priority"
address: 109
options:
0: Solar first
1: Solar and Utility
2: Only solar
3: No charging
4: Utility first # <--- I TO
- Naprawa “Stop waiting for response” (Stabilność)
Twoje
send_wait_time(200ms) jest na granicy błędu. Zwiększ je, aby ESP dawało inwerterowi więcej czasu na odpowiedź. Zmień sekcjęmodbusna:
modbus:
- id: modbus0
uart_id: uart_0
send_wait_time: 1000ms # Zwiększ z 200ms na 1000ms
mój komentarz jeśli ten falownik potrafi się komunikować szybciej niż 9600 bps, to ja bym go skonfigurował na wyższą prędkość transmisji zamiast zwalniać wysyłanie żądań pięciokrotnie
- Ukrycie “Duplicate modbus command”
Projekt
syssijest tak zbudowany, że te ostrzeżenia będą się pojawiać (sensor po sensorze czyta te same bloki danych). Możesz je wyciszyć wloggerze, aby nie zaśmiecały logów:
logger:
level: INFO
baud_rate: 0
logs:
modbus_controller: ERROR # To wyciszy żółte ostrzeżenia (W) o duplikatach
mój komentarz - w czasie uruchamiania chyba nie do końca chciałbym się pozbywać części logów, ale jeśli działa wszystko OK (to co pokazał @Allon wyjaśnia kwestię zduplikowanych żądań), a jest tylko śmietnik w logach, to oczywiście można to maskować.
tak plik YMALa skopiowałem 1:1 - nic tam nie zmieniałem
@szopen, to co wkleiłeś te dwa przykłady z adresami 108 i 109 to są z tego mojego pliku czy jakieś twoje ? bo ja pod tymi adresami mam coś innego
To jest odpowiedź AI, które nakarmiłem YAMLem spod filmiku i twoimi logami.
Dlatego powinieneś sam pytać AI, wyłapywać jego kłamstwa i go punktować, gdy bredzi.
Zrozum, że ponad czterdziestokilobajtowago YAMLa to ja nie będę na piechotę sprawdzał, bo zajmie mi to kilka tygodni roboty po 8 godzin dziennie, to musisz zrobić albo sam systematycznie po trochu każdego dnia, albo użyć AI nad którym świadomie sprawujesz władzę (musisz znać projekt nad którym pracujesz “na wylot”, dopiero wtedy sztuczna inteligencja robi się użyteczna).
A tak z innej beczki, sam YAML spod filmiku jest też nieco kontrowersyjny - autor w nim wyłączył logger na UART0 tak jakby płytka to było ESP8266 (gdzie nie ma kontrolerów UART do wyboru, bo realnie jest tylko JEDEN do wykorzystania, więc trzeba rzeźbić), a tymczasem masz ESP32 gdzie masz aż TRZY kontrolery UART z czego jeden można właśnie poświęcić na logi po serialu. Więc mam mieszane uczucia do ślepej wiary, że ten YAML jest realnie OK.
oczywiście że nie oczekuję żebyś poprawiał Yamla, mnie tylko chodziło żeby mi ktoś kto się na tym lepiej zna ukierunkował gdzie mam szukać a ja sobie to już postaram zrobić sam, bo ja ze swoją znajomością tego tematu to nawet nie wiedziałem gdzie szukać problemu, teraz muszę to wszystko przemyśleć i pomału ogarnąć. Ważne że coś tam działa więc będzie jakby łatwiej. No nic zobaczymy co z tego wyjdzie, na razie wszystkim wielkie dzięki za poświęcony czas.
Aktualnie komunikaty o zdublowanych adresach o modbausie się uspokoiły lecą tylko te o mappingu:
INFO ESPHome 2026.3.1
INFO Reading configuration /config/esphome/anenji-1.yaml...
INFO Detected timezone 'Europe/Warsaw'
INFO Starting log output from 192.168.0.113 using esphome API
INFO Successfully resolved anenji-1 @ 192.168.0.113 in 0.000s
INFO Successfully connected to anenji-1 @ 192.168.0.113 in 0.071s
INFO Successful handshake with anenji-1 @ 192.168.0.113 in 0.022s
[17:44:43.368][I][app:231]: ESPHome version 2026.3.1 compiled on 2026-03-28 10:02:36 +0100
[17:44:43.370][I][app:233]: Project syssi.esphome-smg-ii version 1.4.0
[17:44:43.371][I][app:238]: ESP32 Chip: ESP32 rev3.1, 2 core(s)
[17:44:43.371][W][app:247]: Set minimum_chip_revision: "3.1" to reduce binary size
[17:44:50.986][E][modbus_controller.select:035]: No option found for mapping 4
[17:45:00.986][E][modbus_controller.select:035]: No option found for mapping 4
[17:45:10.986][E][modbus_controller.select:035]: No option found for mapping 4
[17:45:20.944][E][modbus_controller.select:035]: No option found for mapping 4
[17:45:30.943][E][modbus_controller.select:035]: No option found for mapping 4
a tak przy okazji jak tego loga wkleić w oryginalnym wyglądzie ?
bo ja to widzę tak i widzę że inni to potrafią tak wkleić:
5 postów zostało podzielonych na nowy temat: Kolorowanie logów ESPHome
Daj konkretny link, gdzie to widziałeś.
BTW akurat w tym kawałku loga jest hint dla konkretnie tej wersji MCU, którą masz w ręce
ten fragmencik
esp32:
board: esp32dev
framework:
type: esp-idf
zmień na taki
esp32:
board: esp32dev
framework:
type: esp-idf
advanced:
minimum_chip_revision: "3.1" # MCU ESP32 Xtensa6 z ostatnich wypustów
to spowoduje, że kompilator wyprodukuje wsad binarny idealnie zoptymalizowany konkretnie pod ten egzemplarz (tj. pod każdy egzemplarz ESP32 rev3.1 czyli na dziś najnowszą wersję tego starawego modelu MCU zawierającą wszystkie poprawki w hardware, bez tego są stosowane programowe obejścia błędów w MCU, które są mu niepotrzebne)
nie wiem gdzie widziałem, teraz nie pamiętam, nie zwracałem na ta aż takiej uwagi, ale tak dla porządku na forum mi przyszło o to zapytać bo myślałem że jest to jakoś prostsze do wstawienia, ale widzę że nie jest proste
EDIT:
podsumowując
dałem temu mojemu zestawowi trochę spokojnie popracować i obserwowałem co się dzieje i wychodzi na to że pomimo błędów które się sypią w logach to jednak pomiary są odczytywane poprawnie i komunikacja z falownikiem działa.
Jak falownik pracuje i pomiary lecą do HA to nie ma błędów typu:
[13:55:39.634][W][modbus_controller:307]: Duplicate modbus command found: type=0x3 address=108 count=2
są one tylko jak falownik nie przesyła danych bo przestał pracować lub nie ma komunikacji z falownikiem (płytka ESP32 odpięta od falownika)
natomiast jak falownik pracuje i wysyła dane to są tylko błędy typu:
[08:56:09.987][E][modbus_controller.select:035]: No option found for mapping 4
żadnych innych
tak to wygląda jak falownik pracuje i przesyła dane:
a tak jak odepnę płytkę ESP32 od falownika:
cyklicznie wyskakują komunikaty o tych samych zdublowanych portach, są to tylko wybrane porty i cały czas cyklicznie te same i jest ich 17 szt
w momencie jak pomiary wrócą (lub ponownie podłączę płytkę ESP32 do falownika) to błędy na żółto znikają i pojawiają się tylko błędy na czerwono o MAPPINGU (wtedy żółte błędy już nie występują)
Żółte błędy, to nie są błędy, tylko ostrzeżenia. Jeśli nie chcesz ich oglądać możesz wyciszyć, bo nie ma nic nienormalnego w tym, że nieczynny falownik nie odpowiada (chociaż może lepiej byłoby ogarnąć jakoś obsługę offline? za to nie widzę specjalnego powodu do zmniejszania częstotliwości odpytywania skoro daje radę gdy działa).
Natomiast błędy mapowania wynikają z błędów w samym YAML.
Podpowiedzi od AI masz wyżej, one co do idei są dobre, ale musisz znaleźć gdzie faktycznie masz braki w YAML.
Możesz sobie podwyższyć poziom debugowania, to może będzie więcej istotnych informacji gdzie tego szukać (chidzi o te części konfiguracji gdzie jest select)
Oprócz obrazków wklej też tekst jako kod, bo o kant tyłka te obrazki bez tekstu, który można skopiować…
tak masz robić zawsze i bezwarunkowo (teraz sobie ogarnąłem bez aktualnych logów, bo wykopałem sobie stare z jakiegoś starego posta, ale jeśli szukasz pomocy, to nie rzucaj kłód pod nogi odpowiadającym)
aktualna podpowiedź AI jest taka
# Battery charging priority
- platform: modbus_controller
# ... reszta parametrów ...
optionsmap:
"Utility priority": 0
"PV priority": 1
"PV and Utility": 2 # Czasami 2 to PV+Utility, sprawdź dokumentację
"Only PV": 3
"PV and Utility (Hybrid)": 4 <-- DODAJ TĘ LINIE
# …
# ewentualnie tu
"PV-Battery-Utility (SBU)": 2
"PV-Utility-Battery (SUB)": 3
"Unknown Mode 4": 4 <-- DODAJ TĘ LINIE
no ja nie mam takiego falownika, to mogę co najwyżej zgadywać i to wcale nie lepiej od AI gdzie falownik ci zwraca odpowiedź, której YAML nie przewiduje
(jeśli nie wiesz gdzie szukać to wywalaj wszystkie sekcje optionsmap z sekcji select i zostaw tylko jedną, potem wstaw do kodu tylko drugą itd. aż znajdziesz błędną)
czyli wywal w całości to
select:
# Output Mode Uint 300 1 R/W 0: Single, 1: Parallel, 2: 3 Phase-P1, 3: 3 Phase-P2, 4: 3 Phase-P3
- platform: modbus_controller
modbus_controller_id: smg0
name: "${name} output mode"
use_write_multiple: true
address: 300
value_type: U_WORD
entity_category: config
icon: mdi:cog
optionsmap:
"Single": 0
"Parallel": 1
"Phase P1": 2
"Phase P2": 3
"Phase P3": 4
# Output priority Uint 301 1 R/W 0: Utility-PV-Battery, 1: PV-Utility-Battery, 2: PV-Battery-Utility
- platform: modbus_controller
modbus_controller_id: smg0
name: "${name} output priority"
use_write_multiple: true
address: 301
value_type: U_WORD
entity_category: config
icon: mdi:cog
optionsmap:
"Utility-PV-Battery (UTI)": 0
"PV-Utility-Battery (SOL)": 1
"PV-Battery-Utility (SBU)": 2
"PV-Utility-Battery (SUB)": 3
# Input voltage range Uint 302 1 R/W 0: Wide range, 1: Narrow range
- platform: modbus_controller
modbus_controller_id: smg0
name: "${name} input voltage range"
use_write_multiple: true
address: 302
value_type: U_WORD
entity_category: config
icon: mdi:cog
optionsmap:
"Wide range": 0
"Narrow range": 1
# Buzzer mode Uint 303 1 R/W 0: Mute in all situations, 1: Sound when the input source is changed or there is a specific warning or fault, 2: Sound when there is aspecific warning or fault, 3: Sound when fault occurs
- platform: modbus_controller
modbus_controller_id: smg0
name: "${name} buzzer mode"
use_write_multiple: true
address: 303
value_type: U_WORD
entity_category: config
icon: mdi:cog
optionsmap:
"Silent": 0
"Beep on input source changes, warnings and faults": 1
"Beep on warnings and faults": 2
"Beep on faults": 3
# LCD backlight Uint 305 1 R/W 0: Timed off, 1: Always on
- platform: modbus_controller
modbus_controller_id: smg0
name: "${name} lcd backlight"
use_write_multiple: true
address: 305
value_type: U_WORD
entity_category: config
icon: mdi:cog
optionsmap:
"Timed off": 0
"Always on": 1
# Battery charging priority Uint 331 1 R/W 0: Utility priority, 1: PV priority, 2: PV is at the same level as the Utility, 3: Only PV charging is allowed
- platform: modbus_controller
modbus_controller_id: smg0
name: "${name} battery charging priority"
use_write_multiple: true
address: 331
value_type: U_WORD
entity_category: config
icon: mdi:cog
optionsmap:
"Utility priority": 0
"PV priority": 1
"PV is at the same level as the Utility": 2
"Only PV charging is allowed": 3
# Turn on mode Uint 406 1 R/W 0: Can be turn-on locally or remotely, 1: Only local turn-on, 2: Only remote turn-on
- platform: modbus_controller
modbus_controller_id: smg0
name: "${name} turn on mode"
use_write_multiple: true
address: 406
value_type: U_WORD
entity_category: config
icon: mdi:cog
optionsmap:
"Local and remotely turn-on allowed": 0
"Local turn-on only": 1
"Remote turn-on only": 2
- platform: modbus_controller
modbus_controller_id: smg0
name: "${name} battery type"
use_write_multiple: true
address: 322
value_type: U_WORD
entity_category: config
icon: mdi:cog
optionsmap:
"AGM": 0
"FLD": 1
"USER": 2
"Li1": 3
"Li2": 4
"Li3": 5
"Li4": 6
"Lib": 8
a potem wklej sobie tylko tyle zamiast tego co wywaliłeś hurtem
select:
# Output priority Uint 301 1 R/W 0: Utility-PV-Battery, 1: PV-Utility-Battery, 2: PV-Battery-Utility
- platform: modbus_controller
modbus_controller_id: smg0
name: "${name} output priority"
use_write_multiple: true
address: 301
value_type: U_WORD
entity_category: config
icon: mdi:cog
optionsmap:
"Utility-PV-Battery (UTI)": 0
"PV-Utility-Battery (SOL)": 1
"PV-Battery-Utility (SBU)": 2
"PV-Utility-Battery (SUB)": 3
jeśli będą takie same błędy w logach po kompilacji z tego okrojonego kodu, to źródło błędów jest tutaj - poprawiasz i po krzyku
i robisz to samo analogicznie z innymi sekcjami
A gdy już będziesz wiedział gdzie jest do bani, to poprawioną wersję tego wszystkiego co wywaliłeś wkleisz sobie w całości i będzie OK
Gdybyś od początku uruchamiał kod po kawałku, to byś znalazł od razu w którym miejscu jest coś nie halo.
a mam ciut inne pytanie:
już mi to połączenie działało, wszystko chodziło i tylko chciałem wprowadzić drobne zmiany nazwijmy to kosmetyczne w Yamlu, w karcie tego urządzenia w ESPHOME. Więc zrobiłem ponowną kompilację, na nowo wgrałem soft na płytkę ESP32 i po uruchomieniu nie widziałem wprowadzonych zmian, dlatego następnie skasowałem kartę tego urządzenia w “Urządzenia oraz Usługi” w “ESP HOME” w “Integracjach” i na nowo wgrałem soft na płytkę ESP i nic się nie pojawiło (nie pojawiło się nowe urządzenie w ESPHOME) , więc ponownie zrobiłem kompilację i wgranie softu na płytkę ESP (tego który wcześniej działał) czyli wróciłem do działającego pierwowzoru i nadal nic nie wykrywa, nie wykrywa nowego urządzenia żebym mógł go na nowo dodać.
czy chodzi o to, że pomimo skasowania nadal coś gdzieś siedzi i nie pozwala nadpisać nowo wgrywanego ? czy trzeba odczekać, żeby coś nieużywanego się usunęło żeby się nie dublowało, czy o co chodzi ?
Zrestartuj HA, przy takim opisie (bez tych YAMLi), to nie mamy o czym rozmawiać.
Tzn. to, co opisujesz nie powinno się w ogóle wydarzyć, ale szklanej kuli nie mam.
też mi sie tak wydaje. HA już resetowałem
najprościej mówiąc skasowałem kartę, kafelek w ESP HOME, integrację i utworzyłem na nowo i już się nie pojawia, a problem nie jest przypadkiem w tym że wgrałem na nowo yamla z tymi samymi danymi z tym samym MAC adresem urządzenia, ale i nazwa jest ta sama więc jakby się nic nie zmieniło
Nie sądzę.
Ale nawet się nie będę zastanawiał nad tym nie mając możliwości próby odtworzenia problemu bez obu YAMLi
to wiele tłumaczy (tzn. domniemuję wiele różnych możliwych błędów w workflow)
Nie bardzo rozumiem te wszystkie ruchy - jeśli encje w urządzeniu się nie odświeżyły, jedyne co trzeba zrobić, to usunąć je (to urządzenie) z Integracji i dodać tam ponownie.
Optymalnie, gdy w twojej sieci działa jak należy mDNS - sprawdź to w
Ustawienia → System → Sieć → Wykrywanie sieci → Przeglądarka Zeroconf
i tu przychodzi do głowy mnóstwo pytań o konfigurację sieci, ale czy to się kwalifikuje na ten wątek nie wiem
