Standardy w automatyce domowej

Jaka rezponsywność? Przełączając przycisk osoba wyczuje, że to nie jest klasyczny wyłącznik? Co z problemami na switchu, AP?

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

Jesli w HA kliknę w przełacznik na ekranie laptopa czy telefonu, to razem z kliknięciem myszki, czy puknięciem palca słyszę kliknięcie przekaźnika w sonoff, podpiętego pod wifi.

Zaryzykuje, że grubo poniżej 100ms. Prędzej poniżej 50ms.

W przypadku sonoff T1 jest lekkie opóźnienie, bo to sensor dotyku i wymaga wyczyszczenia sygnału z szumu, wiec jest ze 300ms od dotknięcia, do zapalenia światła.

Masz też opcję używania normalnego wyłacznika oświetleniowego i pod niego wciska się (jak puszka głebsza) sonoff mini. Na zewnątrz wygląda jak zwykły wyłacznik i działa dokładnie tak jak się spodziewasz. W środku możesz sterować oświetleniem z HA (albo z aplikacji sonoff, ale to jest "chmurowa").

Pozycja wyłacznika jest wtedy "płynna", w sensie, że nie wiadomo gdzie jest włacz, ale wiadomo, że jak przestawisz, to się włączy i odwrotnie. Możesz też mieć stabilny stan po powrocie zasilania.

Używałem jednego takiego. Działało natychmiastowo, nie zgadł byś, że w środku jest automatyka. Tanie to, jak barszcz.

A druga część pytania?

Problemy na switchu i AP są problemami na switchu i AP. Kupisz lepsze, problem nie istnieje.

Ja używam routerów wifi xiaomi, z podmienionym softem na OpenWRT. Nie do końca polecam, raz na pół roku przestają działać. Przypuszczalnie to wina eksperymentalnego wsparcia OpenWRT. Być może zmienie to na jakiś mesh, ale na razie nie mam silnego parcia na mesh a mash ma [za] silne parcie na kasę.

Jesli awarii ulegnie AP, wyłaczniki (T1 i mini) dalej działają po staremu. Możeś światło właczyć i wyłaczyć.

Ogólnie nie mam w domu jakiejkolwiek automatyki zaleznej od centralnego serwera. Jak coś padnie - to dalej wszystko funkcjonuje po staremu, tracę tylko wygodne sterowanie przez telefon, musze podejśc do ściany, do roobmy, do tv, do pompy ciepła itd.

To jedyny powód, dla którego buduje to samodzielnie: bo mam kontrolę aby to działało mimo awarii.

Niedaleko mnie jest dom, gdzie automatykę zrobiono "profesjonalnie" głośno parskając na wszelakie HA dla biedaków i tam padnięcie routera wifi zablokowało bramę wjazdową do garażu. Ratowałem to hackerskimi sztuczkami rodem z wardrivingu.

W przypadku ESPHome, jak padnie AP, to wyłącznik przestawi się sam w tryb AP i pozwoli się z sobą połączyć z telefonu/komputera (z hasłem oczywiście). Wiec nie tylko fuckup niczego nie uniemozliwia, ale recovery takiego wyłacznika w ścianie jest możliwy bez wstawania z łóżka.

No ale dla usera jest to nadal problem wyłącznika bo nie działa, co się po drodze zepsuło to kwestia wtórna.

Na czym? Ostatnio sąsiad mi się pochwalił, że zrobił całość na satelu (Integra 128 chyba). Aplikacja (interfejs) taki sobie, mój mu się bardziej podobał. Ale przy okazji się do niego wproszę bo nie zdazylem ustalić szczegółów jakie ma elementy wykonawcze (przekaźniki?) jakie wyłączniki w ścianie, jaka rezponsywność itp. Ogólnie to bardzo mnie ciekawi jak rozwiązania profesjonalne się sprawdzają w porównaniu do tych otwartych.

Wyłącznik działa. Nie działa zdalne sterowanie tym wyłącznikiem z aplikacji.

W wyniku awari dostajesz normalny dom, nieinteligentny, ale i niepopsuty.

Nie wiem. Jakaś nazwa padła, ale nie udało mi się jej zapamiętać, to dawno było. Nie widziałem z restą sterownika. Zhackowałem to stawiajac fałszywy AP, połaczyłem się ze sterownikiem i udało się go uruchmić jakąs aplikacją diagnostyczną producenta, zwolnił blokadę. Dało się, bo miałem oryginalne hasła do wifi, normalnie to nie było aż takie dziadowskie.

Niedawno gadałem z monterem. Montują na rozwiązaniach ZigBee, philipsa bodaj (?). Podobno ludzie zadowoleni. Chodzą przez tydzień po sąsiadach i pokazują jak właczyć oświetlenie tarasu z telefonu. Przeszczęśliwi, że technologia kosmiczna.

Przedstawiłem mu, co ja potrzebuje.

Więcej jak połowa niewykonalna.

Z tej połowy wykonalnej, da się, ale inaczej. W większości tylko te trywialne się da ot tak.

W efekcie wole juz rozwiązanie darmowe. Jak czegoś nie ma, to sobie dorobię. Ale jest prawie wszystko.

No i ZigBee jest gówniane. Mam kilka. Zasięg mierny, często znika bez powodu, 99% rozwiązań komercyjnych wymaga internetu i chińskiej chmury, ograniczone możliwości do trywializmów.

Absolutnie nie mówie, że HA+ESPome jest dla ludzi. To dla nerdów z lutownicą. Ale jak już je ustawisz, to mi o "nieprofesjonalności" rozwiazań darmowych pada na pysk. Rozwiązania komercyjne są projektowane pod idiotów i mają dokładnie takie możliwości, jake idioci chcą mieć. Nic ponad to.

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. A ja chce czytać falwonik PV po RS485 i sterować adekwatnie pompą grzania basenu. I się nie da, bo profsjonalne rozwiązania nie mają stosownych możliwości. Kurtyna.

No *nie* działa. Jesteś już w drodze 300km od domu i sobie przypomniałeś, że w pokoju zostawiłeś włączone światło. A w domu brak (myślącego) białka do tej roboty. Jak jesteś w stanie namówić telefonicznie kota by wcisnął w domu przycisk to nie było tematu. Ale nadal z popsutym switchem c*ujnia bo obrazu z kamery nie zobaczysz.

j.w., to zależy od okoliczności.

No ale czy trochę nie przesadzasz z potrzebami? To co mi pokazywał co ma na satelu to dość złożone było. Wyłączniki, termometry, termostaty, reakcja na pogodę. Oczywiście diabeł tkwi w szczegółach, bo u niego zmiana logiki działania czegoś to wymaga podłączenie laptopa i przeprogramowanie, u mnie kilka kilków w interfejsie webowym sterownika. Ja realizujac własny projekt zacząłem od oświetlenia, termostatów i bezprzewodowych ekspanderów realizujących funkcje wyłącznika i/lub termostatu. Zrezygnowałem z sterowania gniazdek, zbędne. A jak raz na rok do czegoś potrzebne ad hoc to realizuje to bezprzewodowym ekspanderem w obudowie dogniazdkowej. Czyli generalnie oświetlenie + termostat (bojler, piec). Nie widzę potrzeby więcej.

Margines potrzeb.

Ok. Nie działa. Jak często? Jedyny problem, to kiepski AP. Stabilnośc samych urządzeń końcowych jest ~3 lata z mojego doświadczenia, bo tyle mam najdłuej działający bezawaryjnie, a z doświadczenia innych pewnie dłużej. ESP8622 to całkiem dobrze obcykany scalak...

A jak często psują się switche? Bo mój ma koło 10 lat. Kosztował grosze. Używany. Więc pewnie ma wiecej.

Na marginesie: mam w domu kilka AP na tym samym SSID. To nie jest mesh, ale jak jeden padnie, przepina się samodzielnie do innego.

Jesli byłbym już skrajnym paranoikiem, to do każdego z tych urządzeń mogę podpiąć mechaniczny reseter zasilania, o 3am.

W sumie, w jednym, krytycznym, mam tak zrobione...

Nie. Dlatego, że mam rozwiązanie, które je pokrywa. Wic to nie są potrzeby niewykonalne, jedynie wymagajace większego wysiłku do ich zaspokojenia.

Przesadzałbym, gdyby takie rozwiązanie nie istniało.

I dlatego rozwiązania profesjonale są zbyt prymitywne i nie mogę ich uzywać.

Ale co najbardziej śmieszne: HA ma możliwośc sterowania niektórymi z nich.

Czy w tym momencie staja się nieprofesjonalne?

Ja mam podobne doświadczenia. Prędzej czy później dochodzisz do ściany i trzeba obok postawić swoje Raspberry, bo czegoś się NIE DA, albo trzeba wymienić połowę systemu do nowej wersji. A w nowej wersji są nowe problemy itd.

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?

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.

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.

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.

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.

Jak osławione żarówki :-) Przerzutki rowerowe... i co jeszcze?

;-)

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.

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

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.

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.