piątek, 24 marca 2023 o 09:36:01 UTC+1 LordBluzg(R)?? napisał(a):
> W dniu 24.03.2023 o 04:31, Zenek Kapelinder pisze:
> > > Ja rozumie
>
> > Rozumie otwieranie bramy
>
> Jeszcze raz napiszesz "rozumie" zamiast "rozumiem" to przyjadę do tej
> Łodzi i cię kurwa odstrzelę jak psa. Zero litości.
> --
> LordBluzg(R)??
> <<<?i? ć?d?? i Putina i ęjcaredefnoK>>>
Napisałem żeby taki młot jak ty zrozumiał.

do góry

W dniu 2023-03-23 o 16:05, io pisze:
> To sprzedaj dom i d...y nie zawracaj. :-)

On nie ma domu i dlatego tak marudzi :P

L.

do góry

W dniu 2023-03-23 o 11:28, J.F pisze:
> On Wed, 22 Mar 2023 21:28:00 +0100, titanus wrote:
>> Czytając posty kilku adv userów, chciałbym zapytać czy ktoś myślał na
>> zrobieniem sobie systemu HA, ale całkowicie od podstaw.
>>
>> Dlaczego tak, skoro na rynku jest kilkanaście różnych pomysłów i to
>> kilka dopracowanych i zróżnicowanych? - bo mam taki pomysł...
>>
>> ...bo mam już dość ciągłego "włażenia mi w buty" przez ich wytwórców.
>>
>> Czego NIE CHCĘ - chmurowgo systemu lub czegokolwiek czego sam nie mogę
>> kontrolować i ustawić CAŁKOWICIE pod siebie - włącznie z kodem.
>
> Przecietny klient nie jest programistą i chce gotowy :-)
> Nie jestem "przeciętnym klientem" - na poziomie kodu programu jestem w stanie
zaprogramować sobie zarówno LOGO! jak i PIC'a czy atmege.
z 80C5x w kodzie szesnastkowym też sobie radzę :)

> A i Ty kiedys pomyslisz, ze przydałoby sie zdalne zarządzanie,
> i wraca problem serwera/chmury.
>
Tak jak pisałem - NIE CHCĘ CHMURY. KROPKA. W żadnej postaci.
Co nawyżej połączenie typu P2P.

>> Czego oczekuję:
>> - Możliwości pracy CAŁKOWICIE lokalnej w ramach jakiejkolwiek sieci:
>> LAN, WIFI, czy RS-485 lub innej.
>> - Jednostki centralnej zarządzającej "klientami".
>> - NA RAZIE możliwości kontroli jako OPCJI przez sieć internetową w
>> formie dostępu zdalnego, rejestrowanego jako P2P lub vpn, ale to nie wymóg.
>
> A "zewnetrzny" adres IP masz? Stały?
>
Jeszcze nie, ale własnie pod tym kątem rozmawiam z lokalnym providerem.

>> - Możliwości połączeń klientów w formie bez i przewodowej.
>> - Identyfikacji klienta i jego możliwości w formie prostej tablicy.
>> - reakcji obustronnej na zdarzenia typu fail, oob, czy tl.
>>
>> Jednostka centralna nie musi mieć - póki co - wyszukanego menu czy
>
> Musi, bo juz widać, ze chcesz dowolne, czasem skomplikowane reguły.
> Moze i bez menu, ale z jakims jezykiem programowania.
>
Tylko po co?
Jeśli stworzę własny ekosystem na zasadzie:
CU czyta i zapisuje w pamięci rodzaje i możliwości CLi, to ustawienie i
zapis do CL będzie w postaci: podania pola zmiany i paramertu zmiany. Cl
przyjmie po sieci to co CU chce zmienić - sprawdzi czy się da, zmieni i
jeśli wszystko będzie OK, wyśle do CU potwierdzenie zmiany. Tyle. Tu nic
nie trzeba będzie programować. Niewielki kod do zarządzania CLem trzeba
będzie wgrać do niego tylko raz.

Dlatego też w samym CU nie trzeba będzie również żadnego gigantycznego
kodu do zarządzania.

>> super-duper wyświetlacza - najważniejsze jest stabilne działanie i
>> stosunkowo prosta i szybka konfiguracja zarówno klientów jak i samego CU.
>
> Srednio się da, szczególnie przy wifi :-)
>

Czy rodzaj interfejsu komunikacyjnego aż tak bardzo determinuje
możliwości tego co ma robić CU/CL ?

>> Do czego chcę go zaprząc:
>> - kontrola zużycia prądu w domu, globalnie i lokalnie - najlepiej
>> bezprzewodowo - w sumie licznik w rozdzielnicy i 4 gniazdkowe.
>> - proste sterowanie 3 pompami lub integracja zerojedynkowa z prościutkim
>> systemikiem opartym na LOGO!. (0BA6)
>> - odczyt temperatur w domu - 4 punkty, i na zewnątrz - 2 punkty.
>> - jako opcja komunikacja z piecem gazowym vailanta przez jakiś
>> "konwerter" i ich wewnętrzną magistralę (na płycie)
>> - odczyt wilgotności w domu - 2 punkty, i na zewnątrz - 1 punkt
>> - praca z RTC i/lub DCF77
>> - kontrolą pieca na paliwo stałe lub integracja z systemem nim
>> zarządząjacym - też na LOGO!. (0BA8)
>> - kontrolą sterowania bramą wjazdową, dwuskrzydłową (piloty na 433Mhz -
>> niekoniecznie kodowane)
>> - możliwością nieskomplikowanego dołożenia czegoś jeszcze w przyszłości
>> głównie np. prostego s-on/off'a
>>
>> To co powyżej musi być widoczne w CU jako CL i ustawiane przez CU
>> bezpośrednio w CL. Aktualne parametry CL dostępne mają być po odpytaniu
>> przez CU i zapisywane w pamięci CU jako lista aktywnych CLi.
>>
>> Jeśli chodzi o CU to sam procek może być jakiś bardziej wyszukany, PIC,
>> ATMEGA czy cokolwiek innego 32 lub 16 bitowego. W CLach wystarczy coś
>> energooszczędnego 8 bitowego ale z portem LAN lub wifi.
>>
>> ------------
>> Jest to w miarę logiczne ?
>
> Jest, ale brzmi jak ambitny projekt Open Source, z mnóstem pluginów.
> I jesli nie zainteresujesz powaznych producentów, to bedziesz musial
> hackowac ich urzadzenia/komunikacje/chmury.
>
...eee tam - może i wygląda to (na papierze) ambitnie, ale takie mi się
nie wydaje.

Stworzenie CLa np w formie płytki dwustronnej o wielkości koła fi 55
(coby weszło np do puszki) posadzenia tam jakiegoś 14/16 pinowego pica
razem z interfejsem wifi czy lan oraz parę elmentów wykonawczych nie
jest jakimś szczególnym dla mnie wyzwaniem.

Wyzwaniem jest takie tego oprogramowanie, żeby stanowiło to jedną
całość. Stąd główne pytanie w rootpoście - czy ktoś robił sobie coś
takiego od podstaw?


>> Macie jakieś doświadczenia ?
>> P.S. - Tak domyślam się, że to może być całkowicie nieekonomiczne, ale 2
>> inne takie nieekonomiczne projekciki sobie zrobiłem i na razie jestem z
>> nich zadowolony.
>
> Zanim skonczyc całośc, to piec zmienisz :-)
>
Nie wydaje mi się - fakt, że dla przykładu: wymiana i oprogramowanie
całkowicie nowej płytki do okapu zajęło mi blisko 3 miechy, kosztowało
drugie tyle co nowy okap, ale ten który jest poprotu pasuje do wystroju
kuchni i żona nie chciała go zmieniać - poszedł pomysł na wymianę i
zrobienie tego całkowinie od nowa. Spoko zabawa. Rezultat - bezcenny :D

Podobnie z małą - jak ją nazywa żona - przepompownią: projekt oparty o
LOGO! które steruje: 3 pompami, 2 zaworami 3-drogowymi (przełączalne),
oraz blokuje mój piec gazowy jesli na piecu na paliwo stałe wykryje jego
pracę - zajął mi 2 miechy. Ddatkowo monitoruje wzrost ciśnienia w moim
układzie i wł/wył odpowienio pompkę do podłogówki jeśli piec gazowy
działa lub nie. Układy piec na paliwo stałe i piec gazowy odseparowane
sprzęgłem hydraulicznym (cieplnym).

...i parę innych.

To nie jest praca "pod publiczkę" ale dla siebie. Nie musi być idealnie
- ważne aby działało dobrze.

> J.

--
Pozdrawiam - titanus

do góry

On 25.03.2023 19:14, titanus wrote:

> Tak jak pisałem - NIE CHCĘ CHMURY. KROPKA. W żadnej postaci.
> Co nawyżej połączenie typu P2P.

>> A "zewnetrzny" adres IP masz? Stały?
>>
> Jeszcze nie, ale własnie pod tym kątem rozmawiam z lokalnym providerem.
>

Szkoda nerwów i pieniędzy. "Chmury", która nie wiem jak działa też bym
nie chciał, ale publiczny broker MQTT - czemu nie - w końcu to ja
decyduję co do niego wysyłam i co odbieram.
Stawianie serwera na własnym IP w domu też ma swoje wady - providera
kiedyś będziesz chciał albo musiał zmienić, może też zdarzyć się awaria
i wtedy na szybko internet z komórki nie zadziała.
Dodatkowo możesz mieć problem z dostępem do swojego IP od różnych
dostawców, u których będziesz gościem. "Chmura" u dużego dostawcy usług
znacznie zmniejsza to ryzyko.

--
Mirek.

do góry

W dniu 25.03.2023 o 19:14, titanus pisze:

> Tak jak pisałem - NIE CHCĘ CHMURY. KROPKA. W żadnej postaci.
> Co nawyżej połączenie typu P2P.

A jak ma to P2P działać bez chmury?

>> A "zewnetrzny" adres IP masz? Stały?
>>
> Jeszcze nie, ale własnie pod tym kątem rozmawiam z lokalnym providerem.

Mając P2P nie potrzebujesz mieć publicznego IP.

>>> Jednostka centralna nie musi mieć - póki co - wyszukanego menu czy
>>
>> Musi, bo juz widać, ze chcesz dowolne, czasem skomplikowane reguły.
>> Moze i bez menu, ale z jakims jezykiem programowania.
>>
> Tylko po co?
> Jeśli stworzę własny ekosystem na zasadzie:
> CU czyta i zapisuje w pamięci rodzaje i możliwości CLi, to ustawienie i
> zapis do CL będzie w postaci: podania pola zmiany i paramertu zmiany. Cl
> przyjmie po sieci to co CU chce zmienić - sprawdzi czy się da, zmieni i
> jeśli wszystko będzie OK, wyśle do CU potwierdzenie zmiany. Tyle. Tu nic
> nie trzeba będzie programować. Niewielki kod do zarządzania CLem trzeba
> będzie wgrać do niego tylko raz.

...a jak chcesz gromadzić dane w sensie historia, powiadomienia, eventy
w sensie, jak jesteś po za domem + ewentualne zarządzanie bez smartfona?



--
LordBluzg(R)??
<<<?i? ć?d?? i Putina i ęjcaredefnoK>>>

do góry

On 25/03/2023 20:09, Mirek wrote:
> nie chciał, ale publiczny broker MQTT - czemu nie - w końcu to ja
> decyduję co do niego wysyłam i co odbieram.

Publiczny broker nie załatwi interfejsu użytkownika.

> Stawianie serwera na własnym IP w domu też ma swoje wady - providera
> kiedyś będziesz chciał albo musiał zmienić, może też zdarzyć się awaria
> i wtedy na szybko internet z komórki nie zadziała.

https://portmap.io/

do góry

On 25.03.2023 20:25, heby wrote:

> Publiczny broker nie załatwi interfejsu użytkownika.
>
Bo nie taka jest jego rola.
Interfejs załatwia zwykle apka.
Rozumiem, że chcesz mieć interfejs po http? No można, ale tak nie działa
przecież żadna "fabryczna chmura", więc porównujmy słonia do słonia a
kota do kota.

--
Mirek.

do góry

W dniu 2023-03-25 o 20:23, LordBluzg(R)?? pisze:
> W dniu 25.03.2023 o 19:14, titanus pisze:
>
>> Tak jak pisałem - NIE CHCĘ CHMURY. KROPKA. W żadnej postaci.
>> Co nawyżej połączenie typu P2P.
>
> A jak ma to P2P działać bez chmury?
>
Podając w np przeglądarce na smartfonie,tablecie/PC publiczny adres IP
serwera z CU + oczywiście logowanie? W tym momencie potrzebuję jedynie
lekko oprogramowanego HTMl'a w CU - chyba nic więcej ?

>>> A "zewnetrzny" adres IP masz? Stały?
>>>
>> Jeszcze nie, ale własnie pod tym kątem rozmawiam z lokalnym providerem.
>
> Mając P2P nie potrzebujesz mieć publicznego IP.
>
hmm... peer to peer - no w zasadzie nie, ale "ktoś" musi wiedzieć
_gdzie_ się chcę podłączyć i dlaczego ?

>>>> Jednostka centralna nie musi mieć - póki co - wyszukanego menu czy
>>>
>>> Musi, bo juz widać, ze chcesz dowolne, czasem skomplikowane reguły.
>>> Moze i bez menu, ale z jakims jezykiem programowania.
>>>
>> Tylko po co?
>> Jeśli stworzę własny ekosystem na zasadzie:
>> CU czyta i zapisuje w pamięci rodzaje i możliwości CLi, to ustawienie
>> i zapis do CL będzie w postaci: podania pola zmiany i paramertu
>> zmiany. Cl przyjmie po sieci to co CU chce zmienić - sprawdzi czy się
>> da, zmieni i jeśli wszystko będzie OK, wyśle do CU potwierdzenie
>> zmiany. Tyle. Tu nic nie trzeba będzie programować. Niewielki kod do
>> zarządzania CLem trzeba będzie wgrać do niego tylko raz.
>
> ...a jak chcesz gromadzić dane w sensie historia, powiadomienia, eventy
> w sensie, jak jesteś po za domem + ewentualne zarządzanie bez smartfona?
>
Może być wysyłane jako zestaw danych np na lokalnie wpięty dysk na
routerze, ze "sztywnym" dostępem (np po ftp).
Sądzę, że nie potrzbuję w CU gigantycznej pamięci tylko na historię czy
logi. Powiadomienia np o zmienie stanu czy błędzie krytycznym można
przecież generować adhoc i dopiero wtedy zapisać w lokalnej pamięci w
formie również prostej tablicy: nr CLa, rodzaj alarmu (nawet cyferkami -
do "rozkodowania" w jakimś case'sie w pętli obsługi przerwania), reakcja
usera na alarm: jest, nie ma, skasuj. Zresztą to już są szczegóły
programowe - do zrobienia później.

--
Pozdrawiam - titanus

do góry

On 25/03/2023 20:44, Mirek wrote:
>> Publiczny broker nie załatwi interfejsu użytkownika.
> Bo nie taka jest jego rola.
> Interfejs załatwia zwykle apka.

Jaka więc apka? Gdzie trzyma konfiguracje? Jest w wersji na PC i
telefon? Kto załątwia automatyzacje i interakcje miedzy elementami
systemu? Chyba nie ta apka bo co jak się telefon rozładuje?

> Rozumiem, że chcesz mieć interfejs po http? No można, ale tak nie działa
> przecież żadna "fabryczna chmura", więc porównujmy słonia do słonia a
> kota do kota.

To chyba tylko kwestia tego, aby dostać się do wewnątrznej sieci z
dowolnego miejsca na świecie. portio + OpenVPN zapewnia nie tylko dostep
do HA, ale do masy innych rzeczy, typu nas, zdalny pulpit, chromecast
itd itp. Owycziście, suwerenowi to zbędne, ale autor wątku do suwerenów
raczej nie należy.

Ogólnie, brak IP publicznego to obecnie nie jest problem, a dostęp do
automatyki jest trywialny bez względu na warunki providera.

do góry

W dniu 25.03.2023 o 20:49, titanus pisze:

>>> Tak jak pisałem - NIE CHCĘ CHMURY. KROPKA. W żadnej postaci.
>>> Co nawyżej połączenie typu P2P.
>>
>> A jak ma to P2P działać bez chmury?
>>
> Podając w np przeglądarce na smartfonie,tablecie/PC publiczny adres IP
> serwera z CU + oczywiście logowanie? W tym momencie potrzebuję jedynie
> lekko oprogramowanego HTMl'a w CU - chyba nic więcej ?

To po co Ci P2P skoro chcesz mieć adres publiczny?
>
>>>> A "zewnetrzny" adres IP masz? Stały?
>>>>
>>> Jeszcze nie, ale własnie pod tym kątem rozmawiam z lokalnym providerem.
>>
>> Mając P2P nie potrzebujesz mieć publicznego IP.
>>
> hmm... peer to peer - no w zasadzie nie, ale "ktoś" musi wiedzieć
> _gdzie_ się chcę podłączyć i dlaczego ?

No tak jest. CU ma kontakt z zewnętrzną chmurą P2P, ty pytasz chmurę,
która jest "publiczna" dostajesz ticket i zestawia się połączenie z CU i
obojętnie jaki masz adres IP czy publiczny/niepubliczny/stały/zmienny.
...
>> ...a jak chcesz gromadzić dane w sensie historia, powiadomienia,
>> eventy w sensie, jak jesteś po za domem + ewentualne zarządzanie bez
>> smartfona?
>>
> Może być wysyłane jako zestaw danych np na lokalnie wpięty dysk na
> routerze, ze "sztywnym" dostępem (np po ftp).

A dlaczego taki "staroć" z tym ftp?

> Sądzę, że nie potrzbuję w CU gigantycznej pamięci tylko na historię czy
> logi. Powiadomienia np o zmienie stanu czy błędzie krytycznym można
> przecież generować adhoc i dopiero wtedy zapisać w lokalnej pamięci w
> formie również prostej tablicy: nr CLa, rodzaj alarmu (nawet cyferkami -
> do "rozkodowania" w jakimś case'sie w pętli obsługi przerwania), reakcja
> usera na alarm: jest, nie ma, skasuj. Zresztą to już są szczegóły
> programowe - do zrobienia później.

No to jeszcze problem z apką na smartfona, która trzyma cały czas
połączenie z CU i reaguje na alarmy/eventy.
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.


--
LordBluzg(R)??
<<<?i? ć?d?? i Putina i ęjcaredefnoK>>>

do góry