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.
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ł 
.