W przypadku gdy na nowym urządzeniu są te same nazwy wejść to HA dodaje encje o tej samej nazwie z rozszerzeniem “_1” i sukcesywnie powiększa numerację gdy ta już występuje. Czyli jeżeli dodamy kilka urządzeniem z tymi samymi nazwami to będziemy mieli encje o ID z rozszerzeniem “_1”, kolejne urządzenie encje z dopiskiem “_2” itd.
Urządzenie 1 :
binary_sensor:
- platform: gpio
name: "Test Door Sensor"
tworzy encję o ID binary_sensor.test_door_sensor
Urządzenie 2 :
binary_sensor:
- platform: gpio
name: "Test Door Sensor"
tworzy encję o ID binary_sensor.test_door_sensor_1
Żeby uniknąć takiego zachowania trzeba wpierw usunąć encje i dopiero dodać nowe urządzenie ze starymi nazwami wejść. Wtedy będzie poprawnie. No to robi się nam dodatkowy nakład pracy w przypadku wymiany urządzenia. Rozumiem, że jest to zabezpieczenie przed przypadkowym przypisaniem tych samych encji dla nowego urządzenia. Efekt uboczny to niestety brak możliwości prostej podmiany urządzenia np. w przypadku awarii. Podobne doświadczenia widzę, że są opisane na forum HA.
Pewnym ułatwieniem jest możliwość zaznaczenia na liście encji kilku jednocześnie i ich usunięcie jedną operacją. Także kliknięcie kilkadziesiąt “ptaszków” i jeden raz wybranie “usuń” w przypadku rzadkiej sytuacji wymiany awaryjnej urządzenia jest do przejścia.
Jedna istotna uwaga. Wszelkie automatyzacje i wizualizacje (dashborad’y) muszą odnosić się do encji. Wtedy taka operacja powinna się udać. Czyli kopię konfiguracji wgrywamy na nowe urządzenie, usuwamy stare urządzenie i jego encje w HA, a następnie dodajemy w HA nowe urządzenie z konfiguracją z kopii zapasowej zawierającą poprzednie nazwy wejść/wyjść.
Witam wszystkich bo to mój pierwszy post na tym forum. Trochę odgrzeje tego “kotleta” bo mam właśnie problem z opóźnieniami a chce zastosować konfigurację NotteNick 'a czyli ESP32 + wykorzystanie obu portów i2c do obsługi minimum 10 x MCP23017.
Ale do rzeczy. Mam trochę dziwną sytuację bo wcześniej testowałem ESP12F+TCA9548A+MCP23017 i wszystko gra i buczy.
Jednak zacząłem testować ESP-S2 mini z dwoma portami i2c+MCP23017 i okazało się, że przy domyślnych ustawieniach częstotliwości taktowania i2c sypie komunikatami opóźnienia:
[20:37:14][W][component:232]: Component gpio.binary_sensor took a long time for an operation (1000 ms).
[20:37:14][W][component:233]: Components should block for at most 30 ms.
Pojawia się to w momencie dodania portów przycisków. Co gorsza czasami powoduje zmiany stanów portów wyjściowych przekaźników. Podwyższenie częstotliwości taktowania do 400 kHz zmniejsza ilość komunikatów. Podwyższenie do 800 powoduje, że jest ich jeszcze mniej ale nadal są i nadal sporadycznie następuje zmiana stanu portu przekaźnika. Dalsze zwiększanie nie daje rezultatu bo z tego co wiem wymaga to podwyższenia napięcia zasilania MCP23017 do 5V.
Podłączałem również jeden układ MCP23017 i również jest taki problem.
Podłączałem również przez TCA9548A ale też nie rozwiązuje problemu.
Dopiero po zmianie na staruszka ESP12F i użycie jak na początku TCA9548A daje pełną stabilność i w dodatku przy taktowaniu 100 kHz. Ma ktoś jakieś pomysły?
Nie mam zastrzeżeń do tego układu. Od kilku lat mam 4 x esp12f + mcp23017 do każdego z nich o obsługują mi część domu. Układ jest prototypowy na pająka i działa bez zastrzeżeń. Teraz chcę zrobić wersje ostateczną na jednym esp i myślałem o esp32 aby wykorzystać dwa porty i2c aby pozbyć się przełącznika.
To pozostaje walczyć dalej z nowym rozwiązałem . Na ukladach PCF857x z ESP32 oparte są rozwiazania boneIO i Kincony (oba udostępniają pełne specyfikacje sprzętowe rozwiazania), działa, również potwierdzam. Czasami zamiast wymyślać lepiej skopiować to co już działa, Samsung tak właśnie zaczynał .
No ja bym zaczął od issue - poszukać czy nie było czegoś dotyczącego S2 - to dość stara konstrukcja i od pewnego czasu ma już status NRND (ten MCU wśród wypustów Espressif chyba dostał ten status jako drugi po ESP8266/8285 i równolegle z “ESP32 solo”; S2 też ma jednordzeniowy procek z tym, że LX7 czyli rdzeń taki jak w S3, a nie LX6 jak w zwykłej “jedynce” ESP32 i w solo), więc jako stara konstrukcja powinna być świetnie wspierana, ALE wśród hobbystów S2 jest stosunkowo mało popularne, a w dodatku na rynku jest doskonale dostępny funkcjonalny następca - ESP32-S3.
Oraz poszukać czy było coś o MCP23017 (serie 0542 i wcześniejsze miały sprzętowego buga, więc sprawdź datę produkcji, bo w ramach kryzysu komponentów na rynku znalazły się układy, których nikt by się nie spodziewał).
@sindap
Osobiście uważam, że to powinien być osobny wątek, bo z ESP32 nie ma nic wspólnego gdyż ESP32-S2 jest totalnie inną konstrukcją… (a jeśli w wątku jest mydło i powidło, to nie da się tego rozsądnie otagować). Więc jeśli podrzucisz sensowny tytuł, to wydzielę do osobnego wątku.
Nie mam nic przeciwko temu by przenieść do osobnego wątku. Trochę miałem nadzieje, że @NotteNick się wypowie bo z tego co widziałem używa MCP23017. Odnośnie tematu nowego wątku to za bardzo nie mam pomysłu może “Wemos S2 mini + MCP23017 i komunikaty dotyczące opóźnienia”
Jeżeli chodzi o Twoje uwagi dotyczące mojego problemu to bardzo ciekawe co piszesz. Wczoraj zmieniłem Wemos S2 mini na Wemos D1 i z przełącznikiem TCA+MCP działa super. Żadnych niepokojących komunikatów i stany na wyjściach oraz wejściach MCP są stabilne.
Mam jeszcze zupełnie innego ESP32 i na nim sprawdzę. Jak będzie dobrze to już będę w domu. Nie wiedziałem też, że były takie chocki klocki z MCP. Jednak swoją drogą gdyby były felerne to na 12F też by głupiały. Chociaż, kto wie?
Błąd, który wspominam dotyczył bodajże adresowania układów - errata jest we w miarę współczesnych datasheetach (i tak jest w tym wypadku), ale czasem w przypadkach wykrycia błędów konstrukcyjnych errata do dokumentacji jest wydawana osobno lub wręcz się wcale nie pojawia (np. po zaprzestaniu produkcji).
Ale generalnie tak - sądzę, że to biblioteka ma błędy, a nie same układy, jakkolwiek to co się stało w popandemicznej rzeczywistości, gdy na rynku pojawiło się sporo podzespołów wykopanych nie wiadomo skąd wymaga przyglądania się datom produkcji. (Na rynku detalicznym stare podzespoły nie są niczym specjalnie dziwnym, więc właściwie nie widzę w tym nic szczególnie szokującego)
Tak, warto sprawdzić, jeśli chodzi o S2 to bym szukał issues dotyczących i2c.
Natomiast jeśli chodzi o pomysły to jeszcze można zastosować zewnętrzne pullupy (jeśli stosujesz obecnie wewnętrzne), ale to pewnie już sprawdzałeś.
Zostawiam wnioski po testach. Może komuś się przyda.
Zmieniłem ESP32-S2FN4R2 na ESP-WROOM-32 38PIN i jest zupełnie inaczej. W logach cisza. W dodatku oba kanały i2c spokojnie mogą być taktowane z częstotliwością 100 kHz co było nie do pomyślenia przy S2.
Ponadto wyszła jeszcze inna sprawa. Jak przekładałem układy na płytce testowej to po zmianie na WROOM’a nie chciał mi działać jeden kanał i2c. Kombinowałem na wszelkie sposoby i ostatecznie doszło do wymiany dwóch przewodów połączeniowych. Omomierz nic nie wykazał ale dla pewności nożyczki tak. Z tego względu z ciekawości jeszcze raz będę musiał sprawdzić układ z S2 aby mieć 100% pewność przyczyny tych problemów.
A z WROOM też nie jest wesoło bo układ nie chce mi działać w ustawieniu sieci DHCP. W konfiguracji statycznej jest OK ale po przełączeniu na DHCP nie dość, że się rozłącza to zamula mi całego HA. Teraz szukam czy jest jakaś wersja na rynku, która nie ma tego problemu.
To jest powiedziałbym co najmniej dziwne - u siebie mam kilkanaście różnych ESP, zawsze w konfiguracji DHCP, większość z bindowaniem IP do MACa przez ARP na routerze, ale nie wszystkie, bo porządki w adresach IP robię raz na jakiś czas (więc każdy z nich kiedyś był bez bindowania), no i żaden nie powodował takich problemów (a są to różne konstrukcje kupowane zupełnie losowo - i to praktycznie od ESP8285 po ESP32-S3).
Czy przy radykalnych zmianach konfiguracji usuwałeś te urządzenia z integracji i ponownie dodawałeś je ze zmienionym firmware?
Niestety zmiany konfiguracji firmware często pozostawiają po sobie osierocone wpisy w Integracjach, należy je bezwzględnie usuwać!
Być może OFF TOPIC, ale HAOS 12.2 wprowadza obsługę MPTCP
Drugi OFF TOPIC - jeśli czujesz w sobie żyłkę eksperymentatora, to są jeszcze 2 dość ciekawe konstrukcje.
Obsługa ESP32-S3 esp32-s3 i RPi Pico W rpi-pico-w jest już na dość dojrzałym poziomie, więc są to konstrukcje zdatne do zastosowań gdzie potrzeba dużo GPIO.
Niestety nie śledzę konfliktu między Platfornio, a malinową fundacją, ale jest to w pewnym stopniu przeciwwskazanie w używaniu RPi Pico W, gdyby nie to, to RP2040 jest raczej rozsądnie zaprojektowanym MCU do rozbudowanego DIY.
Powoli dochodzę do porządku z tym ESP32. Dotychczas używałem wyłącznie ESP-12F. Działają od kilku lat bez problemów i nie robiły mi żadnych niespodzianek. Tfu tfu.
Teraz testując tego ESP-WROOM-32 już wiem, że muszę używać stałego IP. Kombinowałem z opcjami use_address: ‘192.168.3.173’, domain: ‘.local’ jednak jedynym sensownym rozwiązaniem byłoby postawienie wewnętrznego nameservera i przypisanie sobie nazw do IP. Za dużo z tym zabawy. Przejdę na statycznie przypisane IP w przypadku tego jednego ESP i już. U mnie akurat będzie potrzebny jak na razie tylko jeden gdyż całość chcę mieć obsłużoną z poziomu jednego ESP. Dlatego zależało mi na dwóch i2c i możliwości rozbudowy o MCP. Jak na razie z małymi zonkami zgodnie z planem.
Nawiasem pisząc teraz to i2c działają mi na taktowaniu 50kHz.
Miodzio.
Nie jest potrzebny własny DNS, wystarczy, że zbindujesz IP do MACa - to ma każdy router nawet najbiedniejszy jako “statyczne adresy z DHCP” nazewnictwo bywa różne, ale jest to zwykłe bindowanie ARP, w tych routerach, które dają możliwość edycji plików konfiguracyjnych zwykle chodzi o plik ethers.
@sindap natrafiłem na bardzo podoby problem. Korzystam z ESP32 moduł WROOM-32D oraz modułu expandera od EasySwitch 128 I/O (8xMCP23017). Podłączonych aktualnie ok 25 lamp czyli 50 wejść/wyjść expandera.
Przy domyślnej konfiguracji I2C (50kHz) w logach miałem dość regularne wpisy Component gpio.binary_sensor took a long time for an operation z czasami rzędu ~1s. Tym wpisom towarzyszyły automatyczne, samoczynne przełączenia niektórych lamp.
Natrafiłem na ten wpis i na razie podniosłem taktowanie I2C do 100kHz i problem wyraźnie zmalał, choć jeszcze wczoraj na nowej konfiguracji przynajmniej raz ten błąd dostałem (za każdym razem przy tym zapala się jakaś losowa lampa).
Wcześniej lampy kontrolowało Arduino Mega i prosty skrypt własnego autorstwa, nigdy nie miałem takich problemów, wszystko działało stabilnie. Gdy przeszedłem na ESPHome to najpierw kod wrzuciłem na ESP8266 ale on nie uciągnie tyle komponentów (za mało pamięci). Był niestabilny, resetował się i wieszał, ale nie robił tych samych problemów z I2C co ESP32 (nie zapalał też samoczynnie lamp).
Co radzicie? Mogę jeszcze wymienić ESP32 na inny egzemplarz, ale mam ten sam WROOM-32D. Jakie jest zalecane taktowanie I2C i jaki ma wpływ na omawiany tu problem? Może powinienem jeszcze podnieść np do 200 albo 400kHz? Z tego co widzę autor wątku leci sobiena 800kHz i chyba wszystko jest ok?
Szczerze, na rozbudowaną konfigurację chyba najrozsądniej byłoby użyć ESP32-S3 (choćby dlatego, że jest całkowicie inny niż stary ESP32 na prockach Extensa) jeśli w ogóle zakładamy, że chodzi o wadliwe działanie MCU
Moim zdaniem tu może być istotna kwestia sprzętowa - pullupy na magistrali powinny być dobrane do jej obciążenia.
Jeśli masz oscyloskop to on Ci pomoże, ale generalnie reguła jest taka, że im więcej urządzeń na magistrali tym mocniejsze pullupy (mniejsza rezystancja).
Zalecane taktowanie jest takie, na jakie pozwala konstrukcja magistrali (tj. jak zaprojektowałeś ścieżki, możesz podnosić częstotliwość do woli, o tylko ile sprzęt da radę ) oraz na jakie zezwalają podpięte urządzenia - myślę że lektura datasheetów wskazana.
Koniecznie na zasilaniu każdego scalaczka powinny się znaleźć kondensatory odsprzęgające.
Tu jest też kwestia pullupów - im wyższa częstotliwość tym mocniejsze pullupy.
Dzięki @szopen ale obawiam się że to nie jest poziom na którym jestem w stanie to “debugować” ani sprzętu, ani skilla, ani czasu. Jestem raczej dość “casual” userem i mogę jedynie pokombinować z konfiguracją esphome. Moduły których używam to gotowce ze sklepu, nic tu sam nie projektowałem, jedynie połączyłem kabelkami
Ciekawostka:
przy częstotliwości 50kHz miałem stabilnie działające ESP, wifi itd, ale problemy z losowo włączanymi lampami (long time to update etc)
100kHz rozwiązało problemy z lampami, ale sam ESP zaczął mieć problemy z wifi i mqtt (zrywanie połączeń, nie odpowiadanie na zapytania http itd)
podniosłem do 200kHz i póki co jest najlepiej - wszystko chodzi stabilnie, nawet loop time skryptu znacząco spadł (przy niższych freq, cały czas ponad 100-200ms, teraz ~60ms)
Trochę mi się to gryzie bo do tej pory raczej trafiałem na porady wskazujące ż częstotliwość I2C czym niższa, tym stabilniejsza (mniej podatna na zakłócenia) i że ogólnie system powinien pracować na tak niskiej jak to możliwe (jak najniższa, dopóki działa dobrze). Nawet GPT / grok tak podpowiada. A tu trochę przeciwnie, podniesienie taktowania rozwiązało moje problemy (chyba?).
W takim razie od tych kabelków też będzie zależało jak to będzie działać.
Ale fizyczne pullupy powinieneś stosować, przy 8 układach na magistrali I2C pullupy wbudowane w MCU mają prawo nie dać rady (szczególnie, że źródło prądowe użyte do ich emulowania jest słabsze w ESP32 niż w ESP8266).
Możesz dojść do tego eksperymentalnie - przygotuj sobie pary rezystorów na pullupy magistrali 10k, 6k8, 4k7, 3k3, 2k7, 2k2 i wymieniając je testuj.
Mówisz tu o pull up na każdym I/O expanderów, czy o magistrali, ew. zasilaniu całego modułu?
Bo jeśli to pierwsze to obawiam się że w moim przypadku będzie to bardzo niewygodne i niepraktyczne - wybrałem moduł od easy switch bo do niego mam przyprowadzone wszystkie skrętki i zarobione na terminalach. Nie wiem jak w ten tor miałbym wpiąć jeszcze rezystory, chyba że istnieją do tego też eleganckie gotowe moduły (ew. zrobić coś swojego, ale na razie to przekracza moje możliwości).
Do samej magistrali lub zasilania coś dołożyć mogę.
Przy czym tak jak wspominałem wszystko działało 100% idealnie bez żadnych problemów z Arduino Mega przez dobre 3 lata. Przesiadłem się na ESPHome z uwagi na większe możliwości, no i dla integracji z HA. Wydaje mi się że sam expander, jego budowa, konfiguracja i podłączenie są poprawne, to sam ESP (lub aktualne parametry w firmware) powodują jakieś zaburzenia lub zakłócenia.
Arduino jest w logice TTL (5V) a ESP LVTTL (3.3V), nie wiem co masz, daj jakieś linki, jestem przekonany, że bez sprzętowych pullupów na magistrali (mogą być przy MCU) będą problemy.
I jeszcze mówisz o jakichś skrętkach… to te ekspandery nie są zamontowane tuż przy MCU?
Moduł umożliwia pracę zarówno w 5V jak i 3.3V. Konfigurację przełącza się zworką na płycie. Oczywiście jak był pod Arduino to pracował na 5V teraz z ESP jest na 3.3
Miałem na myśli skrętki idące od klawiszy ściennych / przycisków - wchodzą one na wejścia expandera (odczyt, INPUT_PULLUP). Sam expander zamontowany jest w szafie tuż obok mikrokontrolera. Przewód połączeniowy I2C ma ~20cm.
Polski producent, możesz go poprosić o wsparcie…
po obrazku płytki drukowanej widzę, że kondensatory odsprzęgające są przewidziane, w ogóle płytka wygląda na zaprojektowaną rozsądnie
Bez schematu więcej nie powiem, ale chyba sam wiesz czy na magistrali I2C (o żadnej innej nie rozmawiamy) są gdzieś te pullupy czy nie.
Ekspandery nie mają izolacji galwanicznej od niczego, więc tu jest też potencjalna przyczyna, że przy 5V to działa dobrze, a przy 3.3V w grę już wchodzi poziom zakłóceń (niestety im niższe napięcia tym logika bardziej podatna na zakłócenia). Można w sumie dać po drodze konwerter poziomów logiki I2C (chyba jakieś przykłady dedykowanych IC są w tym ostatnim dokumencie który linkowałem) i przywrócić zasilanie 5V.
ten układ nie jest często spotykany w rozwiązaniach, przynajmniej w tych co ja widziałem, większość była oparta o PCF8574 albo PCF8575.
. Na ukladach PCF857x z ESP32 oparte są rozwiazania boneIO i Kincony (oba udostępniają pełne specyfikacje sprzętowe rozwiazania), działa, również potwierdzam. Czasami zamiast wymyślać lepiej skopiować to co już działa, Samsung tak właśnie zaczynał 
.
) oraz na jakie zezwalają podpięte urządzenia - myślę że lektura datasheetów wskazana.
ani sprzętu, ani skilla, ani czasu. Jestem raczej dość “casual” userem i mogę jedynie pokombinować z konfiguracją esphome. Moduły których używam to gotowce ze sklepu, nic tu sam nie projektowałem, jedynie połączyłem kabelkami 