Jakie są aktualne standardy w automatyce domowej dla MQTT i Ethernet?

Fri Aug 19, 2022 9:39 pm   

On 19.08.2022 20:55, Marek wrote:

klientowi na nic czego sami nie uznamy za potrzebne.
BTW - po co po 485 jak każdy falownik ma wifi?

--
Mirek.

Fri Aug 19, 2022 9:48 pm   

On 19/08/2022 21:39, Mirek wrote:

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.

Fri Aug 19, 2022 10:08 pm   

On 19.08.2022 21:48, heby wrote:


klientowi to wystarcza, ale faktycznie wiele więcej tam nie ma.

--
Mirek.

Mon Aug 22, 2022 2:08 pm   

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


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.

Mon Aug 22, 2022 2:32 pm   

On Mon, 22 Aug 2022 14:08:26 +0200, Piotr Gałka wrote:

Co zaraz powoduje problemy pod tytulem kolizje.
Wykrywacie?


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


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


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.

Mon Aug 22, 2022 3:34 pm   

Hello Piotr,

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

[...]


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

Mon Aug 22, 2022 4:26 pm   

Mon Aug 22, 2022 8:21 pm   

W dniu 2022-08-22 o 14:32, J.F pisze:


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


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.


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.


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


W tej chwili nie umiałbym tego udowodnić, ale to dotyczy RS485.
Standardu Wiegand też nikt nie przenosi na ethernet
P.G.

Mon Aug 22, 2022 10:24 pm   

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


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

--
Mirek.

Tue Aug 23, 2022 10:53 am   

W dniu 2022-08-22 o 22:24, Mirek pisze:

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.

Tue Aug 23, 2022 1:35 pm   

On Mon, 22 Aug 2022 20:21:52 +0200, Piotr Gałka wrote:

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


Tak tak, ethernet mial ciekawy pomysl :-)


Ale to juz brzmi jak polling.


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


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



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


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


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

J.

Tue Aug 23, 2022 5:21 pm   

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


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.


Nie rozumiem.


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.


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.


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.


W szczelnie zalanym czytniku ...


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


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

Tue Aug 23, 2022 5:56 pm   

On Tue, 23 Aug 2022 17:21:36 +0200, Piotr Gałka wrote:

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


Losowe opoznienie ethernet ma od samego poczatku :-)


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


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


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.

Tue Aug 23, 2022 8:31 pm   

2022-08-23 o 17:56 +0200, J.F napisał:

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

Tue Aug 23, 2022 8:42 pm   

On 19.08.2022 20:35, heby wrote:

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.


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

--
Pozdrawiam,
Mateusz Bogusz