W dniu 2023-03-25 o 21:01, LordBluzg(R)?? pisze:
> 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?
>>
P2P podałem jedynie jako przykład możliwych dla mnie rozwiązań na zdalny
dostęp. To nie wymóg.

>>>>> 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.
> ...
Wszystko się zgadza - tu chcę POMINĄĆ "chmurę".

>>> ...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?
>
...a dlaczego nie? Nadal "upieram" się jedynie nad tym, że rodzaj
zastosowanych rozwiązań technicznych nie jest w żaden sposób
obligatoryjny. Kwestią dyskusyjną pozostaje: czy warto.

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

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 ?
Coś na zasadzie zarządzania w routerach.
Logujesz się lokalnie - masz interfejs lokalny. Logujesz się zdalnie -
masz dostęp zdalny. Router wyświetla odpowiednio sparsowane strony i kropka.

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

Działanie/stan aktualny CLi byłby sprawdzany powiedzmy np co 1s jeśli
chodzi o rzeczy krytyczne, ale np temp, wilgotność, ciśnienie mogę
sprawdzać równie dobrze co minutę czy trzy.

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

--
Pozdrawiam - titanus