Dzięki, jutro obadam temat.
Edit:
Jasna sprawa.
Z załączonych materiałów przez kolegę Szopena wynika, że w przypadku korzystania z ZHA, zwiększenie mocy dongla dotyczy jedynie routera a nie koordynatora.
@szopen słuszna uwaga aby jednak obniżyć moc koordynatora. Przetestowałem i ustawiłem na -5dBm i routery miały problem z połączeniem więc raczej muszę ustawić więcej.
Dałem koordynator na przedłużaczu USB, nic to nie zmieniło, jedynie tyle że czujka Garderoba rozłączyła mi się.
Dla testów zamontuje antenę 9-12dBm i przetestuje co to da, obecnie jest 5dBm.
Czy wiesz jak działa antena 9dBi w porównaniu do anteny 5dBi?
Mam na myśli charakterystykę promieniowania, bo tak naprawdę tylko ona się zmienia - masz inny kształt wiązki i z tego wynika zysk
(pomijam w ogóle kwestię czy to po prostu sprzedawca domalował zbyt wysoką cyfrę by naiwni kupowali to samo inaczej opisane).
I ostatnia kwestia: dB to skala logarytmiczna
dBi (miara zysku anteny) to inna jednostka od dBm - literka “i” pochodzi od anteny izotropowej - takiej idealnie bezkierunkowej o kulistej charakterystyce (nie istnieją takie w rzeczywistości, ale to jest właśnie poziom odniesienia, rzeczywiste anteny zawsze mają niezerowy zysk, bo ich charakterystyka nie jest kulista)
Tu uwaga zysk anteny miewa 2 różne jednostki dBi i dBd (tym razem “d” od dipola półfalowego, który sam z siebie ma zysk 2.15dBi i jest świetną anteną odniesienia do celów pomiarowych), jest to pole do popisu sprzedawców którym zysk przyrasta na papierze zupełnie z niczego.
Natomiast “m” w dBm to odniesienie do 1mW (a antena nie ma mocy, moc ma nadajnik, dlatego jednostki są inne, bo dotyczą czegoś innego).
-5dBm to 0.3mW
20dBm to 100mW
zmieniając moc o 25dBm zmieniasz ją 300x
PS
Pokazałem wyżej przykładowo -5dBm bo to jest moja instalacja testowa, w której celowo zmniejszyłem moc tak by zasięg koordynatora pokrywał tylko jeden pokój (antena jest o zbyt dużym zysku prawdopodobnie koło 5dBi).
Zigbee wymaga komunikacji 2-kierunkowej, więc zwiększanie mocy wypromieniowanej niewiele daje jeśli jakieś urządzenie “słyszy”, ale samo nadaje zbyt słabo by usłyszał je koordynator, więc w zasadzie regulacja mocy ma sens jedynie w celu dopasowania anteny.
Dzięki @szopen za dokładne wyjaśnienie. W takim razie albo umieścić w każdym pomieszczeniu po jednym urządzeniu z routerem, np. w przełączniku do świateł, albo rozwiązanie, które zaproponował @rafkan .
Ja dopiero zaczynam przechodzenie z bramek Tuya i Xiaomi na bezpośrednią… słuchałem gościa: https://youtu.be/S59UlboptaM i mówił tam o problemach w pośredniczeniu przekazywania sygnału niektórych urządzeń z rodziny Xiaomi/Aquara a widzę, że na screenie masz takowy czujnik. Jeśli tak zapewne pomogło by jak byś użył w pobliżu tego czujnika gniazdka Xiaomi. Mówił pozytywnie o urządzeniach IKEA, które również dobrze sobie radzą ale nie wiem czy dadzą radę z Xiaomowymi urządzeniami.
Mówił również o tym, żeby zacząć parować urządzenie na miejscu docelowym aby od razu podłączyło się do źródła o silniejszym sygnale ponieważ niektóre urządzenia nie potrafią się potem przepiąć na inne.
Obejrzyj może znajdziesz tam odpowiedź na swój problem.
Ja kupiłem skyconnect a widzę, że chciałbym używać zigbe2mqtt ponieważ wolę bardziej uniwersalne zastsowania i możliwe, że będę musiał pisać sterowniki pod nieobsługiwane czujniki (mam np.: tuya sprinkler czy jakieś do sterowania roletami).
Ciekawi mnie czy ten w skyconnect w trybie mqtt2zigbee działa tak samo jak w sonofie? Tam chyba koleś mówił, że jak się Home Assistant restartuje to sonof cały czas rejestruje zmiany stanów urządzeń czyli pewnie kolejka mqtt jest chyba zaimplemetnowana na gwizdku?
Jakie urządzenie polecacie (zigbee2mqtt)?
Chyba obejrzę ten filmik jeszcze raz 
@Cebik
Mylisz się w wielu miejscach, więc może nie doradzaj innym.
Wprawdzie nie oglądałem, ale twoje streszczenie jest z grubsza OK (w kwestiach praktycznych), to chyba jednak nie masz zielonego pojęcia jak to wszystko działa…
Może w skrócie - jeśli firmware routera działa niepoprawnie, to ten router nie działa jak należy (więc dodawania sprzętu Xiaomi zasilanego sieciowo, jeśli to on nie działa prawidłowo nie poprawi sytuacji), nie ma znaczenia jaki jest producent, ważne jest czy firmware ma napisane poprawnie.
Zigbee jako standard miał być hardware agnostic, czyli zapewniać kompatybilność wypustów dowolnego producenta w warstwie sprzętowej (i to się prawie udało), więc można używać routerów dowolnego producenta o ile tylko działają poprawnie.
W warstwie sprzętowej urządzenia nie rozróżniają producenta, więc jest im obojętne jakiego producenta masz routery w sieci kratowej byleby działały prawidłowo.
Sytuację tu jednak komplikuje fakt, że standard miał być zgodny wstecz i wprzód, ale to się nie do końca udało. O ile takie firmy jak Ikea czy Philips/Signify zadbały o aktualizacje firmware każdego swojego starego sprzętu (nazwijmy go umownie Zigbee 1.x), to wielu innych producentów olało ten temat (lub dostarczyło aktualizacje tylko do części swoich wypustów) lub wręcz olewa bieżące poprawki błędów.
Kolejna kwestia to zwalone firmware w urządzeniach końcowych (tych które nie chcą się przepiąć do innego routera, choć powinny), dlatego budowa sieci od koordynatora i routerów od środka w kierunku na zewnątrz, a na końcu dołączanie urządzeń końcowych jest prawidłowym obejściem problemu (skoro producent nie zapewnia im aktualizacji firmware…).
Z punktu widzenia dongla nie ma czegoś takiego jak tryb MQTT czy jakiś inny, on zawsze pracuje tak samo… (o ile mówimy o jego firmware realizującym funkcję koordynatora Zigbee).
Koordynator (NCP) jest TYLKO “modemem” Zigbee natomiast funkcje bramki realizuje zawsze zupełnie inny procesor wraz ze swoim oprogramowaniem.
W przypadku bramek zamkniętych systemów jest to jakiś MCU wraz z jakimś oprogramowaniem i często automatyką wypchniętą poza taką cieniutką konstrukcję do chmury.
W przypadku restartu takiej bramki zdarzenia w trakcie restartu nie zostaną zarejestrowane, ani lokalnie, ani w chmurze.
W przypadku Integracji ZHA tym oprogramowaniem jest zigpy będący podprocesorem HA - dlatego restart HA, który odbywa się w niezerowym czasie ma wpływ - zdarzenia które się odbędą w trakcie restartu HA nie zostaną zarejestrowane. Na dostatecznie szybkim sprzęcie restart HA trwa najwyżej kilka sekund, na starej malinie swego czasu restart HA trwał koło 2 minut więc taka przerwa mogła mieć kluczowe znaczenie (szczególnie, że HA restartujemy stosunkowo często).
W przypadku integracji za pomocą serwera Zigbee2MQTT przy restarcie HA nie restartujesz ani kontenera z brokerem, ani serwera Z2M, dlatego restart samego kontenera HA nie ma znaczenia, bo to broker MQTT przechowuje te zdarzenia do czasu gdy HA będący klientem MQTT połączy się z nim ponownie. Ale jeśli zrestartujesz całą maszynę zamykając serwery Z2M i broker, to przez czas, gdy są one wyłączone zdarzenia nie będą rejestrowane. Zasadniczo poza aktualizacjami OSa nie restartujemy maszyny.
Podobne przerwy wystąpią tez podczas aktualizacji dowolnego z uczestniczących w tworzeniu bramki serwerów czyli Z2M oraz brokera MQTT (ale aktualizuje się je stosunkowo rzadko - Z2m z raz 2x na m-c a broker to już ekstremalnie rzadko).
Pisałeś, że masz Skyconnect, uważam że jest świetny do pracy z Z2M (o ile masz w nim firmware NCP) oczywiście o ile nie zintegrujesz go z ZHA, bo dany koordynator może współpracować tylko z jednym serwerem…