On 26/03/2023 13:18, Mirek wrote:
>> A co konkretni robi, czego HA nie potrafi?
> Więc nie u używasz w swoim HA NR?

Nie. Uważam języki imperatywne za wygodniejsze, ale to subiektywna
opinia związana z wykonywanym zawodem.

>  moim przypadku 1 i 2 są zbędne.
>> A moim nie. Z uwagi na bezpieczeństwo, dostęp do innych usług (nas,
>> zdalny pulpit).
> No można dyskutować. Co się może stać jak ktoś ci zabierze (odblokowany)
> telefon?

Nic.

a) jest zablokowany pinem i niebezpieczeństwo jest takie samo jak to,
gdy masz tam abonament na redtube. Jeśli ktoś odbierze mi odblokowany,
to tak samo mogę płakać, że obajrzy moje filmy i zdjęcia. Myślę, że
jakiś miliard ludzi ryzykuje to codziennie.
b) nie jest rootowany
c) każdy członek rodziny ma osobny certyfikat
d) dowolny cetryfikat mogę zdeaktualizować, zdalnie.
e) całośc tej procedury jest chroniona hasłem
f) przeciętny złodziej ma w d... co masz na telefonie, chodzi tylko o
sprzedaż
g) gdybym miał paranoję mogę spokonie VPN postawić na haśle, tylko że
nie mam (tej paranoi)

A co jeśli ktoś, o muj bosze, odbierze Ci telefon (odblokowany) z Twoją
aplikacją i magicznym pośredniczącym brokerem?

> A co jeśli będą ddos-owani portmap.io?

To samo, jak akurat będzie darmowe porno na steamie, hadkor wspinający
się po drucie od internetu, albo kot nasika na rozdzielkę na słupie, na
sąsiedniej ulicy.

Czyli nic z punktu widzenia automatyki.

Dlaczego uważasz, że to zdalne łącze musi działać 24/dobe z 100%
pewnościa? To, co ma być pewne, pracuje w intranecie. Dostęp zdalny jest
tylko dodatkiem umilającym życie i ma nie wpływać na całośc systemu.

Jak bym chciał mieć zdalne ze 100% dostępem to po prostu podpiął bym do
domu kilka łącz internetowych, dorzucił UPSa i generator diesla w
ogródku, postawił kilka budek strażniczych i w ten sposób dostał w miarę
pewne spuszczanie wody w kiblu jednym kliknięciem z telefonu.

Tylko że to nie jest potrzebne. Znaczy, mi nie jest. Nie wiem jak reszcie.

> Może oberwać również twoja sieć i
> padnie ci sterowanie wewnątrz...

Może. Dzięki temu nie spuszcze wody w kiblu z appki.

Ale ale. A jak Ci padnie ten twój zewnatrzny broker? A jak padnie
internet w domu? A jak kot nasika na komputer? To mi jak padnie, to
problem, a jak Tobie padnie, to nie ma problemu?

Twoje rozwiązanie ma wszystkie wady mojego + dodatkowo jakieś absurdalne
zewnętrzne brokery ch... wie po co.

> przecież vpn-a masz na innym urządzeniu niż HA, a portmap chroni twoje
> połączenie przed tym... ale czy na pewno?

portmap nie chroni *NIC*. Ma w nosie, czy lata tam goły tekst, http czy
szyfrowane portole po torrentach. On nie wie i nie dba o to.

To ja mam cała kontrolę nad tym, co lata po portmapie. On tylko
przekierowuje porty między połaczeniami i nic więcej nie robi. Ja
zestawiam bezpieczne połaczenie, z certyfikatami, kluczami itd itp. To
ja okreslam poziom bezpieczeństwa tego połaczenia i tylko ja za nie
odpowiadam.

>> 1) MQTT jest mało bezpiecznym protokołem z definicji
> Bzdura. Można (i powinno się) użyć szyfrowania SSL, czyli to samo co
> openVPN

1) to nie kwestia szyfrowania w internecie
2) to kwestia tego, że IoT to jeden z najgorszych przykładów inzynierii
programowania, pisany przez programatorów embedded, dla których
przepełnienie bufora na ARM7 to ficzer a nie bug. Ilość niebezpieczeństw
zwiazanych z obsługą MQTT w małym urządzeniu w ścianie jest przeogromna,
wliczajac zdalne wykonanie kodu, DDoS w sieli lokalnej itd itp. A Ty
wesoło wystawiasz MQTT do internetu i nie martwisz się, że ktoś go
przejmie i zacznie wysyłać w nim ramki z payload do Twojego wyłącznika w
ścianie?

Innymi słowy masz wybiórcze problemy z bezpieczeństwem z uwagi na to, że
starasz się je zastosować do najmniej sensownego miejsca ale za to
widzisz niebezpieczeństwa tam, gdzie rozwiązaliśmy je 40 lat temu.

>> 2) Sam broker nic nie daje, trzeba jeszcze jakieś GUI do niego
> No i bardzo dobrze, bo sobie zrobię GUI jakie chcę i do tego dostosowane
> do możliwości i potrzeb użytkownika. Inne dla dziadka a inne dla wnuczka.

To zupełnie jak w HA. Moje dzieci mają inne GUI niż ja.

>> To po co ten zewnętrzny broker?
>> Ja jeszcze rozumiem, jak być integrował kilka systemów, typu zapalenie
>> światła w altance w Grudziądzu powoduje spuszczenie wody w kiblu na
>> Majorce. To tak. Ale chyba nie masz takiego systemu.
> Ja nie mam, ale mój klient ma.

I po co ma?

> Z resztą wytrącę ci ripostę z ręki i
> powiem za ciebie, że na VPN-ie można zrobić to samo. No można, ale
> trzeba go na czymś postawić, a w tej altance w Grudziądzu nie ma na czym.

Widzę że dalej unikasz odpowidzi w temacie *PO* *CO* ten zewnętrzny
broker i kosmiczna kombinacja z jego synchronizacją z jakims innym.

Napisz w końcu po co to zostało zrobione, aby się nie okazało, że
bronisz po prostu bezużytecznej tezy jakiegoś klienta, co do którego
zaczynam mieć wątpliwosci, czy w ogóle istnieje.

>> Nie jest oczywisce co Ci daje ten zewnętrzny broker, poza przesadną
>> komplikacją całości systemu,
> Jaka komplikacja? Broker w środku i tak jest. Bridge to dwie linijki w
> konfiguracji plus wgranie certyfikatu jeśli masz self-signed.

I dalej nie odpowiedziałeś na pytanie: po co on jest.

Dodatkowo podpowiem Ci, że taki "zewnątrzny broker" po spięciu z innym
jest jak dziecko we mgle. Co ma robić, na jakie zdarzenia się zapisać, a
może ma duplikować? A może nie chcesz duplikować częstotliwosci
spuszczania wody w obawie przed ruskimi hackerami? To trzeba okresli co
ma w nim być a co nie.

Ojej, to dwa kliknięcia aby uzyskać bezużyteczny klawałek ficzera który
wymaga potem jeszcze tony konfiguracji.

Bo, przypominam, dalej nie powiedziałeś po co to w ogóle potrzebne.

Bo jeśli tylko do duplikacji, to uważam to za prześmieszne zakończenie.

>  probemami z synchronizacją,
> Jakie problemy? Wytłumacz mi gdzie widzisz problem.

1) Po utracie połaczenia internetowego, zewnętrzny broker nie ma zdarzeń
z intranetu. Nie jest zsychronizowany.

2) Jak już się pojawi, po kilku godzinach, to musisz synchronizować
wszystkie zdarzenia pomiędzy nimi, aby mieć spójny obraz tego co się
działo i jaki jest stan obecny

3) Może to 2) olać i mieć byle co poskładane na kolanie.

Dostep przez siec do HA nie ma takich problemów: nie ma co
synchronizować, stan w HA jest spójny ze stanem brokera, bo miedzy nimi
połaczenie ma znacząco mniejsze szanse na zniknięcie, pracują przecież w
tej samej maszynie.

Wyjaśni mi gdzie jest zaleta Twojego rozwiązania.

>  dodatkową
>> apliakcją.
> A co za różnica czy dodatkowa czy wciśnięta w pakiecie?

Dość spora: ja, dzięki temu że HA w domu, na kompie, na TV i w
telefonie, gdziekolwiek jestem, jest identyczny, robię to raz.

Ty:
1) robisz jakies absurdalne kombinacje z dodatkowym MQTT
2) tworzysz lub znajdujesz jakąs aplikację do obsługi tego dodatkowego MQTT
3) konfigurujesz to jeszcze raz dla tej apliakcji
4) ale nie możesz w niej opisać automatyzacji, bo przeciez co jak się
rozładuje telefon, więc piszesz je na schowanym wstydliwie HA
5) Masz zdesynchronizowany system robiony na kolanie, który po awarii
internetu nie wie, czy światło się świeci czy nie
6) Dalej nie potrafisz wyjasnić po co komu takie dziwaczne pomysły

> Chyba, że postulujesz wyższość interfejsu http nad apką... no co kto
> lubi, ale apka IMHO jednak wygodniejsza.

HA w telefonie jest tak samo wygodne jak na PC, przez stronę.

Zaryzkuję, że widząc odpalony HA na telefonie nie byłbyś w stanie
stwierdzić, samą obserwacją, czy masz do czynienia ze stroną czy aplikacją.

Ja nie postuluje wyższości http nad app. Ja w ogóle nie widzę różnicy w
tym wypadku.