Dzień dobry
Zaczynam przygodę z HA, przeszedłem podstawowe poradniki z forum z małymi problemami które jednak dało się rozwiązać. Ponieważ zaczynam od prostego projektu, zdecydowałem się wykorzystać bezpośrednio piny Raspberry, odczyt stanów kontaktronów i sterowanie przekaźnikami, mam też ESP8266 którym generuje programowo PWM, wiem że to nie jest zalecane rozwiązanie i już odczułem tego skutki, na przykład włączające się losowo przekaźniki (włącza je supervisor) lub nie płynny start PWM. Ale do brzegu.
Chciałbym wzbogacić swój system o Arduino mega r3, któż już mam, z informacji zawartych na forum zdecyduje się na protokół MQTT i tu mam pewien kłopot, chodzi o sposób komunikacji z HA. Ponieważ całość elektroniki będzie zamknięta w jednej skrzynce wolałbym korzystać z jakiegoś połączenia przewodowego USB lub UART, natomiast nie mam na tyle doświadczenia żeby zdecydować który sposób będzie lepszym rozwiązaniem oraz jak to wykonać, chciałbym uniknąć rozwiązań bezprzewodowych WIFI bo jestem zwolennikiem rozwiązań przewodowych a poza tym w domu mam już sporo przewodów rozciągniętych, LAN też bym chciał pominąć. Proszę o jakieś sugestię, może jakiś poradnik jak zestawić połączenie i generalnie jak wykonywać komunikację żeby HA pogadał sobie z Arduino.
Pozdrawiam
A w jakim celu chcesz użyć Arduino? Pytam, bo jest to płytka deweloperska (łączona na kabelkach albo shieldy), co generalnie jest dyskusyjnym rozwiązaniem w kwestiach niezawodnościowych 
Ale równie dobrze można to zmienić w połączenie lutowane.
Swoją drogą np. nano, micro i mini (a nie znam wszystkich modeli, bo w ogóle Arduino to “nie moja bajka”) są w postaci płytek idealnych do wlutowania w inne konstrukcje nawet bezpośrednio w PCB.
Oczywiście są inne minusy DIY (w tym chyba najważniejszy to brak ogólnie dostępnej dokumentacji jeśli to nietypowy projekt, więc przygotowanie czegoś takiego ciąży na autorze), ale że mam już parę lat na karku, to mogę powiedzieć, że widziałem projekty DIY (wtedy to raczej “zrób to sam”) które przetrwały znacznie dłużej niż wiele współczesnych konstrukcji produkowanych masowo.
Zasadniczo połączenie USB w większości wypadków łączenia MCU z SBC czy jakimikolwiek innym komputerem to tak naprawdę połączenie UART z zastosowaniem mostka UART-USB.
Biorąc pod uwagę trend rozwoju HA (gdzie wsparcie dla GPIO jest systematycznie usuwane z HA na korzyść innych rozwiązań) to chyba nie jest najlepsza droga w tym momencie.
Jakkolwiek nie chcę zniechęcać do realizacji pomysłu, sprzętowy PWM miałbyś choćby w ESP32 wprawdzie to nadal WiFi (ale np. płytki prototypowe okrojonej wersji ESP32-C3 która ma zastąpić rodzinę ESP82xx a nadal ma sprzętowy PWM można w tej chwili kupić wręcz za grosze - coś koło 4 dolców/szt., chociaż te tanie to niestety wypusty bezczelnie potanione przez użycie stabilizatora 3,3V nie spełniającego minimum specyfikacji, więc trzeba trochę pokombinować, ale próbnie używam jeden egzemplarz i pracuje mimo wszystko stabilnie).
@Maurycy, jest sporo możliwości aby wykonać niezawodne połączenia nawet na płytkach dewloperskich. Arduino ma zbierać sygnały z otoczenia i przesyłać je do HA, mam większe doświadczenie w pracach manualnych (lutowanie itp) niż w pisaniu programów dlatego to co mam teraz złożone jest w formie prototypu i na razie faktycznie jest na kabelkach, co oczywiście będzie do zmiany.
@szopen faktycznie GPIO jest usuwane na rzecz połączeń bezprzewodowych, ale nie wydaje mi się żeby zrezygnowali z komunikacji UART dlatego chyba zdecyduje się na połączenie arduino z HA przez UART. Co do ESP jeśli bym je wybrał to rozumiem że musiałbym ich zamontować kilka sztuk czyli każdy element to kolejny adres ip, dodatkowe kale zasilające itd. a w mojej ocenie arduino z powodzeniem mogło by to zastąpić. tylko jak wspominałem wcześniej, programowanie to na razie dla mnie przeszkoda.
Po pierwsze Arduino to nie “moja bajka”, ale widziałem że bywają problemy z wieloma portami szeregowymi (RPi jeśli dobrze pamiętam ma jeden, rs232 nie umożliwia fizycznie łączenia innego niż 1:1, oczywiście stosując USB i huby możesz zwielokrotnić ilość portów, ale tu wychodzą kolejne problemy), przejrzyj te wątki
https://forum.arturhome.pl/tag/arduino
Natomiast w kwestii wykorzystania ESP (bo znam rodzinę ESP dość dobrze, ponieważ “jestem fanem” ESPHome) to zaproponowałem, (mimo że to WiFi) akurat ESP32-C3 ponieważ moim zdaniem, jest świetny do niskobudżetowych konstrukcji (doskonale zastąpi ESP8266), a jego wsparcie programowe już jest w wystarczająco dojrzalej fazie (w tym MCU po raz pierwszy zastosowano inny procek - RISC-V zamiast Xtensa LX, a z tego co widzę większość nowych wypustów będzie właśnie na RISC-V). Potencjalnie możliwy do użycia jest też ESP32-S2 (też bez Ethernetu w wersji przewodowej, oraz okrojony z BT/BLE, za to ma naprawdę mnóstwo GPIO do wykorzystania, a z nowszych wypustów ESP-S3 - tu też cena jest dość ciekawa, chyba wrzucę jakiś wątek o S3/C3)
Natomiast stosując nieco droższe zwykłe “stare” ESP32 (bez przyrostków w nazwie) nie jesteś ograniczony do komunikacji WiFi, można na ich bazie użyć moduły z przewodowym Ethernetem, ba są nawet gotowe całkiem sensowne konstrukcje je wykorzystujące, a stosując topologię gwiazdy nie musisz używać wielu MCU - w tych przykładach poniżej wykorzystane są na dużą skalę ekspandery portów
https://forum.arturhome.pl/tag/kincony
a nie jest to jedyna podobna konstrukcja na rynku (chociaż ta jest chyba jedną z najtańszych)
edit:
Więc tym bardziej warto spojrzeć na projekt ESPHome, gdzie sensownie działające urządzenia wykonawcze czy czujniki można ogarnąć za pomocą kilkunastu linii YAMLa (na podstawie którego jest budowany kod źródłowy, swoją drogą ESPHome “pod pokładem” zawiera 2 frameworki: Arduino oraz ESP-IDF dostępne w zależności od wybranego MCU, ale w obecnej fazie rozwoju projektu jako gałąź stabilna obsługiwana są rodziny ESP8285/8266/32, natomiast jako testowa traktowane jest wsparcie dla Espressif ESP32-S2/-S3/-C3 moim zdaniem już w dość zaawansowanym stopniu, choć to jeszcze nie jest wersja produkcyjna oraz Raspberry RP2040 w fazie raczej wstępnej, więc jeśli mamy w danej wersji skompilowany wsad, to radzę sobie go zarchiwizować, co w zasadzie jest dobrym pomysłem dla każdej z platform sprzętowych, ale akurat w przypadku RPi pico były przypadki budowania niedziałających wsadów, a 1 z dostępnych metod flashowania RP2040 jest nie poprawiona chyba już od ponad miesiąca, więc nie wiedząc o tym można się długo zastanawiać co robimy źle).
Jako zwolennik Arduino podpowiem ci inne rozwiązanie: Wemos. Albo do lutowania (Nettigo: Moduł WiFi Wemos D1 mini V2) albo arduinopodobne (D1 R2 WiFi ESP8266 - zgodny z WeMos i Arduino Sklep Botland). Ma mniej I/O ale za to wbudowane WiFi. Do Wemosa wgrywasz Tasmotę i masz od ręki wsparcie dla HA. Plus ADC, IO, I2C i to bez programowania z małą ilością lutowania.
Czyli mamy dwa obozy ze wspólnym punktem jakim jest WIFI. Co do wrzutki jakiegoś opisu do ESP-C3, to jest to bardzo dobry pomysł, a jeszcze jakby był poparty jakimiś przykładami to już byłoby super.
Przeglądałem Ali… w poszukiwaniu ESP-C3 i pojawił się ogrom różnych wersji co wprowadziło u mnie małe zamieszanie który wybrać model.
@szopen jakbyś mógł podać link do konkretnej wersji jaką masz na myśli, to było by fajnie. Na polskich stronach też nie jest lepiej, szczególnie jeśli chodzi o dostęp do dokumentacji, przeważnie jest niepełna, chyba że słabo szukałem.
Mam też pytanie, załóżmy że masz cztery pokoje w których masz taką samą ilość czujników, po jednym PWM i coś tam jeszcze, generalnie jeden ESP dałby radę to obsłużyć bo ma tyle pinów, jakbyś podszedł do sprawy, po jednym ESP na pokój czy ciągnąć przewody w jedno miejsce i spiąć to na jednym ESP, czujki to kontaktrony, termometry, pir, wszystkie są przewodowe. Powoli przekonuje się do WIFI, może spróbuję zrobić dwie wersje, przy czym Arduino zaczynam od podstaw.
P.S. pisałem z komórki i coś mnie wywaliło. Proszę usunąć poprzedni wpis.
To nie jest tak, że są jakieś obozy, a WiFi jest preferowane - po prostu każdy patrzy na dane zagadnienie z własnego punktu widzenia, a przeważnie też z jakimś specyficznym dla siebie zasobem wiedzy i upodobaniami, a każdy cel można osiągnąć na wiele różnych dróg.
Podałeś swoją konfigurację, którą uznałem za niskobudżetową i dlatego zaproponowałem w związku z tym niskobudżetowe rozwiązanie.
Nie widzę szans na przykłady, po pierwsze są zależne od projektu jaki zamierzasz wykorzystać (ESPHome, Tasmota, Platformio, Arduino - platforma programowa w zasadzie zależy od tego w jakim stopniu chcesz być programistą) - a C3 jest po prostu przykładem MCU który ma zastąpić ESP82xx w klasie niskobudżetowej.
Wątek na temat ESP32-C3 mam w przygotowaniu (o ESP32-S3 też)
Dokumentacja zazwyczaj jest dostępna na stronach producentów (nie będę tłumaczył dokumentacji na polski, będą tylko linki, swoją drogą dokumentacja każdego MCU jest zwykle grubości przeciętnej encyklopedii - to tysiące stron do czytania dokumentacji ściśle technicznej, nie zajmuję się tym zawodowo, więc nie czytuję od deski do deski, zwykle wystarcza jakiś skrót + troszeczkę doświadczenia z elektroniką), w rękach mam kilka najtańszych modułów, oczywiście były BEZ dokumentacji, bo ich producent to olał, ale przetrzepałem internet i wiem sporo, to wszystko będzie w wątku który powstaje.
Mały hint: chudy portfel zwykle nie jest dobrym doradcą…
Jeden MCU to jest kolejny zły pomysł, w podobnym wątku, znajdziesz odpowiedzi dlaczego (chociaż pisałeś, że masz doświadczenie z elektroniką to powinieneś zdawać sobie z tego sprawę)
WiFi ma jedną zaletę (jak i każda inna technologia bezprzewodowa) - lokalizacja jest jedynie uzależniona od źródła zasilania (a i to nie zawsze, ale zrobienie sensownie działającego DIY zasilanego akumulatorowo jest znacznie większym wyzwaniem niż się wydaje).
No generalnie jeden MCU który ma ogarniać każde zagadnienie w całej chacie, to błąd większości początkujących (nawalić do jednego urządzenia tyle funkcji ile się w nim zmieści lub wręcz nie zmieści, a potem szukać gdzie jest błąd), oczywiście pomysł przeciwny biegun typu “1 MCU na 1 czujnik” też jest słaby (choć tak są projektowane masowo wytwarzane produkty, z których… korzystam), w przypadku DIY warto iść na jakiś sensowny kompromis.
Wrócę jeszcze do tematu rozwiązań przewodowych - stosując ESP32 (bez przyrostków) można użyć przewodowego Ethernetu, wręcz wiele konstrukcji umożliwia wykorzystanie PoE, tylko wtedy na płytkę prototypową z MCU i Ethernetem trzeba wysupłać 100zł-200zł (rozwiązania bez PoE można znaleźć poniżej 100zł, ale coś fajnego z PoE może kosztować znacznie więcej niż 200zł) no ale trzeba mieć wtedy okablowanie Ethernet i chociaż budżetowego switcha PoE.
No i to jest kwestia, czym się zajmujesz i jaką masz wizję na przyszłość.
Jeśli się nie mylę to był projekt pomocy naukowej dla studentów kierunków politechnicznych i takiej wiedzy to wymaga (w sensie wiedzy inżynierskiej, albo nadrobienia braków nauką od podstaw).
RPi było dla przykładu pomocą naukową dla szkół średnich i chyba później podstawówek, w każdym razie świetnym wypustem dydaktycznym dla podstawówek jest BBC micro:bit (tam to państwowe radio i telewizja naprawdę spełniają rolę misyjną, nie to co u nas…)
PS - taka mała prywata
Osobiście pominąłem etap Arduino (i czasem mi brakuje wiedzy, którą można zdobyć tylko jeśli się robi coś od podstaw), a na swoje usprawiedliwienie mam tylko fakt, że jak się pojawiło na rynku (kilkanaście lat temu, a z całą pewnością sporo więcej niż 10) to: po pierwsze było naprawdę drogie na polską kieszeń, a po drugie miałem taki etap w życiu, że nie było czasu na hobby. A jak już staniało (chińskie klony) i zacząłem mieć więcej czasu dla siebie, to odkryłem Espressif’a i zamiast się wdrażać od podstaw w Arduino od razu zauroczyło mnie ESPHome i to w sumie jako coś wtórnego względem HA, (tylko HA parę lat temu wymagał “kilometrów” YAMLa, więc przeskok do ESPHome był już dość naturalnym krokiem).
PPS “Krowa, która dużo ryczy mało mleka daje”, a wpadłem już w syndrom ryczącej krowy i klepię na forum zamiast robić swoje.
Edit - wstępna wersja (w miarę sił i czasu dorzucę jakąś dokumentację a może i resztę)
No cóż, przytyk
“chudy portfel zwykle nie jest dobrym doradcą…”
jest trochę nie na miejscu.
Co do dobierania podzespołów pod projekty, nie zgodzę się ze stwierdzeniem że
“jeden MCU który ma ogarniać każde zagadnienie w całej chacie, to błąd”
Po to producenci podzespołów produkują tyle różnych wersji, żeby można było wybrać odpowiednią dla siebie, przecież nie weźmiesz ATMEGA328 jedynie do obsługi czujników w oknach bo do tego wystarczy zwykła '51, generalnie nie myślisz jak programista, poto producent umieścił w procku tyle peryferii (PWM, UART, I2C, itd.) żeby z nich skorzystać. Jeśli dany procek się nie wyrabia to tylko dlatego że nie jest odpowiednio dobrany lub nie ogarniasz jako programista, masz odpowiednią ilość pamięci i to twoje zadanie zmieścić się w ograniczeniach, powinno się tak napisać program aby spełniał wszystkie potrzeby. Swego czasu programowałem procki z rodziny '51, ale że byłem w tym słaby, tzn znam lepszych, pozostałem przy prostych projektach (zegary, sterowanie zasilaczem) ale nadal mam przekonanie że poprawnie napisany program i odpowiednio dobrany procek spełni wszystkie wymagania jakie sobie założyłem w jednym układzie.
Co do WIFI, nie wiem jak u was ale u mnie jest sporo zakłóceń, czasami mnie odcina od sieci, poza tym większość akcesoriów działa w 2,4GHZ, gdzie jest sporo shitu no i w dosyć łatwy sposób można to zakłócić, kabel to kabel, dlatego jestem zwolennikiem rozwiązań przewodowych. Co do nauki od zera to czemu nie.
To nie przytyk, tylko fakt, nadmierne oszczędności zawsze mają kiepski finał.
WiFi u mnie stabilne jak skała, ale generalnie na rozwiązania bezprzewodowe postawiłem z braku możliwości dołożenia okablowania i akurat nie jestem fanem rozwiązań WiFi, ale ich nie odrzucam, bo są genialnie proste w budowie własnego DIY (jakkolwiek można na bazie ESP32 zbudować rozwiązania z przewodowym Ethernetem - trzeba na to odpowiednio większą gotówkę), ale stosuję też Zigbee i BLE, a to też 2,4GHz oraz z-wave = pasmo sub-1GHz