W dniu 14.01.2024 o 17:36, heby pisze:
> On 14/01/2024 17:25, io wrote:
>> A jak mi zasilacz RPi albo gniazdko zasilania w Rpi padną to też
>> światła nie będę miał.
>
> Dlatego nie należy być nierozsądnym i stosoać normalne włączniki światła
> *plus* automatykę, a nie automatykę zamiast wąłczników światła.
>

Nie wystarczy zaprojektować automatykę tak by nie zależała od tego
pieprzonego HA?

do góry

W dniu 14.01.2024 o 17:52, heby pisze:
> On 14/01/2024 17:40, io wrote:
>>> Trzeba było wobec tego nie cytować mojej wypowiedzi o HA. Pi pojawiło
>>> się jako przykład najniższej platformy na której bredzenie o
>>> responsywaności tez nie ma sensu.
>>> To że znowu wypowiadasz się w wątku nie majac pojęcia o co chodzi,
>>> może oznaczać że zapomniałeś włączyć sobie widok drzewka w kliencie.
>> Na razie to Ty nie masz pojęcia o co chodzi, co w artykule
>> rozpoczynającym wątek jest.
>
> Jest marudzenie że coś sie popsuło.

Jest pytanie jak zastąpić HA czymś co decentralizuje sterowanie, kołku.

>
> [kolejne pierdoły o HA jak mnie ten HA do niczego nie jest potrzebny]
>
>
> To nie jest "Twój" wątek. Mamy prawo dyskutować sobie w nim o czym
> chcemy. Dyskujsja już od dawna skręciła w inną stronę. To jest usenet,
> tu tak się dzieje zawsze. Pierwszy raz, czy coś?
>

A ilu Was tam jest?

do góry

On 14/01/2024 18:58, io wrote:
>> Dlatego nie należy być nierozsądnym i stosoać normalne włączniki
>> światła *plus* automatykę, a nie automatykę zamiast wąłczników światła.
> Nie wystarczy zaprojektować automatykę tak by nie zależała od tego
> pieprzonego HA?

To jest bardzo *trudne*.

Albo inaczej: koszt zmiany, w systemie rozproszonym, jakiegokolwiek
detalu jest bardzo wysoki.

Wyobraź sobie, że chcesz, aby wyłącznik światła na podjeździe uruchamiał
oświetlenie nie tylko podjazdu, ale również odpalał nagrywanie kamery
oraz dodotkowo był połaczony z czujnikiem ruchu. Normalna sprawa. Ale o
tej kamerze nie pomyślałeś jak projektowałeś.

Nie dośc, że musisz wymienić oprogramowanie w przycisku, to jeszcze
wykonać orkę i wywołać z niego API jakiegoś systemu monitoringu. To może
być nietrywialne zagadnienie, a nawet przekraczać możliwości małego
kontrolera.

Ta unifikacja realizowana jest przez centralne aplikacje takie jak HA
czy dedykowane Xiaomi/Sonoff, chumrowe rozwiązania. ALe nie masz tego u
siebie. Musisz robić to ręcznie.

Nie wiesz, że to trudne, bo jeszcze tego nie zrobiłeś.

Oczywiście, w przypadku napotkania takiego problemu zastosujesz typowe
rozwiązanie: wmówisz sobie że to zbędne. I ok, nie ma z tym problemu,
podejście rozproszone jest bardzo mało elastyczne na etapie
rekonfiguracji i tworzysz taki system zdając sobie sprawę z problemów,
wszak.

Ponadto Twój system zapewne i tak będzie zależał od czegoś centralnego:
na przykład routera, serwera DHCP czy nawet obecności zagłuszania od
falownika sąsiada. Ilość "centralnych" problemów jest znacząca. Dam
przykład nieoczywistego: niektóre wyłączniki sonoff, jakie mam w sieci,
potrafią się "zawiesić" w wyniku skoku napięcia. Są martwe przez kilka
minut. Wot, zaleznośc od centralnego *zasilania* ... czyli co? Akumulatory?

Jeśli chcesz zbudować system automatyki, w którym nie ma routera, DHCP
itd itp to czeka Cie orka wręcz kosmiczna: moduły musza się komunikować
ad-hoc z sobą. Oceń na ile to będzie łatwe, szczególnie do zmian.

Moja automatyka, mimo zarządzania z HA, nie zależy od HA. Jeśli wyłacze
serwer to zdecydowana większość elementów domu pracuje tak samo. Nie
mogę wyłaczyć światła w ogródku z telefonu, ale mam też do tego normalny
przycisk. Nie mogę zmienić temperatury na kaloryferze z telefonu, ale
mam do tego pokretło.

Ludzie szacują ryzyko stawiania centralnego systemu, ale zyskują w ten
sposób łatwość rekonfiguracji całości. Jeśli nie chcesz mieć łatwo, to
przeciez nikt nie zmusza Cie do używania. Rób po swojemu, całość
dyskusji nie bierze się z tego, że ktoś ma pretensje do tego pomysłu,
tylko z kłamstw o niestabilności HA ogólnie. On jest tylko niestabilny
na gównianym hardware. Jeśli ta niestabilnośc to jedyny argument jaki
masz przeciw, to nie masz argumentu przeciw. Ale dalej nikt nie zmusza
Cie do robienia na HA, rób jak uważasz.

do góry

On 14/01/2024 19:05, io wrote:
>>> rozpoczynającym wątek jest.
>> Jest marudzenie że coś sie popsuło.
> Jest pytanie jak zastąpić HA czymś co decentralizuje sterowanie, kołku.

Nie tylko, jest również marudzenie. W pierwszych zdaniach. Do niego
odnosi się całą reszta wypowiedzi. To usenet, to Twój pierwszy raz?
Nigdy nie widziałeś jak działa dyskusja na grupie? Oczekujesz, że ktoś
odpowie Ci na pytanie, bo płacisz za Internet? To jakaś grupa supportu
technicznego jest?

>> To nie jest "Twój" wątek. Mamy prawo dyskutować sobie w nim o czym
>> chcemy. Dyskujsja już od dawna skręciła w inną stronę. To jest usenet,
>> tu tak się dzieje zawsze. Pierwszy raz, czy coś?
> A ilu Was tam jest?

Co najmniej kilku. Warto czytać własne wątki, mógłbyś się sporo dowiedzieć.

do góry

On Sun, 14 Jan 2024 14:17:02 +0100, heby <h...@p...onet.pl> wrote:
> To że znowu wypowiadasz się w wątku nie majac pojęcia o co chodzi,
> może
> oznaczać że zapomniałeś włączyć sobie widok drzewka w kliencie.

Wiem o co chodzi, io słusznie zauważył że tego typu rozwiązania są
dość szczególnym punktem awarii, bo unieruchamiają wszystko.

--
Marek

do góry

W dniu 14.01.2024 o 19:25, heby pisze:
> On 14/01/2024 18:58, io wrote:
>>> Dlatego nie należy być nierozsądnym i stosoać normalne włączniki
>>> światła *plus* automatykę, a nie automatykę zamiast wąłczników światła.
>> Nie wystarczy zaprojektować automatykę tak by nie zależała od tego
>> pieprzonego HA?
>
> To jest bardzo *trudne*.
>
> Albo inaczej: koszt zmiany, w systemie rozproszonym, jakiegokolwiek
> detalu jest bardzo wysoki.
>
> Wyobraź sobie, że chcesz, aby wyłącznik światła na podjeździe uruchamiał
> oświetlenie nie tylko podjazdu, ale również odpalał nagrywanie kamery
> oraz dodotkowo był połaczony z czujnikiem ruchu. Normalna sprawa. Ale o
> tej kamerze nie pomyślałeś jak projektowałeś.
>
> Nie dośc, że musisz wymienić oprogramowanie w przycisku, to jeszcze
> wykonać orkę i wywołać z niego API jakiegoś systemu monitoringu. To może
> być nietrywialne zagadnienie, a nawet przekraczać możliwości małego
> kontrolera.
>
> Ta unifikacja realizowana jest przez centralne aplikacje takie jak HA
> czy dedykowane Xiaomi/Sonoff, chumrowe rozwiązania. ALe nie masz tego u
> siebie. Musisz robić to ręcznie.
>
> Nie wiesz, że to trudne, bo jeszcze tego nie zrobiłeś.

Ja to robiłem, używałem do tego DCSa. Tobie tylko wydaje się, że problem
znasz i jak mi tutaj coś napiszesz to mnie przekonasz do jakiegoś
pieprzonego HA.

>
> Oczywiście, w przypadku napotkania takiego problemu zastosujesz typowe
> rozwiązanie: wmówisz sobie że to zbędne. I ok, nie ma z tym problemu,
> podejście rozproszone jest bardzo mało elastyczne na etapie
> rekonfiguracji i tworzysz taki system zdając sobie sprawę z problemów,
> wszak.
>
> Ponadto Twój system zapewne i tak będzie zależał od czegoś centralnego:
> na przykład routera, serwera DHCP czy nawet obecności zagłuszania od
> falownika sąsiada. Ilość "centralnych" problemów jest znacząca. Dam
> przykład nieoczywistego: niektóre wyłączniki sonoff, jakie mam w sieci,
> potrafią się "zawiesić" w wyniku skoku napięcia. Są martwe przez kilka
> minut. Wot, zaleznośc od centralnego *zasilania* ... czyli co? Akumulatory?

No i jak wyżej, oprogramowanie integrujące musi te problemy ogarniać np
wyznaczyć elementy krytyczne czego HA oczywiście nie umie bo nie ma
bladego pojęcia o zagadnieniach niezawodności systemów i dlatego
napisałem w artykule rozpoczynającym że szukam oprogramowania, które to
umie i tylko taki kołek jak Ty ciągle uważa, że "chcemy to robić na HA"
jak jasno zostało przedstawione, że nie.

>
> Jeśli chcesz zbudować system automatyki, w którym nie ma routera, DHCP
> itd itp to czeka Cie orka wręcz kosmiczna: moduły musza się komunikować
> ad-hoc z sobą. Oceń na ile to będzie łatwe, szczególnie do zmian.
>
> Moja automatyka, mimo zarządzania z HA, nie zależy od HA. Jeśli wyłacze
> serwer to zdecydowana większość elementów domu pracuje tak samo. Nie
> mogę wyłaczyć światła w ogródku z telefonu, ale mam też do tego normalny
> przycisk. Nie mogę zmienić temperatury na kaloryferze z telefonu, ale
> mam do tego pokretło.

Tak, i jak padnie centralny sterownik to wszystko będziesz robił ręcznie
bo nie umiesz zaprojektować systemu tak, by sterowanie było rozproszone.

>
> Ludzie szacują ryzyko stawiania centralnego systemu, ale zyskują w ten
> sposób łatwość rekonfiguracji całości. Jeśli nie chcesz mieć łatwo, to
> przeciez nikt nie zmusza Cie do używania. Rób po swojemu, całość
> dyskusji nie bierze się z tego, że ktoś ma pretensje do tego pomysłu,
> tylko z kłamstw o niestabilności HA ogólnie. On jest tylko niestabilny
> na gównianym hardware. Jeśli ta niestabilnośc to jedyny argument jaki
> masz przeciw, to nie masz argumentu przeciw. Ale dalej nikt nie zmusza
> Cie do robienia na HA, rób jak uważasz.
>
>

Weź się chłopku zainteresuj rozproszonymi systemami sterowania i skończ
pieprzyć.

do góry

W dniu 14.01.2024 o 19:27, heby pisze:
> On 14/01/2024 19:05, io wrote:
>>>> rozpoczynającym wątek jest.
>>> Jest marudzenie że coś sie popsuło.
>> Jest pytanie jak zastąpić HA czymś co decentralizuje sterowanie, kołku.
>
> Nie tylko, jest również marudzenie.

Naświetlenie sytuacji by było wiadomo dlaczego chcę tego czego chcę.

> W pierwszych zdaniach. Do niego
> odnosi się całą reszta wypowiedzi. To usenet, to Twój pierwszy raz?
> Nigdy nie widziałeś jak działa dyskusja na grupie? Oczekujesz, że ktoś
> odpowie Ci na pytanie, bo płacisz za Internet? To jakaś grupa supportu
> technicznego jest?
>
>>> To nie jest "Twój" wątek. Mamy prawo dyskutować sobie w nim o czym
>>> chcemy. Dyskujsja już od dawna skręciła w inną stronę. To jest
>>> usenet, tu tak się dzieje zawsze. Pierwszy raz, czy coś?
>> A ilu Was tam jest?
>
> Co najmniej kilku. Warto czytać własne wątki, mógłbyś się sporo dowiedzieć.
>

A ja myślę, że wszyscy (oprócz hebe) już zrozumieli dlaczego chcę
rozwiązania dla rozpraszania sterowania tylko takiego nie znają.

do góry

On 14/01/2024 20:34, io wrote:
> No i jak wyżej, oprogramowanie integrujące musi te problemy ogarniać np
> wyznaczyć elementy krytyczne czego HA oczywiście nie umie bo nie ma
> bladego pojęcia o zagadnieniach niezawodności systemów

Twoim problemem niezawodności był hardware. Zmień go i może się okazać,
że nie trzeba mieć bladego pojęcia więcej niż jest już zrobione.

Choć nie, nie zmieniaj. To uwaga dla innych, u Ciebie jest już tylko
"pieprzony HA" co oznacza że te rady nie mają sensu personalnie.
Puszczaj je mimo uszu, pisze to tylko po to, aby reszta miała
odniesienie do skrajności, którą reprezentujesz.

> umie i tylko taki kołek jak Ty ciągle uważa, że "chcemy to robić na HA"
> jak jasno zostało przedstawione, że nie.

Nie. Ja tu jestem tylko po to, aby rozdeptywać brednie o niestabilności
HA i wyjaśnić, że prawdopodobnie ładujesz się na minę. Ale przecież nikt
tego nie zabrania. Źle odczytujesz intencje. Nikt Ci nie zabrania
zrobienia tego jak chcesz. Ale brednia o niestabilności HA musi być
rozgnieciona w zarodku, bo niewinni ludzie mogą na to trafić i
potraktować to serio. Traktuj to jako przeciwwagę.

>> tego normalny przycisk. Nie mogę zmienić temperatury na kaloryferze z
>> telefonu, ale mam do tego pokretło.
> Tak, i jak padnie centralny sterownik to wszystko będziesz robił ręcznie

Jak padnie centralny sterownik to:
1) jeśli padnie HA to przywróce go z backupu - jakieś 3 minuty i ze 3
kliknięcia (proxmox).
2) jeśli padnie hardware, to przeniose na zapasowy - czas to głównie
wydłubanie dysku ze starego. Tak, mam zapasowy.
3) jeśli padnie dysk: to postawienie na nowo proxmoxa i odzyskanie HA z
backupu to jakieś może z 20 minut max, ale przypuszczam że mniej.
4) Jak mnie nie będzie w domu to ojej, trzeba bedzie podejśc do ściany i
pstryknąć światło po staremu.

> bo nie umiesz zaprojektować systemu tak, by sterowanie było rozproszone.

To raczej kwestia zdawania sobie sprawy z kłopotliwości tego
zagadnienia, a nie braku umiejętności. Co prawda, może bym i potrafił
wystrugać furmankę, ale jednak preferuję samochody.

Innymi słowy widzę zalety rozpraszania, ale też zdaje sobie sprawę, że
to nie system sterowania silosami rakiet międzykontynentalnych. Jak
padnie, to się naprawi w max 20 minut, w przeciwieństwie do zrobienia od
zera rozproszonego, licząc to w nieskończonej ilości roboczogodzin.

> Weź się chłopku zainteresuj rozproszonymi systemami sterowania i skończ
> pieprzyć.

Ja się nimi interesowałem jak jeszcze nie były modne. I dalej nie są.
Też kiedyś miałem pomysł robić wszystko samodzielnie. Jakie to
szczęście, że zmądrzałem.

do góry

On 14/01/2024 20:19, Marek wrote:
> io słusznie zauważył że tego typu rozwiązania są dość
> szczególnym punktem awarii, bo unieruchamiają wszystko.

Podonie jak:
1) awaria prądu
2) awaria routera
3) konflikt DHCP
4) zagłuszarka sieci
5) posuta mikrofalówka
6) trafienie meteorytu

Aby te problemy rozwiązać, należy puscić dodatkowe zasilanie, najlepiej
zdublowanymi kablami, z podwójnego UPSa. Całość komunikacji zrobić na
Wifi ah-hoc. Zabić na stałe IP, a najlepiej w ogóle nie używać
protokołów wyższej warstwy, tylko napierniczać głym ethernetem. Otoczyć
budynek gęstą siatką, zabudować klatkę betonową nad dachem i wyrzucić
całość sprzętu RTV-AGD.

Tylko wtedy można będzie czuć się bezpiecznie, że da się zapalić światło
w kiblu.

Można też światło w kiblu mieć poprowadzone kablem, co inwaliduje prawie
wszystko wyżej.

Rozumiesz śmieszność problemu stabilności automatyki domowej?

Awaria HA nic nie powinna zmienić w działaniu części krytycznej budynku.
Jak coś zmienia, to masz zdrowo popsuty koncept.

I dotyczy to też sterowania rozproszonego.

W zasadzie: dowolnego sterowania zwiazanego z komfortem.

do góry

W dniu 14.01.2024 o 20:53, heby pisze:
> On 14/01/2024 20:34, io wrote:
>> No i jak wyżej, oprogramowanie integrujące musi te problemy ogarniać
>> np wyznaczyć elementy krytyczne czego HA oczywiście nie umie bo nie ma
>> bladego pojęcia o zagadnieniach niezawodności systemów
>
> Twoim problemem niezawodności był hardware. [reszta pierdów nt HA]

Wątpię. Raczej HA. A przede wszystkim koncepcja centralnego sterownika
którą ten HA jedynie zna.

do góry