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