W dniu 2023-03-25 o 22:41, Mirek pisze:
> On 25.03.2023 22:13, titanus wrote:
>
>> I to też: "codzienna, szybka obsługa" - nie mam takiego fetysza,
>
> Ja też nie mam, ale w końcu po to to jest: można jak ktoś już napisał
> włączyć ogrzewanie, otworzyć bramę śmieciarzowi, wyłączyć chwilowo
> podlewanie, bo akurat wracamy i nie chcemy mokrego samochodu czy ubrania
> itp. Gdzieś pisałem, że z kolei do bramy pilot jest wygodniejszy od
> apki... bo jest, ale znowu nie 50-cio przyciskowy.
>

Nie wykorzystuję i nie zamierzam wykorzystywać HA do niczego więcej niż
do LOKALNEGO sterowania i EWENTUALNIE zdalnego PODGLĄDU. W sytuacji
krytycznej conajwyżej mogę przy jego POMOCY dokonać jakiegoś resetu czy
innej niezbędnej interakcji, a tak ma to wszystko załatwić sam.

Jak mam to klarowniej wyjaśnić ?

Dla mnie synonim Home Assistant zawiera się DOKŁADNIE w tym
stwierdzeniu. Gdyby nazywał się Cloud Assistant - wtedy kierunkowo
wymyślałbym mu funkcjonalności z tym związane.

Nie potrzebuję tu JARVIS'a.

--
Pozdrawiam - titanus

do góry

On 26.03.2023 10:49, titanus wrote:

> Dla mnie synonim Home Assistant zawiera się DOKŁADNIE w tym
> stwierdzeniu. Gdyby nazywał się Cloud Assistant -

Ale może się określ co to jest Home Assistant, bo to jest nazwa własna
systemu... który jak wykazał heby nie używa z resztą żadnej chmury, więc
o co tyle krzyku?

--
Mirek.

do góry

On 26.03.2023 00:43, heby wrote:


> Pytasz po co jest język programowania w automatyce? Aby była automatyką
> a nie monitoringiem.

Nie, zmierzam do tego. że Node-RED robi to, czego HA nie potrafi.
>

> W moim wypadku to 3 kliknięcia w telefonie:
> 1) Otworzyć OpenVPN
> 2) kliknąc Connect
> 3) Otworzyć HA
>
W moim przypadku 1 i 2 są zbędne.


> W Twoim rozwiązaniu z jakimś zewnętrznym brokerem MQTT internet jest
> niezbędy, tylko nie wiadomo po co bo jak na razie nie przedstawiłeś
> śladu zalety

Skup się:
Wewnątrz jest cała automatyka i broker. Z resztą nie tylko broker, bo
nie wszystkie urządzenia działają po MQTT. Ten broker łączy się do
publicznego funkcją bridge. Jak się nie połączy to całość działa
normalnie - czy to nie jest oczywiste?

Nie wiem skąd ci się wzięło, że chcę urządzenia w domu łączyć przez
broker w internecie i nie wiem co z tego wynika - uważasz mnie za debila?
.
> 3) Suweren nie musi mieć automatyzacji, to nie dla niego.
>
Ale chce i płaci.


> A VPN przyda się do wielu innych rzeczy.

Suwerenowi?

--
Mirek.

do góry

W dniu 25.03.2023 o 21:31, titanus pisze:

>> No to jeszcze problem z apką na smartfona, która trzyma cały czas
>> połączenie z CU i reaguje na alarmy/eventy.
>
> Co wy z tymi apkami ?? - A jak napiszę, że nie chcę apki, a jedynie
> dostęp do serwera HTML na CU z "zewnątrz"? - Po co utrudniać sobie życie ?

Dla mnie, sens smart home, to przede wszystkim apka. To jak pilot +
kontrola tego, co się tam odjaniepawla. Każdy krok całego systemu mam
zawsze przy sobie i do wglądu. Interfejs www traktuję tylko do samej
konfiguracji a późniejsze działanie kontroluję apką, nie przez www, bo
to upierdliwe. Gdybym opierał się tylko na www to praktycznie nawet bym
tego nie używał bo po co? Smart home bez apki to nawet nie półprodukt.
To można (bez apki) zrealizować w systemie rozproszonym i działa dobie
swoim życiem, bez żadnej kontroli ale dla mnie to bez żadnego sensu.

>> Przeglądanie historii w apce też bym implementował+oczywiście
>> wszystkie możliwe odczyty, sceny, skrypty, dlatego wskazałem na Supla,
>> która ma to już rozwiązane w sensie, ze masz gotowce ale możesz sobie
>> samemu nawydziwiać do woli.
>>
> Historię - z tego co pomyślałem - potrzebuję jedynie na logi z
> licznika/ów energii i co najwyżej alarmy oraz eventy (wykonano -
> powiedzmy do 3 dni wstecz).

Liczniki energii, też będziesz pisał? To proste nie jest a są gotowce,
opracowane, działające. Masz przykład Zamela, gdzie praktycznie wszystko
zostało już zrobione:

https://supla.zamel.com/

> Tak więc przeglądanie historii - nie musi byś w żadnej apce.
> Serwer html w CU czyta z logów na dysku zewnętrznych jakiś częściowy
> zestaw danych - wrzuca go na czas przeglądania do lokalnej pamięci, i
> wyświetla userowi we wcześniej wybranje formie. Po zakończeniu sesji
> czyści pamięć z danych i szlus. :D
>
U mnie apka robi jako alarm, kontrolując wszystko co mogę. Drzwi,
czujniki ruchu, bariery podczerwieni, kamery, włączniki, klapy, furtki,
bramy, temperaturę, wilgotność, wiatr, CO i oczywiście możliwość
sterowania tym wszystkim, pomimo że cały system tworzy pełną autonomikę
w sensie, że od różnych zdarzeń, ustalają się różne rzeczy. Liczniki
energii podają mi dokładnie co chcę, nawet w złotówkach i przede
wszystkim historię, stąd mogę ocenić czy coś mi wyżera za dużo czy nie w
danej chwili a nie po zapłaceniu rachunku...itd

Kliknij w linka, zobacz produkty i się zastanów, czy sam chcesz to pisać
od początku.
--
LordBluzg(R)??
<<<?i? ć?d?? i Putina i ęjcaredefnoK>>>

do góry

On 26/03/2023 11:54, Mirek wrote:
>> Pytasz po co jest język programowania w automatyce? Aby była
>> automatyką a nie monitoringiem.
> Nie, zmierzam do tego. że Node-RED robi to, czego HA nie potrafi.

A co konkretni robi, czego HA nie potrafi?

Zanim odpowiesz, zauważ, że HA obslugiwac mozesz równiez językiem
imperatywnym, np:

https://www.home-assistant.io/integrations/python_sc
ript/

>> W moim wypadku to 3 kliknięcia w telefonie:
>> 1) Otworzyć OpenVPN
>> 2) kliknąc Connect
>> 3) Otworzyć HA
> W 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).

>> W Twoim rozwiązaniu z jakimś zewnętrznym brokerem MQTT internet jest
>> niezbędy, tylko nie wiadomo po co bo jak na razie nie przedstawiłeś
>> śladu zalety
> Skup się:
> Wewnątrz jest cała automatyka i broker. Z resztą nie tylko broker, bo
> nie wszystkie urządzenia działają po MQTT. Ten broker łączy się do
> publicznego funkcją bridge.

Tak, ale dalej nie wyjasniłeś po co komu zewnętrzny broker.

1) MQTT jest mało bezpiecznym protokołem z definicji
2) Sam broker nic nie daje, trzeba jeszcze jakieś GUI do niego
3) punkty 1) i 2) załatwia HA.

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.

> Jak się nie połączy to całość działa
> normalnie - czy to nie jest oczywiste?

Nie jest oczywisce co Ci daje ten zewnętrzny broker, poza przesadną
komplikacją całości systemu, probemami z synchronizacją, dodatkową
apliakcją. A jak padnie internet jesteś tak samo w d... jak z HA
dostepnym przez internet. Gdzie te zalety?

> Nie wiem skąd ci się wzięło, że chcę urządzenia w domu łączyć przez
> broker w internecie i nie wiem co z tego wynika - uważasz mnie za debila?

Uważam, że z jakiejś przyczyny, która jest niewypowiedziana do teraz,
masz zewnętrzny broker. Dalej drążę temat abyś w końcu udowodnił co on
daje "lepiej" niż HA dostępny na OpenVPN.

>> 3) Suweren nie musi mieć automatyzacji, to nie dla niego.
> Ale chce i płaci.

I może kupić sonoffy, Tuye, Xiaomi, Philipsy i inne chmurowe guano. Mam
sąsiada, ogarnał sam zapalanie światełka w ogródku z apki. Jest szczęśliwy.

>> A VPN przyda się do wielu innych rzeczy.
> Suwerenowi?

Też. Ku mojemu zaskoczeniu, po 3 latach pracy zdalnej, nawet suweren
zaczyna zastanawiać się jak zrobić, żeby dało się pracować na kompie w
domu, jak się jest w kiblu na dworcu w Koluszkach.

Prawdopodobnie dlatego, że VPN na domowym routerze to obecnie czynnośc
nie przekraczająca pojmowania tumanisty po filologii.

do góry

On 26.03.2023 12:09, heby wrote:

> A co konkretni robi, czego HA nie potrafi?
>
Więc nie u używasz w swoim HA NR?

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?
A co jeśli będą ddos-owani portmap.io? Może oberwać również twoja sieć i
padnie ci sterowanie wewnątrz... a to już niefajne... ale zakładam, że
przecież vpn-a masz na innym urządzeniu niż HA, a portmap chroni twoje
połączenie przed tym... ale czy na pewno?


> 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

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

> 3) punkty 1) i 2) załatwia HA.

ta, raz i dwa to trzy, a trzy oznacza tajemnicę ;)

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


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

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

dodatkową
> apliakcją.

A co za różnica czy dodatkowa czy wciśnięta w pakiecie?
Chyba, że postulujesz wyższość interfejsu http nad apką... no co kto
lubi, ale apka IMHO jednak wygodniejsza.

--
Mirek.

do góry

W dniu 2023-03-26 o 11:28, Mirek pisze:
> On 26.03.2023 10:49, titanus wrote:
>
>> Dla mnie synonim Home Assistant zawiera się DOKŁADNIE w tym
>> stwierdzeniu. Gdyby nazywał się Cloud Assistant -
>
> Ale może się określ co to jest Home Assistant, bo to jest nazwa własna
> systemu...

<cit>
Tłumaczenie z języka angielskiego - Home Assistant to bezpłatne
oprogramowanie typu open source do automatyki domowej zaprojektowane
jako centralny system sterowania inteligentnymi urządzeniami domowymi z
naciskiem na lokalną kontrolę i prywatność.
</cit>

> który jak wykazał heby nie używa z resztą żadnej chmury, więc
> o co tyle krzyku?
>
...chyba o to, że prawie każdy chce mi "wcinąć" do tego właśnie ZDALNE
zarządzanie, a jak sam opisałem to w temacie i rootpoście, chcę właśnie
skonstruować to tak, żeby samo działało lokalnie.

--
Pozdrawiam - titanus

do góry

W dniu 2023-03-26 o 12:01, LordBluzg(R)?? pisze:
> W dniu 25.03.2023 o 21:31, titanus pisze:
>
>>> No to jeszcze problem z apką na smartfona, która trzyma cały czas
>>> połączenie z CU i reaguje na alarmy/eventy.
>>
>> Co wy z tymi apkami ?? - A jak napiszę, że nie chcę apki, a jedynie
>> dostęp do serwera HTML na CU z "zewnątrz"? - Po co utrudniać sobie
>> życie ?
>
> Dla mnie, sens smart home, to przede wszystkim apka. To jak pilot +
> kontrola tego, co się tam odjaniepawla. Każdy krok całego systemu mam
> zawsze przy sobie i do wglądu. Interfejs www traktuję tylko do samej
> konfiguracji a późniejsze działanie kontroluję apką, nie przez www, bo
> to upierdliwe. Gdybym opierał się tylko na www to praktycznie nawet bym
> tego nie używał bo po co? Smart home bez apki to nawet nie półprodukt.
> To można (bez apki) zrealizować w systemie rozproszonym i działa dobie
> swoim życiem, bez żadnej kontroli ale dla mnie to bez żadnego sensu.
>
No dobrze - może inaczej: gdzie napisałem, że chcę SMART home ?

>>> Przeglądanie historii w apce też bym implementował+oczywiście
>>> wszystkie możliwe odczyty, sceny, skrypty, dlatego wskazałem na
>>> Supla, która ma to już rozwiązane w sensie, ze masz gotowce ale
>>> możesz sobie samemu nawydziwiać do woli.
>>>
>> Historię - z tego co pomyślałem - potrzebuję jedynie na logi z
>> licznika/ów energii i co najwyżej alarmy oraz eventy (wykonano -
>> powiedzmy do 3 dni wstecz).
>
> Liczniki energii, też będziesz pisał? To proste nie jest a są gotowce,
> opracowane, działające. Masz przykład Zamela, gdzie praktycznie wszystko
> zostało już zrobione:
>
Z wykształcenia i zawodowo jestem elektrykiem, informatykiem i
automatykiem. Nie widzę w tym przypadku żadnego problemu:
Przekładnik z odpowiednią klasą, jakiś znośny A/D + wzór obliczeń
uwzględniający zmienne. To dla 3 faz i dużych obciążeń.
W przypadku 1-fazowych jest jeszcze prościej.


> https://supla.zamel.com/
>
>> Tak więc przeglądanie historii - nie musi byś w żadnej apce.
>> Serwer html w CU czyta z logów na dysku zewnętrznych jakiś częściowy
>> zestaw danych - wrzuca go na czas przeglądania do lokalnej pamięci, i
>> wyświetla userowi we wcześniej wybranje formie. Po zakończeniu sesji
>> czyści pamięć z danych i szlus. :D
>>
> U mnie apka robi jako alarm, kontrolując wszystko co mogę. Drzwi,
> czujniki ruchu, bariery podczerwieni, kamery, włączniki, klapy, furtki,
> bramy, temperaturę, wilgotność, wiatr, CO i oczywiście możliwość
> sterowania tym wszystkim, pomimo że cały system tworzy pełną autonomikę
> w sensie, że od różnych zdarzeń, ustalają się różne rzeczy. Liczniki
> energii podają mi dokładnie co chcę, nawet w złotówkach i przede
> wszystkim historię, stąd mogę ocenić czy coś mi wyżera za dużo czy nie w
> danej chwili a nie po zapłaceniu rachunku...itd
>
> Kliknij w linka, zobacz produkty i się zastanów, czy sam chcesz to pisać
> od początku.

Tak zrobię :D ... bo jak widzę cenę zamela to już mi się same palce
garną do pisania kodu :DDDDD


--
Pozdrawiam - titanus

do góry

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.

do góry

On 26.03.2023 13:56, heby wrote:

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

Pobawi się moim domem podobnie jak twoim.
Ale nic nie zrobi w sieci lokalnej w przeciwieństwie do twojej.


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

Nie spuścisz w ogóle, bo twój HA będzie zajęty pakietami ddos.


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

No więc przepuści też pakiety ddos do twojego HA.


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

Bzdura. Każdy broker ma limity na wielkość pakietu jak i na liczbę
pakietów na sekundę.

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?

Równie dobrze może "przejąć" twoj VPN - taki sam poziom zabezpieczenia,
a skutki nieporównywalne.

>

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

Juź mi się powoli odechciewa, bo to do niczego nie prowadzi.

OK. prosty przykład - masz firmę, albo sąsiada, kogokolwiek komu
chciałbyś umożliwić sterowanie częścią systemu - dasz im wszystkim VPN-a
do swojej sieci?
A ja dam im użytkownika, który będzie mógł pisać czy tylko czytać pod
konkretny temaat, a mój system będzie na to reagował, a jak mi się
odechce to nie.

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

.
Bzdura. To załatwia flaga retained - tylko trzeba wiedzieć po co jest i
jak jej używać.
>
> 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

To się robi samo, tylko trzeba wiedzieć do czego służy retained, a nie
wymyślać problemu tam gdzie go nie ma.
>
>
--
Mirek.

do góry