Skąd pomysł akurat na takie ścieżki?
Nie miałeś błędów przy kompilacji?
Nie miałem, jakie powinny być poprawne w takim razie?
To co zamieściłeś, schematowo wygląda poprawnie. W którym miejscu zamieniałeś Rx Tx … pomiędzy ESP a konwerterem (z tymi oznaczeniami bywa różnie)?
Czy na tym konwerterze jest LED sygnalizujący transmisję i czy mruga?
Nie znam ESPHome ale masz inną definicję modułu… nie powinno mieć to znaczenia moim zdaniem więc niech wypowie się ten co się zna.
Na moje oko to comfoair.h masz w innym miejscu niż podałeś w include (ale może się coś zmieniło w ESPHome i załącza z podkatalogów? bez ich jawnego podania w kodzie (YAMLu))
Od definicji modułu zależą aliasy takie jak TX czy D1, można z nich nie korzystać podając po prostu fizyczny numer pinu dla użytego MCU (konkretnie numer końcówki scalaczka ESPxxxx, a nie opis nadrukowany na PCB - taka numeracja bywa drastycznie inna).
TX i RX są akurat aliasami, które pasują prawdopodobnie do każdego modelu płytki z ESP8285/8266 (bo ten MCU ma jeden w pełni funkcjonalny sprzętowy UART wyprowadzony raczej zawsze tak samo, ale sprawdzać mi się nie chce, zdecydowanie lepszą praktyką jest wykorzystywanie definicji płytki zgodnej z użytym sprzętem, definicja esp01_1m jest dla płytek “ESP-01 czarny laminat” oraz dla ESP-01s, natomiast dla płytki z obrazka tj. tego schemaciku użyłbym nodemcuv2 bo na zdjęciu to płytka NodeMCU v2).
tak, pomiędzy ESP a konwerterem, są dwie diody, jedna od zasilania druga jak domniemam od transmisji, świeci tylko ta od zasilania.
Czy powinienem w takim razie zmienic na board: nodemcuv2 (załacznik)
Panowie podpowiedzcie w takim razie jaka sciezka do tego include, ewentualnie jak mam upewniać się ze podana ścieżka jest dobra lub zła, jest możliwa jakaś kompilacja kodu?
Czyli ta definicja jest dla kogoś co nie wie do końca co robi? 
Ok, zmieniam i zaraz przetestuje.
dzieki za cierpliwosc…
Ja bym zmienił.
Konwertery mediów często się wpina TX do TX MCU, a RX do RX MCU (najlepiej to sprawdzić w dokumentacji tego, który masz). Niestety trafiają się konstrukcje opisane inaczej, ale nic prostszego niż zamienić przewody.
Dopiero urządzenia docelowe łączysz “na krzyż” (jest to chyba jasne jak Słońce, że sygnał nadawany - TX z jednego musi trafiać do RX, czyli odbiornika, w drugim i nawzajem).
Bez przesady, przykładowo płytka NodeMCU ma wlutowany moduł ESP12 (castellated) w którym ESP8266 jest “zaspawany” pod blachą ekranu, więc nawet nie widać gdzie co jest podpięte, więc zamiast ślęczeć nad dokumentacją, czy ewentualnie śledzić ścieżki na PCB (co jest nieuniknione, gdy przerabiasz jakieś gotowe urządzenie a nie płytkę prototypową) używasz właściwą definicję i translację opisów masz z czapki - nie musisz nigdzie szukać, że np. RX to GPIO3 = 3 albo D0 = GPIO16 = 16.
Mi się wydaje, że oba pliki tj. *yaml i *.h powinieneś mieć w tym samym katalogu (.h tam gdzie .yaml), a jeśli wrzucasz do podkatalogu, to powinieneś jawnie podać ścieżkę względną, ale jestem w delegacji i nie mam czasu na eksperymenty.
Generalnie katalogiem “bazowym” jest /config/esphome/ w którym mamy cały “śmietnik”, więc jeśli chcesz coś uporządkować, to możesz w nim założyć podkatalogi i do nich się odwoływać (sprawdź w dokumentacji jak działa include, bo z pewnością działa inaczej przy załączaniu całego katalogu, a inaczej dla konkretnego pliku, działa również różnie zależnie od tego co załączasz - mam na myśli rodzaj pliku).
Czytaj po prostu logi kompilacji - tam zwykle jest wszystko, czasem daje się skompilować firmware, które nie działa lub nie ma pożądanych funkcji (np. ostrzeżenia nie przerywają kompilacji).
Niestety dalej bez zmian, po podłaczeniu kabla od razu wyskakuje komunikat “bład comfonet, sprawdz kable”
Pokaż logi z pracy modułu ESP w ESPHome. Mam wrażenie, że nie rozumiesz jak to wszystko działa i skaczesz z kwiatka na kwiatek. Czy aby na pewno wiesz jak posługiwać się ESPHome i na czym polega kompilacja pliku wsadowego .bin, a następnie jego wgrywanie do ESP? Czy twoja konfiguracja w YAML dla modułu ESP tworzona w ESPHome przechodzi walidację bez błędów?
Uczę się, mam podobne wrażenie, ze zapominałem o podstawa skacząc na inne rzeczy… przyznaje. Mam nadzieje to wszystko nadrobić.
Przechodzi bez błędów, pliki w załączniku.
Downloads.zip (3,0 KB)
Skoro używamy sprzętowy UART na jego natywnych pinach, to on w ogóle nie wymaga tak rozbudowanej definicji jak na obrazku powyżej, no i po to mamy aliasy, wszystko się zmieści w 5 linijkach.
Oczywiście nie można definiować TX na pinie RX i odwrotnie.
Rzeczywiście jest błąd. Zmienilem jak poniżej, jest mały sukces bo nie wyrzuca błedu na rekuperacji. Ale dalej brak komunikacji, nie swieci sie tez dioda od komunikacji na R232. Jak sprawdzic czy esp komunikuje sie dalej?
uart:
id: uart_bus
baud_rate: 9600
tx_pin: TX
rx_pin: RX
Plik jest w walidacji, wiec zawiera zapis pełnej konfiguracji przed kompilacją.
Przecież w pierwotnej wersji tak miałeś?
Słusznie @angler sugeruje że coś jest nie tak z aliasami.
Wpisz jawnie
uart:
id: uart_bus
baud_rate: 9600
tx_pin: 1
rx_pin: 3
Zmieniłem, bez zmian. Jak moge upewnić sie ze sygnał z tego urządzenia wychodzi albo jest ruch miedzy tymi TX i RX urzadzenia a rekuperacja? Jest na to jakis sposób?
Nic się nie zmieniło? Przyjrzyj się dobrze… jak nie mruga to nie ma transmisji.
Najmocniej przepraszam, na urządzenia jest wyłącznie jedna dioda oznaczona D1. Ona cały czas się świeci - światłem ciągłym.
Od samego początku mi coś “świerdziało”
AerisNext (to samo co ComfoAir Q) nie jest kompatybilny z połączeniem szeregowym/RS232. Nie możesz tego kontrolować za pomocą tej integracji. Ponadto ComfoNet nie jest protokołem szeregowym (nie jestem pewien, co to jest, prawdopodobnie coś takiego jak modbus). Aby zintegrować to z HA, potrzebujesz interfejsu sieciowego ( ComfoConnect LAN C ) i oficjalnej integracji:
… resolved
1 polubienie