On Mon, 22 Aug 2022 20:21:52 +0200, Piotr Gałka wrote:
> W dniu 2022-08-22 o 14:32, J.F pisze:
>> Co zaraz powoduje problemy pod tytulem kolizje.
>> Wykrywacie?
>
> Przyjmujemy, że nie ma pewności wykrycia kolizji. Jak oba nadajniki są
> kawałek od siebie to może być tak, że każdy widzi to co sam nadaje.
> Dlatego nie usiłujemy wykrywać kolizji - minimalizujemy szansę na
> kolizje i przy braku potwierdzenia powtarzamy.

A jaki timeout dla potwierdzenia? Ile trzeba czekac az drzwi sie
otworzą ? :-)

> Nie ja pisałem oprogramowanie - mogę mylić drobiazgi.
> Wszystkie drivery fail-save.
> Każdy wypracowuje flagę - linia wolna/linia zajęta. Z tym, że jak uzna,
> że linia jest wolna to odmierza jeszcze losowe opóźnienie zanim ustawi
> sobie flagę linia wolna. Każde 0 na linii powoduje natychmiastowe
> ustawienie flagi na linia zajęta.
> Jeden postanawia nadawać - szykuje ramkę, szyfruje ją podpisuje i jak ma
> flagę linia wolna to wchodzi na linię (czyli jak już dawno była wolna to
> wchodzi bez żadnego opóźnienia).
> Wchodzi na linię - po rzędu 0us od decyzji.
> Odczekuje chwilkę (aby zbocze było relatywnie tak samo opóźnione jak
> potem kolejne) - np 0,7us.
> Czas propagacji scalaka (HVD72) - typ. 0,7us.
> Czas propagacji w linii (do 300m, 2E8) - 1,5us.
> Czas propagacji odbiornika 0,1us.
> Czas reakcji na przerwanie w tej skali - 0us.
> Razem 3us. Czyli mogą się zderzyć tylko gdy różnica momentów decyzji o
> wejściu na linię jest mniejsza niż 3us. Często mniejsza różnica momentu
> decyzji też nie spowoduje zderzenia, bo przecież nie zawsze linia ma
> 300m i nie każda para urządzeń jest na przeciwległych końcach.
>
> Na początku nie mieliśmy tych opóźnień i trafiliśmy raz (może 1996) na
> parę urządzeń, które wiecznie się zderzały - mijało kilka sekund (wiele
> ramek) zanim któremuś udało się być pierwszym.

Tak tak, ethernet mial ciekawy pomysl :-)

> Zaokrąglając. Prędkość 100k, bit = 10us, bajt =100us, mała ramka = 1ms.
> Czyli na tej losowości możemy maksymalnie marnować 15x5us=75us - mniej
> niż bajt przerwy. Ale to dotyczy tylko sytuacji maksymalnego obciążenia
> linii, które nigdy nie występuje.
>
> Załóżmy mały system - 5 urządzeń podległych na szynie. Norma wymaga, aby
> najdalej po 5s wykryć brak urządzenia. Czyli np raz na 4s kontroler
> wysyła 5 ramek (nie broadcast, bo każdy ma inny klucz sesji) i potem
> niezależny proces zbiera odpowiedzi.

Ale to juz brzmi jak polling.

> Możliwe, że jak chce wysłać 3-ą
> ramkę to odpowiedź pierwszego urządzenia wetnie się przed nią - zależy
> co kto wylosuje. Czyli w stanie normalnym raz na 4s leci 10 ramek.
> Typowa zajętość linii 10ms/4000ms = 0,25%.
>
>> Przy niewielkiej ilosci szybkich urzadzen - moze to nie problem.
>> Bedą odpytywane co poł sekundy ...
>
> A pro po szybkich. Ten ich system powoduje, że tylko kontroler może
> optymalizować czas szyfrowania robiąc to w czasie gdy inna ramka leci.
> Urządzenie po odebraniu musi sprawdzić podpis, rozszyfrować, wypracować
> odpowiedź, zaszyfrować, podpisać i w tym czasie na szynie cisza - się czeka.

No ale i tak to robisz. Tyle tylko, ze jak rozumiem - to sluzy do
sprawdzania obecnosci - zdarzenie urządzenia przekazują w miare
natychmiast.

> Pół sekundy to sporo czasu. Norma przewiduje, że atakujący system grade
> 3 i grade 4 ma praktycznie dowolne wyposażenie jakie mu tylko potrzebne.
> Norma nie specyfikuje, że taki tamper ma trafić momentalnie. My po
> prostu uważaliśmy, że jak coś da się zrobić lepiej to nie ma sensu robić
> gorzej.
> Są dwa tematy:
> 1.
> Niektóre instalacje muszą mieć dużo urządzeń. Wyobraź sobie pokój
> centralny i od niego promieniście śluzy. Każda ma 4 drzwi: do tego
> pokoju, na zewnątrz, do śluzy po prawej i do śluzy po lewej (jeszcze 2
> lata temu nie wiedziałem, że takie rzeczy istnieją). Nie da się
> wydzielić żadnego podzbioru drzwi niezależnych od innych. Z tego powodu
> wprowadziliśmy kontroler obsługujący 16 drzwi. Czytnik po każdej stronie
> - już 32 urządzenia. Dodatkowo ileś modułów rozszerzeń aby dodać wyjść i
> wejść i mamy rzędu 40.
> 2.
> Jak urządzenie typowo nadaje 1ms na 4s to przyjąłem, że z dopuszczalnego
> zasilania do 24V robię 3V3 liniowo. A jak się puści odpytywanie
> najszybciej jak się da to ilość wydzielanego ciepła wzrośnie radykalnie.
> Nie przewidywałem po prostu tak idiotycznego sposobu pracy. A poza tym w
> czytniku RFID wolę nie mieć DCDC bo może będzie zakłócało odczyt.

No fakt, moglby byc problem ... wiekszy radiator :-)


>> Rozumiem, ze to twoje zyczenie, ale jak czytnik ma sprawdzic gdzies
>> "na serwerze", serwer sprawdzic "w bazie danych", to czas rosnie :-(
>
> Chyba nawet norma wymaga, że w przypadku odcięcia komunikacji z serwerem
> wszystko ma nadal działać. W każdym razie u nas wszystkie informacje są
> w kontrolerze (mała skrzyneczka na szynę DIN) zasilanym zasilaczem
> buforowym.

Pisząc "serwer" mam na mysli jakis "kontroler systemu".
Gdzies tam macie przeciez zapisane ktore karty sa aktywne, jakie maja
uprawnienia itp.

>> Np wspolny protokół, zeby można było urządzenia mieszać, brak kolizji,
>> brak programowania w sensie - brak adresu "serwera". Choc mozna by
>> dac jakis staly adres np 1 czy jakis brodcastowy "do wszystkich
>> serwerow/kontrolerow".
>
> W normie jest opisany rozkaz broadcastowy, ale piszą, że jest założenie,
> że jest używany tylko, gdy jest połączenie jeden do jeden. Ja jej
> dokładnie nie znam. To ma chyba służyć do tego aby można było wywołać
> urządzenie, które nie ma przydzielonego numeru i mu ten numer
> przydzielić. Łącząc tak po jednym potem można połączyć wszystkie.
> U nas wszystko łączy się jak ma być i potem wszyscy się dogadują (też
> nie wiem dokładnie jak, bo to brat pisał).

Podejrzewam, ze i tamta norma podobnie zaklada, bo to troche glupio
wiekszy system po jednym montowac i uruchamiac.

>> Byc moze tez przy okazji znika problem zajetosci kontrolera, choc
>> odbior portu szeregowego i tak na przerwaniach przeciez ...
>>
>> A warstwa fizyczna jest tam podana?
>> Bo moze i tak na ethernet przeszli :-)
>
> W tej chwili nie umiałbym tego udowodnić, ale to dotyczy RS485.
> Standardu Wiegand też nikt nie przenosi na ethernet :)

Jak widac jednak sporo elementow Ethernetu sie w koncu w systemie
znalazlo :-)

J.

do góry

W dniu 2022-08-23 o 13:35, J.F pisze:

Cieszę się, że się czepiasz :)
Traktuję to jako pomoc w przygotowaniu się na ewentualne dyskusje bo w
normie jest:
"If you wish to give us your feedback on this publication...." i
"W sprawach merytorycznych dotyczących treści normy można zwracać się.."

> A jaki timeout dla potwierdzenia? Ile trzeba czekac az drzwi sie
> otworzą ? :-)

Nie mam pojęcia (to nie ja, to brat :) ).
Zakładam, że system jest idealny według mojego pomysłu. O ile wiem brat
nie wszystko wdrożył, bo zrobił próby (typu 10 urządzeń dostaje wspólnym
drutem informację o zmianie stanu, który trzeba wysłać) i stwierdził
skoro wszystko działa to nie ma co przesadzać.

Najważniejsze jest oszacowanie jakie jest prawdopodobieństwa zderzenia.
Jeśli jest odpowiednio małe to jak nawet z takim prawdopodobieństwem
zdarzy się, że ktoś poczeka dodatkowe 100ms to świat się raczej nie zawali.

W tym idealnym rozwiązaniu mamy system priorytetów o którym wcześniej
nie wspominałem. Są rozdzielne zakresy opóźnień dla różnych rodzajów
ramek. Jeśli na koniec aktualnie nadawanej ramki czeka ramka powolnego
poolingu i ramka z odczytaną kartą to prawdopodobieństwo, że się zderzą
jest 0 bo mają rozdzielone okna czasowe.
Czyli jeśli czytnik nabiera ochoty na transmisję podczas trwania ramki
poolingu to jedynym problemem może być drugi czytnik. Ramka trwa 1ms.
Jakie jest prawdopodobieństwo, że dwie osoby zbliżą karty w czasie tej
samej 1ms. Myślę, że znikome i w tym fragmencie trzeba to jeszcze
pomnożyć przez 0,25% bo tak szacowałem zajętość szyny poolingiem.
Jest jakieś śladowe prawdopodobieństwo i teraz z kolei, aby się zderzyć
obaj muszą wygenerować tę samą liczbę losową, co nawet wtedy nie daje
gwarancji, że się zderzą.
Druga sytuacja to dwa czytniki, gdy nie ma akurat ramki poolingu. Można
założyć, że tak jest prawie zawsze. Oba czytniki już od jakiegoś czasu
uważają, że szyna jest wolna więc jak tylko będą miały ramkę to ją
nadadzą. Ale tu zbieżność musi być na poziomie 3us. Załóżmy, że stawiamy
dwie osoby przy dwu czytnikach i niech próbują trafić tak dokładnie :)
Aby policzyć trzeba założyć, jak często do n czytników ktoś podchodzi.
Wstępnie bym zsumował po 3us z n-1 czytników, podzielił przez rozważany
okres i to byłaby gęstość prawdopodobieństwa, że n-ty czytnik trafi. Tak
bym ocenił ryzyko dla tego jednego. Że wśród n się zdarzy to mniej
więcej (ale tu można mniej więcej) razy n.

>> Na początku nie mieliśmy tych opóźnień i trafiliśmy raz (może 1996) na
>> parę urządzeń, które wiecznie się zderzały - mijało kilka sekund (wiele
>> ramek) zanim któremuś udało się być pierwszym.
>
> Tak tak, ethernet mial ciekawy pomysl :-)

Nie rozumiem.

>> Załóżmy mały system - 5 urządzeń podległych na szynie. Norma wymaga, aby
>> najdalej po 5s wykryć brak urządzenia. Czyli np raz na 4s kontroler
>> wysyła 5 ramek (nie broadcast, bo każdy ma inny klucz sesji) i potem
>> niezależny proces zbiera odpowiedzi.
>
> Ale to juz brzmi jak polling.

Ale co innego (zasadniczo co innego) maksymalnie szybki pooling, aby dać
urządzeniom szansę wysłania pilnych komunikatów a co innego kilkanaście
1ms ramek raz na 4s.
Nie przeczytałem jeszcze całej normy i nie wiem ile mi zejdzie. O ile
się orientuję, to pooling jest tam nie szyfrowany. Zakładają, że mogą
być urządzenia o małej mocy obliczeniowej które by opóźniały. To
oznacza, że w tym grade, gdy norma (inna, główna) wymaga szyfrowania
komunikacji to dodatkowo trzeba zrobić szyfrowany pooling raz na te 4s
bo zwykły pooling daje się oszukać.
Przy grade 4 jest założenie, że atakujący ma nieograniczony czas i
środki na przygotowanie ataku.

>> Możliwe, że jak chce wysłać 3-ą
>> ramkę to odpowiedź pierwszego urządzenia wetnie się przed nią - zależy
>> co kto wylosuje. Czyli w stanie normalnym raz na 4s leci 10 ramek.
>> Typowa zajętość linii 10ms/4000ms = 0,25%.
>>
>>> Przy niewielkiej ilosci szybkich urzadzen - moze to nie problem.
>>> Bedą odpytywane co poł sekundy ...
>>
>> A pro po szybkich. Ten ich system powoduje, że tylko kontroler może
>> optymalizować czas szyfrowania robiąc to w czasie gdy inna ramka leci.
>> Urządzenie po odebraniu musi sprawdzić podpis, rozszyfrować, wypracować
>> odpowiedź, zaszyfrować, podpisać i w tym czasie na szynie cisza - się czeka.
>
> No ale i tak to robisz.

Chyba nie zrozumiałeś co chciałem powiedzieć.
Ten fragment "Możliwe, że jak chce wysłać 3-ą.." powinien wyjaśniać.
Kontroler nie czeka, aż odpytywany sobie zdekoduje i zakoduje. W tym
czasie szyna może być normalnie używana przez wszystkich potrzebujących.
Wszystkie operacje kryptograficzne u wszystkich uczestników pogaduszek
odbywają się poza czasem zajętości szyny. Urządzenie dopiero jak ma
gotową ramkę to staje się uczestnikiem walki o dostęp.

> Tyle tylko, ze jak rozumiem - to sluzy do
> sprawdzania obecnosci - zdarzenie urządzenia przekazują w miare
> natychmiast.

Tak, służy tylko temu, ale chciałem tu pokazać, że ten pooling nie
blokuje w żaden sposób szyny w związku z operacjami krypto.
Jakbyśmy dołączyli urządzenie, które będzie liczyło AES na przekaźnikach
to nie spowolni to w żaden sposób komunikacji na szynie.

> No fakt, moglby byc problem ... wiekszy radiator :-)

W szczelnie zalanym czytniku ...

>>> Rozumiem, ze to twoje zyczenie, ale jak czytnik ma sprawdzic gdzies
>>> "na serwerze", serwer sprawdzic "w bazie danych", to czas rosnie :-(
>>
>> Chyba nawet norma wymaga, że w przypadku odcięcia komunikacji z serwerem
>> wszystko ma nadal działać. W każdym razie u nas wszystkie informacje są
>> w kontrolerze (mała skrzyneczka na szynę DIN) zasilanym zasilaczem
>> buforowym.
>
> Pisząc "serwer" mam na mysli jakis "kontroler systemu".
> Gdzies tam macie przeciez zapisane ktore karty sa aktywne, jakie maja
> uprawnienia itp.

Kiedyś mając słabsze procesory kombinowaliśmy układając wszystkie karty
w 64 kupki i na podstawie jakiejś sumy wybierając tylko jedną z nich do
przejrzenia. Ale teraz całą bazę 32 tysięcy kart AtXmega daje radę
przejrzeć liniowo chyba w 50ms (szczegółowego obliczenia nie znam, ale
nie sądzę, aby dłużej).

>> W tej chwili nie umiałbym tego udowodnić, ale to dotyczy RS485.
>> Standardu Wiegand też nikt nie przenosi na ethernet :)
>
> Jak widac jednak sporo elementow Ethernetu sie w koncu w systemie
> znalazlo :-)

Znów nie rozumiem.
Musisz łopatologicznie bo Ethernet to dla mnie czarna magia.
P.G.

do góry

On Tue, 23 Aug 2022 17:21:36 +0200, Piotr Gałka wrote:
> W dniu 2022-08-23 o 13:35, J.F pisze:
> Cieszę się, że się czepiasz :)
> Traktuję to jako pomoc w przygotowaniu się na ewentualne dyskusje bo w
> normie jest:
> "If you wish to give us your feedback on this publication...." i
> "W sprawach merytorycznych dotyczących treści normy można zwracać się.."
>
>> A jaki timeout dla potwierdzenia? Ile trzeba czekac az drzwi sie
>> otworzą ? :-)
>
> Nie mam pojęcia (to nie ja, to brat :) ).
> Zakładam, że system jest idealny według mojego pomysłu. O ile wiem brat
> nie wszystko wdrożył, bo zrobił próby (typu 10 urządzeń dostaje wspólnym
> drutem informację o zmianie stanu, który trzeba wysłać) i stwierdził
> skoro wszystko działa to nie ma co przesadzać.
>
> Najważniejsze jest oszacowanie jakie jest prawdopodobieństwa zderzenia.
> Jeśli jest odpowiednio małe to jak nawet z takim prawdopodobieństwem
> zdarzy się, że ktoś poczeka dodatkowe 100ms to świat się raczej nie zawali.

Jak masz 50 urzadzen na szynie .... ciekawe, czy mogą tak dociązyc
kontroler/serwer, ze nie nadązy odpowiadac :-)

tzn musialoby sie cos stac, ze wszystkie zechca naraz wysylac dane.
Jeden raz nie wystarczy, bo kontroler ktorys odbierze, potwierdzi i
ten zamilknie na dluzsza chwile.

Np piorun zasymuluje włamanie do wszystkich urządzen.
Albo ludzie sie zmówią i pare razy w jednej sekundzie machną kartami
przed czytnikami ..
... no dobra, moze i troche timeoutow bedzie, ale powinno sie szybko
odblokowac ...

>>> Na początku nie mieliśmy tych opóźnień i trafiliśmy raz (może 1996) na
>>> parę urządzeń, które wiecznie się zderzały - mijało kilka sekund (wiele
>>> ramek) zanim któremuś udało się być pierwszym.
>>
>> Tak tak, ethernet mial ciekawy pomysl :-)
>
> Nie rozumiem.

Losowe opoznienie ethernet ma od samego poczatku :-)

>> No fakt, moglby byc problem ... wiekszy radiator :-)
> W szczelnie zalanym czytniku ...

Zasilacz to Atari byl szczelnie zalany ... nie przeszkadzalo ...

>>>> Rozumiem, ze to twoje zyczenie, ale jak czytnik ma sprawdzic gdzies
>>>> "na serwerze", serwer sprawdzic "w bazie danych", to czas rosnie :-(
>>>
>>> Chyba nawet norma wymaga, że w przypadku odcięcia komunikacji z serwerem
>>> wszystko ma nadal działać. W każdym razie u nas wszystkie informacje są
>>> w kontrolerze (mała skrzyneczka na szynę DIN) zasilanym zasilaczem
>>> buforowym.
>>
>> Pisząc "serwer" mam na mysli jakis "kontroler systemu".
>> Gdzies tam macie przeciez zapisane ktore karty sa aktywne, jakie maja
>> uprawnienia itp.
>
> Kiedyś mając słabsze procesory kombinowaliśmy układając wszystkie karty
> w 64 kupki i na podstawie jakiejś sumy wybierając tylko jedną z nich do
> przejrzenia. Ale teraz całą bazę 32 tysięcy kart AtXmega daje radę
> przejrzeć liniowo chyba w 50ms (szczegółowego obliczenia nie znam, ale
> nie sądzę, aby dłużej).

Numer tam jakis macie, to mozna posortowac i binarnie szukac.

Chodzilo mi o to, ze chyba nie wysylacie tych danych kart do kazdego
zamka, zamki wysylaja do "centralnego kontrolera z baza danych" czy
jako tam sie nazywa fachowo nazywa.
Jak ten centralny kontroler/serwer padnie, to nie bardzo wiem
jak to ma dzialac w/g normy ...

>>> W tej chwili nie umiałbym tego udowodnić, ale to dotyczy RS485.
>>> Standardu Wiegand też nikt nie przenosi na ethernet :)
>>
>> Jak widac jednak sporo elementow Ethernetu sie w koncu w systemie
>> znalazlo :-)
>
> Znów nie rozumiem.
> Musisz łopatologicznie bo Ethernet to dla mnie czarna magia.

Ethernet działał praktycznie tak jak napisałes i to od lat 70-tych.
https://en.wikipedia.org/wiki/Carrier-sense_multiple
_access_with_collision_detection

stacje sprawdzały czy na kablu nic nie leci, wysyłały swoje,
wykrywały ewentualne kolizje, a po kolizji odczekiwały losowy czas
i wysyłały ponownie.
I tak do 16 razy, zwiekszajac górną granicę losowego czasu.

Teoretycznie tez moglo sie zdarzyc zablokowanie.

J.

do góry

2022-08-23 o 17:56 +0200, J.F napisał:
> stacje sprawdzały czy na kablu nic nie leci, wysyłały swoje,
> wykrywały ewentualne kolizje, a po kolizji odczekiwały losowy czas
> i wysyłały ponownie.
> I tak do 16 razy, zwiekszajac górną granicę losowego czasu.
>
> Teoretycznie tez moglo sie zdarzyc zablokowanie.

Praktycznie też, dlatego przecież zaczęto kombinować z bridgeami, aby
zmniejszyć domenę kolizyjną poprzez jej podział i zmniejszyć tym samym
prawdopodobieństwo wystąpienia sztormu. Jak czytałem opisy Piotra o
tych jego wynalazkach, od razu pomyślałem "O, ktoś tu na nowo odkrywa
stare CSMA/CD"... :)

Mateusz

do góry

On 19.08.2022 20:35, heby wrote:
> Niedawno na FB pojawiło się kilka filmików promujących jakiś system
> profesjonalny. Mieli tam wypasioną automatykę, że wentylator się właczy
> jak wejdziesz do łazienki itp "profesjonalne" zastosowania.

Według tej definicji zabawką z jednym pokrętłem jest Karcher WD5, a
dowolny robot sprzątający z aplikacją na telefon to profesjonalne
urządzenie.

> A ja chce czytać falwonik PV po RS485 i sterować adekwatnie pompą grzania basenu.

Sterujesz bezpośrednio falownikiem czy może jednak sterownikiem w tej PC
i użyłeś takiego skrótu myślowego?

--
Pozdrawiam,
Mateusz Bogusz

do góry

W dniu 2022-08-23 o 17:56, J.F pisze:

> Jak masz 50 urzadzen na szynie .... ciekawe, czy mogą tak dociązyc
> kontroler/serwer, ze nie nadązy odpowiadac :-)

Upraszczającym założeniem jest, że ramka ma 10 bajtów (1ms).
Przerwa na losowe opóźnienia - praktycznie do pominięcia.
Czyli rzędu 1000 ramek na sekundę.
Im więcej losowych time-slotów przewidzimy tym mniejsza szansa, że
najniższą wylosowaną wartość wylosują dwa lub więcej. Większe,
wylosowane wartości nas nie interesują, ale wprowadzimy nieco więcej
martwego czasu.
To jest olbrzymia liczba ramek. Mechanizm losowych opóźnień działa
sprawnie. Brat nawet nie wdrożył priorytetów.

> tzn musialoby sie cos stac, ze wszystkie zechca naraz wysylac dane.
> Jeden raz nie wystarczy, bo kontroler ktorys odbierze, potwierdzi i
> ten zamilknie na dluzsza chwile.
>
> Np piorun zasymuluje włamanie do wszystkich urządzen.
> Albo ludzie sie zmówią i pare razy w jednej sekundzie machną kartami
> przed czytnikami ..
> ... no dobra, moze i troche timeoutow bedzie, ale powinno sie szybko
> odblokowac ...

Trafienie przez ludzi z dokładnością do 3us - wybitnie nisko
prawdopodobne. Już większa szansa, że w ciągu trwania ramki 1ms uda im
się doprowadzić do tego, że góra 3 czytniki będą czekały na koniec tej
ramki, aby nadać swoje. Uważam, że uda im się to osiągnąć bardzo rzadko.
A tedy jeszcze jest niemała szansa, że nie doprowadzi to do zderzenia.
Musiałyby dwa wylosować dokładnie tę samą liczbę i to mniejszą niż
wylosuje trzeci. Dodatkowo to wcale nie gwarantuje zderzenia. Moment
uznania, że zakończyła się poprzednia transmisja będzie trochę różny u
każdego. Jak są bliżej siebie niż 300m to wykrycie, że ktoś wszedł na
linię będzie nie po 3us, ale po 2us (lub mniej).

>>> Tak tak, ethernet mial ciekawy pomysl :-)
>>
>> Nie rozumiem.
>
> Losowe opoznienie ethernet ma od samego poczatku :-)

A to nie wiedziałem. Przecież to połączenia jeden do jeden to po co
opóźnienia?
O! Zapomniałem, że kiedyś był na koncentryku.

> Chodzilo mi o to, ze chyba nie wysylacie tych danych kart do kazdego
> zamka, zamki wysylaja do "centralnego kontrolera z baza danych" czy
> jako tam sie nazywa fachowo nazywa.

Jak się fachowo nazywa to nie mam pojęcia. Nie kontaktujemy się z innymi
więc gadamy swoim wewnętrznym slangiem. A normy są po angielsku i
definiują jakieś skrótowce, których na pamięć nie znam.
A odpowiadając: Tak. Wysyłamy do każdego kontrolera ('zamka'). Z tym, że
żaden zamek nie ma postaci czytnika - czyli dane nigdy nie są w
urządzeniu znajdującym się poza strefą chronioną.
Nasz kontroler to skrzyneczka o szerokości 7cm na szynę DIN. Zdjęcia na
pewno do znalezienia w necie, ale ja już lata tam nie zaglądałem.
Cały proces wpuszczenia człowieka angażuje tylko komunikację po RS485.
W kontrolerze są praktycznie wpisane reguły wpuszczania na najbliższy
rok (włącznie z tym co ma być na Wielkanoc, czy Wigilię) i ma bufor na
chyba 48 tysięcy zdarzeń.

> Jak ten centralny kontroler/serwer padnie, to nie bardzo wiem
> jak to ma dzialac w/g normy ...

Dla mnie kontroler to coś co jest odległe od przejścia o RS485, a serwer
to jest coś odległego od kontrolera o Ethernet.
Zapewne źle używam słowa serwer. Norma raczej określa to jako konsola
operatora i określa (zależnie od grade) jakie funkcjonalności muszą
działać mimo przerwania komunikacji między kontrolerem a konsolą.

Do konsoli może być daleko. Mamy np. taką jedną instalację, że około 300
kontrolerów jest rozsianych po całej Polsce i jeden centralny serwer
jest sobie gdzieś tam.

>> Musisz łopatologicznie bo Ethernet to dla mnie czarna magia.
>
> Ethernet działał praktycznie tak jak napisałes i to od lat 70-tych.
> https://en.wikipedia.org/wiki/Carrier-sense_multiple
_access_with_collision_detection
>
> stacje sprawdzały czy na kablu nic nie leci, wysyłały swoje,
> wykrywały ewentualne kolizje, a po kolizji odczekiwały losowy czas
> i wysyłały ponownie.
> I tak do 16 razy, zwiekszajac górną granicę losowego czasu.
>
> Teoretycznie tez moglo sie zdarzyc zablokowanie.

Nie miałem pojęcia. Czyli wynalazłem koło.
RS485 używamy od 1995 i już mniej więcej wtedy przyjęliśmy sposób taki
jak opisuję. Ethernet (po skrętce) zaczęliśmy używać około 2012 i ja
praktycznie nic o tym nie wiem. Skrętka czyli jeden do jeden to w ogóle
mi się nie kojarzyło z jakimiś zderzeniami.
P.G.

do góry

2022-08-23 o 20:42 +0200, Piotr Gałka napisał:
> > Losowe opoznienie ethernet ma od samego poczatku :-)
>
> A to nie wiedziałem. Przecież to połączenia jeden do jeden to po co
> opóźnienia?
> O! Zapomniałem, że kiedyś był na koncentryku.

Na skrętce było tak samo. Tam nie miało miejsce "jeden do jeden", tylko
"jeden do wszystkich", a to za sprawą hubów. Sytuacja zmieniła się
dopiero po wprowadzeniu switchy, czyli relatywnie niedawno. Jeszcze 25
lat temu hub był normalnością.

Mateusz

do góry

On 23/08/2022 20:42, Mateusz Bogusz wrote:
>> A ja chce czytać falwonik PV po RS485 i sterować adekwatnie pompą
>> grzania basenu.
> Sterujesz bezpośrednio falownikiem czy może jednak sterownikiem w tej PC
> i użyłeś takiego skrótu myślowego?

Czytam PV, analizuję pogodę i na podstawie tego, algorytmicznie, steruje
czy właczyć PC i pompę wymiennika ciepła z basenem. Warunki są rózne, na
przykład "świeci od 5 minut z mocą 60%" albo "nie ma co odpalać, nawet
jak świeci, bo chmury w prognozie" itp.

do góry

On 23.08.2022 21:05, heby wrote:
>>> A ja chce czytać falwonik PV po RS485 i sterować adekwatnie pompą
>>> grzania basenu.
>> Sterujesz bezpośrednio falownikiem czy może jednak sterownikiem w tej
>> PC i użyłeś takiego skrótu myślowego?
>
> Czytam PV, analizuję pogodę i na podstawie tego, algorytmicznie, steruje
> czy właczyć PC i pompę wymiennika ciepła z basenem. Warunki są rózne, na
> przykład "świeci od 5 minut z mocą 60%" albo "nie ma co odpalać, nawet
> jak świeci, bo chmury w prognozie" itp.

A gdy algorytm uzna że włącza pompę, bo ładna pogoda itd. to dostajesz
powiadomienie "Dzisiaj się kąpiesz"? :-D

--
Pozdrawiam,
Mateusz Bogusz

do góry

On 24/08/2022 07:11, Mateusz Bogusz wrote:
>> Czytam PV, analizuję pogodę i na podstawie tego, algorytmicznie,
>> steruje czy właczyć PC i pompę wymiennika ciepła z basenem. Warunki są
>> rózne, na przykład "świeci od 5 minut z mocą 60%" albo "nie ma co
>> odpalać, nawet jak świeci, bo chmury w prognozie" itp.
> A gdy algorytm uzna że włącza pompę, bo ładna pogoda itd. to dostajesz
> powiadomienie "Dzisiaj się kąpiesz"? :-D

Każda sytaucja "jesteśmy w domu, jest ciepło, nie ma nic do roboty"
kończy się kąpielą.

W razie czego jest switch "dzisiaj nie grzej".

do góry