On 19.08.2022 20:55, Marek wrote:
> On Fri, 19 Aug 2022 20:35:22 +0200, heby <h...@p...onet.pl> wrote:

>> A ja chce
>> czytać falwonik PV po RS485 i sterować adekwatnie pompą grzania basenu.
>
> Margines potrzeb.
>
I to mnie właśnie wk... w podejściu "profesjonalnych" - nie pozwólmy
klientowi na nic czego sami nie uznamy za potrzebne.
BTW - po co po 485 jak każdy falownik ma wifi?

--
Mirek.

do góry

On 19/08/2022 21:39, Mirek wrote:
> BTW - po co po 485 jak każdy falownik ma wifi?

a) nie udało mi się po wifi wyjąć tego, co wyjmuje po RS485. Mimo, że
sprawa prosta - to tylko proste proxy TCP>RS485, to część rejestrów jest
"niewidoczna" po stronie wifi. Aplikacja producenta posługuje się jakimś
zaszyfrowanym protokołem. Nie było sensu tracić czasu.

b) akurat falownik jest poganiany przez Pi Zero. Pi robi jako dodatkowa
algorytmika uśredniająca dośc szumiący stan rejestrów. Mogłbym to zrobić
na poziomie HA ale Pi z Pythonem było prościej i robiło (i dalej robi)
jako debugger, bo nie wszystko jeszcze udało mi się znaleźć w rejestrach.

do góry

On 19.08.2022 21:48, heby wrote:

> a) nie udało mi się po wifi wyjąć tego, co wyjmuje po RS485.
Ja wyjąłem z Sofar-a moc na DC z tego http co jest do konfiguracji -
klientowi to wystarcza, ale faktycznie wiele więcej tam nie ma.

--
Mirek.

do góry

W dniu 2022-08-19 o 19:31, heby pisze:

> Natychmiastowa. Jestem uczolony na responsywność, dlatego to dla mnie
> krytyczne.

Skojarzenie z responsywność. Nie całkiem na temat, ale jestem akurat
wściekły i jak sobie ponarzekam to może mi ulży :)

Na RS485 od zawsze (czyli okolice 1995) działamy tak, że jak ktoś się
chce odezwać to się odzywa.
W ten sposób np. sygnał z tampera, że ktoś zerwał urządzenie ze ściany
zostanie przesłany praktycznie natychmiast. Atakujący nie zdąży przeciąć
kabla co skutkowało by informacją 'urządzenie nie odpowiada' zamiast
'zostało zerwane ze ściany'. Według mnie prawidłowa informacja ma swoją
wartość.

Miesiąc temu, ktoś kto od nas bierze sprzęt do realizacji instalacji ze
swoim oprogramowaniem przekazał nam, że zamawiający wpisał w wymagania
spełnienie normy PN-EN IEC 60839-11-5:2020. Opisuje ona 'Otwarty
protokół urządzenia nadzorowanego' w systemach kontroli dostępu. Nie
wiedzieliśmy, że to już jest ujęte w normę.

Mam tę normę od 2 tygodni i ... szok i totalna załamka. Urządzenia nie
mogą się odezwać nie pytane - czyli ciągłe przeglądanie. Na odpowiedź
mają 200ms, ale zalecane jest aby zdążyły odpowiedzieć w 3ms.

Kolega był kiedyś z kimś na obiekcie, gdzie po każdym zbliżeniu karty do
czytnika czekali ze 2..3 s aż drzwi się otworzą. I ten gość traktował to
jako normę. Dla mnie niewyobrażalne. Według mnie wypracowanie decyzji o
otwarciu drzwi nie powinno zajmować więcej niż 50 (no góra 100) ms.

Dopuszczamy do 50 urządzeń na szynie. Przeglądanie może zająć trochę
czasu szczególnie jak urządzenia (obce) na serio potraktują te 200ms.
Wygląda na to, że albo wypadniemy z rynku, albo się dopasujemy i wkrótce
nasz system zacznie działać tak jak kolega tego wtedy doświadczył.

Driver RS485 odbierając bierze 0,3mA, nadając jakieś 40mA (rezystory
terminalowe). Cały świat kombinuje jak by tu zaoszczędzić energię.
Wprowadza się limity na moc stand-by. A tu nagle się okazuje, że
wszystkie szyny RS485 wszystkich systemów kontroli dostępu mają zużywać
według moich szacunków przeciętnie około 300 razy więcej energii niż
faktycznie potrzebują jednocześnie tracąc responsywność.

Do tej pory sądziłem, że nie ma głupich norm.
P.G.

do góry

On Mon, 22 Aug 2022 14:08:26 +0200, Piotr Gałka wrote:
> W dniu 2022-08-19 o 19:31, heby pisze:
>> Natychmiastowa. Jestem uczolony na responsywność, dlatego to dla mnie
>> krytyczne.
>
> Skojarzenie z responsywność. Nie całkiem na temat, ale jestem akurat
> wściekły i jak sobie ponarzekam to może mi ulży :)
>
> Na RS485 od zawsze (czyli okolice 1995) działamy tak, że jak ktoś się
> chce odezwać to się odzywa.

Co zaraz powoduje problemy pod tytulem kolizje.
Wykrywacie?

> W ten sposób np. sygnał z tampera, że ktoś zerwał urządzenie ze ściany
> zostanie przesłany praktycznie natychmiast. Atakujący nie zdąży przeciąć
> kabla co skutkowało by informacją 'urządzenie nie odpowiada' zamiast
> 'zostało zerwane ze ściany'. Według mnie prawidłowa informacja ma swoją
> wartość.
>
> Miesiąc temu, ktoś kto od nas bierze sprzęt do realizacji instalacji ze
> swoim oprogramowaniem przekazał nam, że zamawiający wpisał w wymagania
> spełnienie normy PN-EN IEC 60839-11-5:2020. Opisuje ona 'Otwarty
> protokół urządzenia nadzorowanego' w systemach kontroli dostępu. Nie
> wiedzieliśmy, że to już jest ujęte w normę.
>
> Mam tę normę od 2 tygodni i ... szok i totalna załamka. Urządzenia nie
> mogą się odezwać nie pytane - czyli ciągłe przeglądanie. Na odpowiedź
> mają 200ms, ale zalecane jest aby zdążyły odpowiedzieć w 3ms.

Przy niewielkiej ilosci szybkich urzadzen - moze to nie problem.
Bedą odpytywane co poł sekundy ...

> Kolega był kiedyś z kimś na obiekcie, gdzie po każdym zbliżeniu karty do
> czytnika czekali ze 2..3 s aż drzwi się otworzą. I ten gość traktował to
> jako normę. Dla mnie niewyobrażalne. Według mnie wypracowanie decyzji o
> otwarciu drzwi nie powinno zajmować więcej niż 50 (no góra 100) ms.

Komputery coraz szybsze, a Windows coraz wolniejszy :-)

Rozumiem, ze to twoje zyczenie, ale jak czytnik ma sprawdzic gdzies
"na serwerze", serwer sprawdzic "w bazie danych", to czas rosnie :-(

> Dopuszczamy do 50 urządzeń na szynie. Przeglądanie może zająć trochę
> czasu szczególnie jak urządzenia (obce) na serio potraktują te 200ms.
> Wygląda na to, że albo wypadniemy z rynku, albo się dopasujemy i wkrótce
> nasz system zacznie działać tak jak kolega tego wtedy doświadczył.

> Driver RS485 odbierając bierze 0,3mA, nadając jakieś 40mA (rezystory
> terminalowe). Cały świat kombinuje jak by tu zaoszczędzić energię.
> Wprowadza się limity na moc stand-by. A tu nagle się okazuje, że
> wszystkie szyny RS485 wszystkich systemów kontroli dostępu mają zużywać
> według moich szacunków przeciętnie około 300 razy więcej energii niż
> faktycznie potrzebują jednocześnie tracąc responsywność.

> Do tej pory sądziłem, że nie ma głupich norm.

Dorobicie "koncentrator szyn", bedzie 10 urzadzen na szynie i 5 szyn,
podniesiecie predkosc - to sie okaze, nadajnik wiekszosc czasu jednak
nie pracuje.

A norma ... no coz, moze miala cos innego na celu.
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".

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

J.

do góry

Hello Piotr,

Monday, August 22, 2022, 2:08:26 PM, you wrote:

[...]

> Do tej pory sądziłem, że nie ma głupich norm.

Głupie normy? Kiedyś żądano na dopuszczenie szybowców do lotów testów
zniszczeniowych wszystkich egzemplarzy. Jakoś tak dziwnie, że
obowiązywało tylko polskie szybowce. Na szczęście szybko się
opamiętali.

Z aktualnych norm - norma na transformatory zezwala na używanie drutów
w pełnej izolacji (FIW) dla izolacji wzmocnionej. Ale wymaga cyklu 72
godzin testowania termicznego transformatorów, w różnych
temperaturach, z pomiarami pośrednimi. Wyjątkowo durny i drogi test.
Oczywiście transformatory nawijane drutami w potrójnej izolacja (TIW)
- starsza technologia - nie wymagają takich testów.

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

On 2022-08-19 18:39, Marek wrote:
> On Thu, 18 Aug 2022 13:07:08 +0200,
> LordBluzg(R)??<m...@p...onet.pl> wrote:
>> Raczej nie znasz języków :)
>
> Nie muszę znać języków, żeby stwierdzić że coś po polsku brzmi głupio.
>
Jak osławione żarówki :-)
Przerzutki rowerowe...
i co jeszcze?


;-)

do góry

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.

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.
Wprowadziliśmy opóźnienia i problem już nigdy się nie pojawił.
Jak dokładnie to jest zrealizowane to tego nie wiem. Ale np. każdy
losuje liczbę z zakresu 0..15 i odmierza tyle razy 5us jako opóźnienie.
Wiadomo - generator pseudolosowy więc ryzyko synchronizacji. Generator
więc uwzględnia typ i numer urządzenia (czyli niepowtarzalny komplet) i
miesza to (stosujemy procki z hardwareowym AES) aby nie było ryzyka
wiecznie takich samych liczb pseudo-losowych.

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

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.

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

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

> 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 :)
P.G.

do góry

On 22.08.2022 20:21, Piotr Gałka wrote:

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

I gdzie jest ta sankcjonowana normami szyna?
Od czytnika do kontrolera czy od kontrolerów do jakiejś centralki?

--
Mirek.

do góry

W dniu 2022-08-22 o 22:24, Mirek pisze:
> On 22.08.2022 20:21, Piotr Gałka wrote:
>
>> 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.
>
> I gdzie jest ta sankcjonowana normami szyna?
> Od czytnika do kontrolera czy od kontrolerów do jakiejś centralki?
>

Od czytników (wielu) i innych urządzeń do kontrolera. My dopuszczamy do
50 urządzeń na tej szynie.
Co to inne urządzenia?
Nasz kontroler ma np. tylko 2 wyjścia przekaźnikowe bo najczęściej jest
używany do kontrolowania jednego przejścia. Jak ma obsłużyć np. 8
przejść to trzeba podłączyć moduł zawierający dodatkowe wyjścia. A
wyższe grade normy może zmuszać do większej liczy wyjść na jedne drzwi -
np. obowiązkowa sygnalizacja niedomknięcia drzwi.

Intencją tej normy o której pisałem jest zastąpienie od wieków używanego
standardu Wiegand jakimś nowocześniejszym standardem.

Wiegand (dla tych, co nie wiedzą) to 2 druty OC i po nich lecą impulsy.
Impuls na jednym to 0, na drugim to 1. Prędkość dowolna w szerokim zakresie.
Były np. karty metalowe (podobno stosowane w kopalniach bo
niezniszczalne) z dwoma rzędami prostokątnych dziurek i czytnik z dwiema
fotokomórkami, bez żadnej logiki mógł wysyłać transmisję Wiegand przy
przeciąganiu takiej karty.

Wiegnad:
- jest jednokierunkowy - nie pozwala wykryć odcięcia/awarii czytnika,
- nie przewiduje wysyłania innej informacji niż nr karty,
- nie daje się szyfrować,
- wiele urządzeń obsługuje maksymalnie WIEGAND 37, czyli 35 bitów, a
obecne karty mają nr 7 bajtowy (56 bitów).

Norma kontroli dostępu wymaga (przy grade 3) aby połączenie od czytnika
do kontrolera było:
- albo szyfrowane,
- albo zabezpieczone przed dostępem (puszczenie kabla w plastikowym
korytku raczej nie zostanie uznane z zabezpieczenie).
P.G.

do góry