Uff, mam tyły w tematach forum. Czas najwyższy na odwiedziny
Piekło zamarzło! Exta Life z dostępem przez chmurę
Szkoda, że tak późno, ale dla systemu dobrze. Aż się dziwię, że coś jeszcze się dzieje w oprogramowaniu EFC-01.
Po włączeniu usługi chmurowej pozostaje jedno połączenie lokalne do kontrolera, więc spokojnie działa integracja @admina.
Czyli że chmura zjada aż 2 połączenia? Bo z tego co pamiętam to kontroler obsługuje aż 3 jednocześnie
Czy zawsze zjada 2 czy tylko gdy ktoś zostawi włączone powiadomienia push? Nigdy nie zrozumiem rozrzutności w wykorzystaniu zasobów tego kontrolera...ale fak, że jak ktoś odpali chmurę, to jedno awaryjne połączenie powinno wystarczyć, a wszyscy niech się łączą przez chmurę.
Druga sprawa, w razie padu chmury nie zalogujemy się już na bramkę lokalnie czy zdalnie (przekierowanie lub VPN).
A dlaczego? Chyba tylko w przypadku gdy ktoś ma włączoną chmurę + integrację z HA?
Zadaję te pytania, ponieważ nie mam możliwości przetestowania tego u siebie z racji tego, że serwis Zamela przy naprawie w 2020 roku zablokował mi możliwość aktualizacji kontrolera i zostałem na sofcie 1.6.4. Nie mogę go zaktualizować ani przez apkę, ani przez USB. Druga sprawa, że i tak nie bardzo mi już ta chmura do czegokolwiek potrzebna. Lokalna kontrola przez HA w pełni mi wystarcza.
ja wiem że mi się za ten pomysł oberwie od kolegi @admin ale miło by było w przyszłości mieć integrację która umożliwia wybrania połączenia z chmurą zamiast zajmowania lokalnego połączenia, by to zostało jako awaryjne.
Ja tam ani nie gryzę ani nie biję
A tak serio to miło by było, ale wg mnie to tylko takie nice-to-have. Zasadą nadrzędną w HA jest kontrola lokalna i ja się tego będę trzymał. Jestem fanem elastyczności w oprogramowaniu i taka opcja integracji przez cloud albo lokalnei byłaby fajna. Jest jednak kilka "ale":
1. Trzebaby przepisać całą warstwę komunikacyjną integracji, bo przypuszczam, że komunikacja przez cloud zrobiona jest zupełnie inaczej. Strzelam w ciemno, bo nie mam tego jak rozpoznać a dokumentacji wiiadomo - nie ma. Duży effort
2. Utrzymywanie integracji wymagałoby wsparcia obydwu dróg komunikacji czyli byłoby trudniejsze i bardziej czasochłonne
3. Z racji braku czasu i braku innych osób do pomocy w pracy nad integracją niestety taka implementacja jest nierealna
Moim zdaniem argument, że trzeba zrobić robić zmiany w integracji, aby odblokować awaryjne połączenie jest tylko częściowo trafiony. Owszem, fajnie by było, ale po prawdzie to sądzę, że Zamel powinien sam zadbać o optymalizcję wykorzystania zasobów kontrolera i aby ich chmura nie zżerała aż dwóch połączeń, wtedy nie byłoby tego problemu. Nie wiem dlaczego wymaga aż tyle, ale powinni zrobić tak, aby wystarczyło jedno połączenie. Jeśli to kwestia wyłączenia push to super - zadowoli się jednym, ale jeśli mimo wyłączenia nadal zjada 2 to kicha. Rozrzutność na maksa
miło by było w przyszłości mieć integrację która umożliwia wybrania połączenia z chmurą zamiast zajmowania lokalnego połączenia, by to zostało jako awaryjne.
Oczywiście po stronie Zamela też musiała by być współpraca i wypuszczenie np API do celów integracji.
Nie bardzo widzę sens takiej konfiguracji. Dlaczego integracja z HA działającym lokalnie miała by komunikować się z kontrolerem będącym w tej samej sieci przez chmurę Zamel'a? Nie ma ułomności integracji admina, jest ułomność oprogramowania Zamela. Trudno wymagać API jak nie ma się podstawowych funkcji komunikacji kontroler - urządzenie końcowe (brak notyfikacji aktualnych stanów). Jeśli tworzy się kontroler w oparciu o bieda hardware (LAN 10Mbps, STM32f429) i udaje, że jest to topowy sprzęt na rynku, to już na starcie projektu mamy ograniczenia.
Święte słowa. W pełni się zgadzam. Zamel tworząc EFC-01 niczego nie nauczył się z poprzedniego projektu czyli EFC-02, który miał być rakietą, a wyszło tak, że góra urodziła mysz. EFC-01 nie dość, że jest na słabym sprzęcie, to jeszcze oprogramowanie układowe szarżuje z wykorzystaniem zasobów czego efektem jest brak wolnych połączeń do kontrolera. Nawet nie będę komentował tego jak wygląda sprawa obsługi tylko 3 połączeń dla aplikacji a do włączeniu cloud tylko 1. Mamy XXI wiek. To możliwości dobre w latach '90 a nie w roku 2022. Zamel storzył sprzęt kompletnie nieodporny na rozbudowę oprogramowania i funkcji. Zero myślenia do przodu na kilka lat.
Więc może zamiast prosić admin'a, zacznijmy wymagać od Zamel'a aby swój projekt uwspółcześnił i otworzył na świat open sourse. Połączenie chmurowe jest dobrym posunięciem dla klienta ale system musi znieść ograniczenia swojego stosowania w logice automatyzacji i otworzyć się na świat, np przez komunikację po MQTT.
MQTT byłoby super w połączeniu z notyfikacjami odbioru sygnałów z nadajników. Zamel nie robi nic, aby Exta Life otworzyć na świat, więc wątpię, że MQTT zostanie dodane do Exta Life. To nie supla, która z założenia jest open source i tworzona / napędzana przez open source. A gdyby nawet dodali MQTT to pewnie zajęłoby ono ostatnie, trzecie połączenie
Chyba, że konfigurowałoby się kontroler tak jak urządzenia w supla - czyli albo mamy cloud, albo lokalne MQTT. Od kilku dni posiadam supla MEW-01 (nigdy nie sądziłem, że jeszcze kupię coś od Zamela, ale z racji niezawodności elektryki w tych urządzeniach zaufałem im, bo soft i tak robi supla a nie Zamel
) i jestem zadowolony, choć kwestię local vs chmura rozwiązali do kitu wg mnie. Shelly robi to znacznie lepiej. Interfejs konfiguracyjny jest w Shelly dostępny zawsze, a nie tylko w specjalnym trybie konfiguracji i połączeniu z lokalną siecią WiFi urządzenia. Nie wymaga to fizycznego dostępu do urządzenia, aby wejść w tryb konfiguracji tak jak w supla. Mam nadzieję, że kiedyś uda im się to zmienić.