W najnowszej wersji HA 2023.8 pojawiają się błędy urządzeń SHELLY
Prawidłowa konfiguracja, problem po aktualizacji,
Czekamy na poprawę 
Problem dotyczy wszystkich moich urządzeń niezależnie od wersji
Ty używasz MQTT ja używam lokalnej integracji + chmura.
Problem jest tylko od wersji 2023.8
na drugiej maszynie przy 2023.7. jest ok
Dodatkowo pojawiło się
Sensory z Zigbee2MQTT
Bo trzeba przestawić COLOT peer z mcast na unicast z odpowednim adresem i portem i działa.
to rozwiązanie jest rekomendowane dla urządzeń bateryjnych, zrezygnowałem z integracji shelly i cloud-a i skonfigurowałem wszystkie urządzenia pod MQTT i jest spokój.
Shelly jak pamiętam nigdy nie wymagało clouda, a opisywany wyżej problem u mnie nie występuje (ale mam tylko jedno ich urządzenie: Plug S, zintegrowany wbudowaną w HA integracją z użyciem CoIoT).
Cześć, czy jest gdzieś (nie mogę znaleźć) jak obecnie skonfigurować Shelly po MQTT? Mam Mosquitto broker, w logach widzę, że Shelly się prawidłowo loguje.Kiedyś miałem zdefiniowany przełącznik MQTT Shelly w configuration.yaml, ale od którejś wersji HA przestało to działać i był komunikat, żeby usunąć sekcje w tym pliku konfiguracyjnym. Nie wiem jak utworzyć przełacznik i sensory. Od czasu zmiany na nowy firmware jest masakra. Opróczy powyższych błędów z dużą częstotliwością następuje odłączanie od sieci Wifi na dokładnie 30 sekund. Może po MQTT będzie lepiej.
Zależnie od sprzętu Shelly są dostępne ułatwiacze życia
gen1
gen2 i gen3
Jeśli nie musisz z jakiegoś konkretnego powodu używać MQTT, to Shelly integruje się z HA bezpośrednio, tj. bez MQTT (tu też zależy jaka generacja)
Dzięki, mam Shelly1 i 2,5. O to chodzi, że do chwili aktualizacji firmare shelly korzystałem z integracji w HA, ale teraz jest masakra z rozłączaniem. Jednego nie zdążyłem zaktualizować i z nim jest OK.
Niestety wersja beta również nie załatwia sprawy, czyli nie ma chyba co liczyć na naprawę w nowej wersji.
Mam tylko plugi gen1 (SHPLG-S)
i na sofcie 20230913-113421/v1.14.0-gcb84623
zero problemów - integracja standardowa przez autowykrywanie (multicast), czyli włączone CoIoT
Jeśli masz problem z multicastem w sieci (np. routery mikrotik), to zamiast mcast wpisujesz tam zgodnie z dokumentacją <IP-of-HA>:5683 czyli przykładowo 192.168.20.50:5683
Oczywiście wszystkie aktualizacje beta-firmware (rc-x) ignoruję, chyba że mam ochotę na eksperymenty, ale do stable żadna sztuka cofnąć.
PS
Tak mi do głowy przyszło, że może nie chodzi o firmware, tylko się posypały kondensatory elektrolityczne w modułach - kilka takich przypadków było zgłaszanych na forum i zawsze dotyczyły modułów (ze sporym przebiegiem) dopuszkowych, gdzie jest problem braku wentylacji i sprzęt się przegrzewa, pomaga wymiana kondensatorów na nowe (lub reklamacja o ile stało się to dostatecznie wcześnie).
Osobiście do każdego zakupionego Shelly wgrywam ESPHome i zapominam o problemach .
@szopen zgadza się, unicast rozwiązuje temat błędów push oraz przerw za pomocą integracji Shelly w HA. Niestety mam również testowy HA, więc na nim nadal pozostaje problem.
Docelowo pozostaje MQTT lub integracji Shelly z HACS.
Nie mogę sobie poradzić nadal z MQTT. Uruchomiłem skrypt MQTT dla Gen1, utworzyłem wymagane automatyzacje. Automatyzacje uruchamiają się prawidłowo, Shelly prawidłowo loguje się do brokera MQTT. Nie widzę jednak nowego urządzenia Shelly MQTT. Nie wiem co dalej.
To znaczy, że masz problem z konfiguracją swojej sieci LAN.
Nie używam Shelly w ten sposób, a nie mam czasu na zabawę, może ktoś inny coś podrzuci.
Ok, dzięki.
jeśli chodzi przyczynę, to obecny wątek i wiele zagranicznych świadczą to tym, że problemem jest najnowsza wersja firmware i wiele osób się z tym zmaga (przynajmniej w zakresie push urządzenia). Poprzednio ustawienie mcast nie powodowało problemu.
No to zobacz czy możesz zrobić downgrade poniżej aktualnej wersji stable.
http://archive.shelly-tools.de/
(w ogóle to zakładam, że nie jesteś na żadnej wersji RC/beta tylko na stable, bo dużo ludzi świerzbią palce i są na wersjach eksperymentalnych…)
Nie rozumiem czemu nie podajesz żadnych konkretów umożliwiających przyjrzenie się twojemu problemowi przez kogoś kto nie ma identycznego sprzętu (brakuje kodów modeli oraz konkretnych wersji firmware, które masz zainstalowane).
PS
Aby HA nie informował o wersjach beta, co zmniejsza świerzbienie palców, bo nie proponuje aktualizacji do RC/beta warto wyłączyć zbędną encję aktualizacji beta
jakkolwiek cofnięcie się z beta do stable nie jest jakimś hardkorem i jest do wykonania z GUI Shelly
jak widać mimo, że aktualne stable jest starsze to można zaktualizować do niego z bety
zatem - próbowałeś downgrade?
przy robieniu SS nie przewinąłem listy, ale jest też 1.13, 1.12 itd.
UWAGA to jest nieoficjalny serwis i mimo linkowania do oficjalnych zasobów downgrade niesie ryzyko uwalenia sprzętu, więc testuj na jakimś mało istotnym module, proponuję też go najpierw odłączyć od chmury.
Nie wiedziałem, że jest taka możliwość. Wypróbuję.
Niestety coś mi nie poszło przywrócenie starszych wersji. Jakoś bardzo szybko zmienia się wersja na urządzeniu (obserwowałem w drugim oknie nie ma żadnego inicjowania). Efekt jest taki, że urządzenie wskazuje że jest starsza wersja, ale np. znika opcja CoIoT. Na razie przywróciłem aktualną wersję i ustawiłem unicast. Po dłuższej obserwacji widzę, że wprawdzie sytuacja uległa znacznej poprawie w stosunku do multicast, ale nie do końca problem zniknął. Przy multicast rozłączanie było nawet co kilka minut, obecnie jest to 2-3 razy na dobę.
Być może faktycznie problem dotyczy ustawień w sieci. Teraz sobie przypomniałem, że u mnie aktualizacja shelly zbiegła się z wymianą routera. Obecnie mam router światłowodowy z Orange. Być może to powoduje problem. Wprawdzie z dokumnentacji wynika, że problemy z CotoT mogą występować przy zdefiniowanych vlan-ach, u mnie nie ma ich.