Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Standardy w automatyce domowej
79 views
Skip to first unread message
Atlantis
Aug 18, 2022, 5:30:51 AM8/18/22
to
Parę lat temu zacząłem projektować moduły, które miały stanowić element
prostego systemu automatyki domowej - płytka wyposażona w interfejs
Ethernet, która komunikowałaby się ze światem za pośrednictwem protokołu
MQTT, sterowała załączaniem świateł i informowała o zdarzeniach
(otwarcie drzwi albo okna, naciśnięcie przycisku na ścianie, odczytanie
danych z jakiegoś czujnika temperatury/ciśnienia/wilgotności).
Początkowo planowałem wszystko napisać samodzielnie - zarówno firmware
do mikrokontrolerów, jak i prosty interfejs webowy albo aplikację
mobilną. Potem jednak projekt trafił na chwilę do szuflady, a w
międzyczasie zaczęły się pojawiać coraz powszechniejsze rozwiązania
komercyjne oparte na "inteligentnych żarówkach" z wbudowanym WiFi
(tudzież modułami RF, współpracującymi z dedykowaną bramką sieciową).
Ludzie zaczęli też się chwalić projektami automatyki domowej, opartymi
na gotowym sofcie odpalanym na Raspberry Pi albo innych miniaturowych
komputerkach.
Czy na chwilę obecną istnieją już jakieś powszechnie obowiązujące
standardy, których mógłbym się trzymać pisząc firmware do swoich
modułów? Nie chciałbym wynajdować koła na nowo i potem pisać osobne
proxy pośredniczące w komunikacji pomiędzy moimi modułami albo jakimś
Domoticzem lub innym podobnym systemem.
prostego systemu automatyki domowej - płytka wyposażona w interfejs
Ethernet, która komunikowałaby się ze światem za pośrednictwem protokołu
MQTT, sterowała załączaniem świateł i informowała o zdarzeniach
(otwarcie drzwi albo okna, naciśnięcie przycisku na ścianie, odczytanie
danych z jakiegoś czujnika temperatury/ciśnienia/wilgotności).
Początkowo planowałem wszystko napisać samodzielnie - zarówno firmware
do mikrokontrolerów, jak i prosty interfejs webowy albo aplikację
mobilną. Potem jednak projekt trafił na chwilę do szuflady, a w
międzyczasie zaczęły się pojawiać coraz powszechniejsze rozwiązania
komercyjne oparte na "inteligentnych żarówkach" z wbudowanym WiFi
(tudzież modułami RF, współpracującymi z dedykowaną bramką sieciową).
Ludzie zaczęli też się chwalić projektami automatyki domowej, opartymi
na gotowym sofcie odpalanym na Raspberry Pi albo innych miniaturowych
komputerkach.
Czy na chwilę obecną istnieją już jakieś powszechnie obowiązujące
standardy, których mógłbym się trzymać pisząc firmware do swoich
modułów? Nie chciałbym wynajdować koła na nowo i potem pisać osobne
proxy pośredniczące w komunikacji pomiędzy moimi modułami albo jakimś
Domoticzem lub innym podobnym systemem.
Marek
Aug 18, 2022, 5:40:16 AM8/18/22
to
On Thu, 18 Aug 2022 11:30:49 +0200, Atlantis <marekw19...@wp.pl>
wrote:
--
Marek
wrote:
> Domoticzem lub innym podobnym systemem.
Co to Domoticz?
--
Marek
LordBluzg®🇵🇱
Aug 18, 2022, 6:25:27 AM8/18/22
to
W dniu 18.08.2022 o 11:40, Marek pisze:
>> Domoticzem lub innym podobnym systemem.
>
> Co to Domoticz?
>
https://www.domoticz.com
--
LordBluzg®🇵🇱
<<<ƧiԳ ćɒdɘႱ i Putina i ęjcaredefnoK>>>
>> Domoticzem lub innym podobnym systemem.
>
> Co to Domoticz?
>
--
LordBluzg®🇵🇱
<<<ƧiԳ ćɒdɘႱ i Putina i ęjcaredefnoK>>>
heby
Aug 18, 2022, 6:25:42 AM8/18/22
to
On 18/08/2022 11:30, Atlantis wrote:
> Czy na chwilę obecną istnieją już jakieś powszechnie obowiązujące
> standardy, których mógłbym się trzymać pisząc firmware do swoich
> modułów?
Raczej narzędzia.
> Czy na chwilę obecną istnieją już jakieś powszechnie obowiązujące
> standardy, których mógłbym się trzymać pisząc firmware do swoich
> modułów?
Home Assistant + ESPHome.
Z grubsza: ESPHome pozwala na "napisanie" termostatu na ESP8266 w minutę
i spięcie go z HomeAssistantem w następną minutę. Po dwóch minutach maś
śliczny UI w przeglądarce do kontroli termostatu.
ESPHome jest w wersji, będącej toolem w środku HomeAssistanta i
pozwalając na programowanie (kompilacja, edyca itd) z poziomu
przegladarki z automatyczną aktualizacją firmware po WiFi. Wspiera
większośc gotowców, takich jak sonoff.
Do zagadnień typu "fikuśny wylacznik śwaitła ze ściemniaczem, wyrzutnią
Iskanderów i czujnikiem zmierzchu" jak znalazł.
Używam.
LordBluzg®🇵🇱
Aug 18, 2022, 6:31:28 AM8/18/22
to
W dniu 18.08.2022 o 11:30, Atlantis pisze:
> Czy na chwilę obecną istnieją już jakieś powszechnie obowiązujące
> standardy, których mógłbym się trzymać pisząc firmware do swoich
> modułów?
Raczej nie istnieją standardy. Napisałbym, że to część konkurencji i
każdy system ma inne firmware. Raz jeden jest bardziej popularny a
później inny. Później każdy chwali to, w co akurat wdepnał.
> Nie chciałbym wynajdować koła na nowo i potem pisać osobne
> proxy pośredniczące w komunikacji pomiędzy moimi modułami albo jakimś
> Domoticzem lub innym podobnym systemem.
Chyba jednak właściwiej napisać proxy, bo wtedy możesz się oprzeć o
wiele systemów ale google home ma już takie "proxy" więc nie wiem czy w
ogóle warto tworzyć na nowo.
> Czy na chwilę obecną istnieją już jakieś powszechnie obowiązujące
> standardy, których mógłbym się trzymać pisząc firmware do swoich
> modułów?
każdy system ma inne firmware. Raz jeden jest bardziej popularny a
później inny. Później każdy chwali to, w co akurat wdepnał.
> Nie chciałbym wynajdować koła na nowo i potem pisać osobne
> proxy pośredniczące w komunikacji pomiędzy moimi modułami albo jakimś
> Domoticzem lub innym podobnym systemem.
wiele systemów ale google home ma już takie "proxy" więc nie wiem czy w
ogóle warto tworzyć na nowo.
Marek
Aug 18, 2022, 7:02:04 AM8/18/22
to
On Thu, 18 Aug 2022 12:25:09 +0200,
LordBluzg®🇵🇱<mka...@poczta.onet.pl> wrote:
> https://www.domoticz.com
Ło matko jaka nazwa, myślałem że to jakiś lapsus językowy.
--
Marek
LordBluzg®🇵🇱<mka...@poczta.onet.pl> wrote:
> https://www.domoticz.com
Ło matko jaka nazwa, myślałem że to jakiś lapsus językowy.
--
Marek
Marek
Aug 18, 2022, 7:07:04 AM8/18/22
to
On Thu, 18 Aug 2022 12:25:32 +0200, heby <he...@poczta.onet.pl> wrote:
> Raczej narzędzia.
> Home Assistant + ESPHome.
On chyba raczej pyta o protokoły, sposoby oraz metody a nie o gotowe
> Raczej narzędzia.
> Home Assistant + ESPHome.
narzędzia...
--
Marek
LordBluzg®🇵🇱
Aug 18, 2022, 7:07:53 AM8/18/22
to
W dniu 18.08.2022 o 13:02, Marek pisze:
Raczej nie znasz języków :)
https://translate.google.pl/?sl=es&tl=pl&text=domoticz&op=translate
heby
Aug 18, 2022, 7:18:00 AM8/18/22
to
On 18/08/2022 13:06, Marek wrote:
>> Raczej narzędzia.
>> Home Assistant + ESPHome.
> On chyba raczej pyta o protokoły, sposoby oraz metody a nie o gotowe
> narzędzia...
ESPHome jest czymś w rodzaju protokołu i gotowego narzędzia w jednym
>> Raczej narzędzia.
>> Home Assistant + ESPHome.
> On chyba raczej pyta o protokoły, sposoby oraz metody a nie o gotowe
> narzędzia...
właśnie.
Pisanie dzisiaj od zera stosu TCP z MQTT jest mało sensowne.
Integracja rózncyh systemów automatyki nie odbywa się na protokołach,
tylko na wysokich abstrakcjach, jak HomeAssistant. Nie da się rozmawiać
o tym w oderwaniu od narzędzi.
Atlantis
Aug 18, 2022, 9:16:48 AM8/18/22
to
On 18.08.2022 13:17, heby wrote:
> Pisanie dzisiaj od zera stosu TCP z MQTT jest mało sensowne.
Stosu TCP nie muszę pisać, bo mam bibliotekę od Microchipa, którą
> Pisanie dzisiaj od zera stosu TCP z MQTT jest mało sensowne.
wykorzystuję w swoich projektach. Z MQTT trochę gorzej, bo nie została
ona zaimplementowana dla tego stosu - istnieje co prawda biblioteka
napisana przez kogoś, ale nie do końca działająca i posiadająca sporo
błędów - obecnie ją właśnie poprawiam.
Tyle tylko, że MQTT to tylko protokół odpowiedzialny za przesyłanie
informacji za pośrednictwem TCP. Mogę za jego pomocą przesyłać niemal
dowolne dane, w niemal dowolnej formie. Aplikacja odpowiedzialna za
zarządzanie automatyką domową może równie dobrze oczekiwać tam JSON-ów o
odpowiedniej zawartości, jakiegoś innego protokołu opartego o ASCII,
albo komend binarnych.
I właśnie tego dotyczyło moje pytanie. Bo zakładam, że systemy
automatyki działają właśnie w oparciu o jakiś broker MQTT. Pozostaje
jednak jeszcze kwestia nazewnictwa tematów i przesyłanej zawartości.
Piotrek
Aug 18, 2022, 9:41:18 AM8/18/22
to
On 18.08.2022 15:16, Atlantis wrote:
> [...] Aplikacja odpowiedzialna za
mechanizm pluginów, bindingów, czy jak to jeszcze inaczej nazywają (np.
proxy), wykorzystujący API dostarczane przez aplikację zarządzającą.
I wcale MQTT nie jest jakąś dominującą szyną ...
Domoticzem się mocno nie interesowałem, ale używam na co dzień OpenHAB -
tam tych pluginów jest ponad 200, przy czym MQTT występuje właśnie jako
binding - obok modbus, ZigBee, etc.
Piotrek
> [...] Aplikacja odpowiedzialna za
> zarządzanie automatyką domową może równie dobrze oczekiwać tam JSON-ów o
> odpowiedniej zawartości, jakiegoś innego protokołu opartego o ASCII,
> albo komend binarnych.
> I właśnie tego dotyczyło moje pytanie. Bo zakładam, że systemy
> automatyki działają właśnie w oparciu o jakiś broker MQTT. Pozostaje
> jednak jeszcze kwestia nazewnictwa tematów i przesyłanej zawartości.
>
Jeśli sprzęt nie jest obsługiwany negatywnie to z reguły jest dostępny
> odpowiedniej zawartości, jakiegoś innego protokołu opartego o ASCII,
> albo komend binarnych.
> I właśnie tego dotyczyło moje pytanie. Bo zakładam, że systemy
> automatyki działają właśnie w oparciu o jakiś broker MQTT. Pozostaje
> jednak jeszcze kwestia nazewnictwa tematów i przesyłanej zawartości.
>
mechanizm pluginów, bindingów, czy jak to jeszcze inaczej nazywają (np.
proxy), wykorzystujący API dostarczane przez aplikację zarządzającą.
I wcale MQTT nie jest jakąś dominującą szyną ...
Domoticzem się mocno nie interesowałem, ale używam na co dzień OpenHAB -
tam tych pluginów jest ponad 200, przy czym MQTT występuje właśnie jako
binding - obok modbus, ZigBee, etc.
Piotrek
heby
Aug 18, 2022, 9:47:31 AM8/18/22
to
On 18/08/2022 15:16, Atlantis wrote:
> I właśnie tego dotyczyło moje pytanie. Bo zakładam, że systemy
> automatyki działają właśnie w oparciu o jakiś broker MQTT.
Tak. Ale to nie jest takie proste.
> I właśnie tego dotyczyło moje pytanie. Bo zakładam, że systemy
> automatyki działają właśnie w oparciu o jakiś broker MQTT.
Wyobraź sobie że wysyłasz na MQTT jakies "FOO" o wartości 1.
Możesz zmusić HomeAssistanta, aby zinterpretował to jako temperature,
wartość bool, jasność, czas.
Dzięki temu, że istnieją specjalne nadbudówki nad MQTT, możliwe jest
automatyczne poinformowanie HA że ma do czynienia z typem "temperatura"
a nie wartością liczbową.
Dlatego tak ciezko wyróżnić "protokół". Tak, można spłycić, że wszystko
lata po MQTT. Ale to nie do końca prawda - wiele danych tam latających
implemetuje informacje wyższego poziomu.
Taki na przykład przełącznik światła sonoff z zaprogramowaną Tasmotą,
zgłosi się w HA jako pstryczek z ikoną żarówki. Automatycznie.
> Pozostaje
> jednak jeszcze kwestia nazewnictwa tematów i przesyłanej zawartości.
Choc oczywiście możesz.
Mój pierwotny styl pracy bazował na ręcznym wyrzucaniu do MQTT jakiś
informacji i męczeniu się w HA aby je prawidłowo sklasyfikować.
Potem okazało się, że np. Tasmota ma autodiscovery, które HA rozumie.
Potem okazało się, że ESPHome robi to wszystko automatycznie.
Systemy automatyki to nie jest bare matal MQTT. Tam jest znacznie więcej
gotowych i bardzo wygodnych rozwiązań.
Przykładowo tutaj masz kod pstryczka do światła, bazującego na sonoff T1
(90% tego kodu napisał ESPHome), który automatycznie jest rejestrowany i
dostępny w HA jako pstryczek, żaróweczka i kilka statusów. Update tego
kodu, po wifi, mogę przeprowadzić w dowolnym momencie z poziomu
przegladarki w HA:
esphome:
name: wlacznik-swiatla-w-garderobie
esp8266:
board: esp01_1m
# Enable logging
logger:
# Enable Home Assistant API
api:
ota:
password: "39rj38ur390r9i093i09i3rr"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Wlacznik-Swiatla-W-Garderobie"
password: "xxxxxx"
captive_portal:
binary_sensor:
- platform: gpio
pin:
number: GPIO0
mode:
input: true
pullup: true
inverted: true
id: button_1
on_press:
then:
- light.toggle: light_1
- platform: status
name: "T1 Status"
output:
- platform: gpio
pin: GPIO12
id: relay_1
light:
- platform: binary
name: "Garderoba"
id: light_1
output: relay_1
status_led:
pin:
number: GPIO13
inverted: yes
Piotrek
Aug 18, 2022, 9:49:15 AM8/18/22
to
On 18.08.2022 15:40, Piotrek wrote:
> tam tych pluginów jest ponad 200, przy czym MQTT występuje właśnie jako
> binding - obok modbus, ZigBee, etc.
>
Pisałem z głowy, czyli z niczego - pluginów jest blisko 400, obsługuje
> tam tych pluginów jest ponad 200, przy czym MQTT występuje właśnie jako
> binding - obok modbus, ZigBee, etc.
>
prawie 3000 różnych gadżetów.
Piotrek
heby
Aug 18, 2022, 9:50:06 AM8/18/22
to
On 18/08/2022 15:49, Piotrek wrote:
>> tam tych pluginów jest ponad 200, przy czym MQTT występuje właśnie
>> jako binding - obok modbus, ZigBee, etc.
> Pisałem z głowy, czyli z niczego - pluginów jest blisko 400, obsługuje
> prawie 3000 różnych gadżetów.
HA ma też od groma automatyzacji.
>> tam tych pluginów jest ponad 200, przy czym MQTT występuje właśnie
>> jako binding - obok modbus, ZigBee, etc.
> Pisałem z głowy, czyli z niczego - pluginów jest blisko 400, obsługuje
> prawie 3000 różnych gadżetów.
Obecnie wybranie jakiegoś to chyba bardziej kwestia gustu.
LordBluzg®🇵🇱
Aug 18, 2022, 9:58:37 AM8/18/22
to
W dniu 18.08.2022 o 13:07, LordBluzg®🇵🇱 pisze:
>>> https://www.domoticz.com
>>
>> Ło matko jaka nazwa, myślałem że to jakiś lapsus językowy.
>>
> Raczej nie znasz języków :)
>
> https://translate.google.pl/?sl=es&tl=pl&text=domoticz&op=translate
>
Miało być bez "z" :]
https://translate.google.pl/?sl=es&tl=pl&text=domotic&op=translate
>>> https://www.domoticz.com
>>
>> Ło matko jaka nazwa, myślałem że to jakiś lapsus językowy.
>>
> Raczej nie znasz języków :)
>
> https://translate.google.pl/?sl=es&tl=pl&text=domoticz&op=translate
>
https://translate.google.pl/?sl=es&tl=pl&text=domotic&op=translate
Atlantis
Aug 18, 2022, 11:57:55 AM8/18/22
to
On 18.08.2022 15:47, heby wrote:
> Wyobraź sobie że wysyłasz na MQTT jakies "FOO" o wartości 1.
>
> Możesz zmusić HomeAssistanta, aby zinterpretował to jako temperature,
> wartość bool, jasność, czas.
Czyli rozumieć, że mogę Home Assistanta "nauczyć" obsługi własnego,
> Wyobraź sobie że wysyłasz na MQTT jakies "FOO" o wartości 1.
>
> Możesz zmusić HomeAssistanta, aby zinterpretował to jako temperature,
> wartość bool, jasność, czas.
niestandardowego protokołu?
> Dzięki temu, że istnieją specjalne nadbudówki nad MQTT, możliwe jest
> automatyczne poinformowanie HA że ma do czynienia z typem "temperatura"
> a nie wartością liczbową.
mógłbym napisać firmware do swoich modułów w ten sposób, żeby naśladował
któreś z dostępnych rozwiązań? Właśnie coś takiego miałem na myśli.
Generalnie na początku chciałbym zacząć od czegoś skromnego - systemu
zdalnego/automatycznego gaszenia świateł w warsztacie/budynku
gospodarczym (tam przerabianie instalacji elektrycznej będzie znacznie
mniej problematyczne). Jednocześnie chciałbym umieścić kilka czujników w
drzwiach czy sensorów temperatury/wilgotności/ciśnienia.
Jestem jednak uczulony na dostępne na rynku "prowizorki" w stylu
"inteligentnych żarówek z WiFi", które wymagają pozostawiania
zostawienia cały czas włączonego zasilania na włączniku w ścianie. Jeśli
już, to powinien być moduł z przekaźnikami półprzewodnikowymi, które
będą załączane po po otrzymaniu wiadomości siecią albo aktywowaniu wejścia.
Docelowo system może się potem rozrosnąć o kolejne elementy: sterowanie
bramą, stację pogodową, załączanie świateł w innych pomieszczeniach (to
już przy okazji jakiegoś remontu).
Swoją drogą, Home Assistanta można w miarę prosto zintegrować z
asystentem głosowym Google na Androidzie? :)
heby
Aug 18, 2022, 1:11:06 PM8/18/22
to
On 18/08/2022 17:57, Atlantis wrote:
>> Wyobraź sobie że wysyłasz na MQTT jakies "FOO" o wartości 1.
>> Możesz zmusić HomeAssistanta, aby zinterpretował to jako temperature,
>> wartość bool, jasność, czas.
> Czyli rozumieć, że mogę Home Assistanta "nauczyć" obsługi własnego,
> niestandardowego protokołu?
Tak. Na przykłąd zmusiłem go do sterowania centralą rekuperatora, po
>> Wyobraź sobie że wysyłasz na MQTT jakies "FOO" o wartości 1.
>> Możesz zmusić HomeAssistanta, aby zinterpretował to jako temperature,
>> wartość bool, jasność, czas.
> Czyli rozumieć, że mogę Home Assistanta "nauczyć" obsługi własnego,
> niestandardowego protokołu?
RS485/modbus (u mnie z konwerterem na wifi).
Ręcznie wyjasniłem HA jakie rejestry i gdzie są dostępne, jak je czytać,
jak interpretować, w jakich zakresach przyjmują dane, w pliku
konfiguracyjnym.
I w efekcie mam "suwak" którym steruje jego prędkość, dostępny z panelu
usera. Jak to działa pod maską jest bez znaczenia.
>> Dzięki temu, że istnieją specjalne nadbudówki nad MQTT, możliwe jest
>> automatyczne poinformowanie HA że ma do czynienia z typem
>> "temperatura" a nie wartością liczbową.
> Czyli rozumiem, że HA potrafi rozpoznać poszczególne urządzenia i
> mógłbym napisać firmware do swoich modułów w ten sposób, żeby naśladował
> któreś z dostępnych rozwiązań? Właśnie coś takiego miałem na myśli.
ESPHome.
> Generalnie na początku chciałbym zacząć od czegoś skromnego - systemu
> zdalnego/automatycznego gaszenia świateł w warsztacie/budynku
> gospodarczym (tam przerabianie instalacji elektrycznej będzie znacznie
> mniej problematyczne). Jednocześnie chciałbym umieścić kilka czujników w
> drzwiach czy sensorów temperatury/wilgotności/ciśnienia.
1) wyłacznika sonoff
2) ESPHome
3) ewentualnie Tasmota (trudniejsze)
> Jestem jednak uczulony na dostępne na rynku "prowizorki" w stylu
> "inteligentnych żarówek z WiFi", które wymagają pozostawiania
> zostawienia cały czas włączonego zasilania na włączniku w ścianie. Jeśli
> już, to powinien być moduł z przekaźnikami półprzewodnikowymi, które
> będą załączane po po otrzymaniu wiadomości siecią albo aktywowaniu wejścia.
Sonoff T1 + wymiana softu na ESPHome.
> Docelowo system może się potem rozrosnąć o kolejne elementy: sterowanie
> bramą, stację pogodową, załączanie świateł w innych pomieszczeniach (to
> już przy okazji jakiegoś remontu).
samodzielnie. Integruje się praktycznie ze wszytskim co jest sterowane w
domu, wliczając w to klimatyzatory, telewizory, roomby itd itp.
> Swoją drogą, Home Assistanta można w miarę prosto zintegrować z
> asystentem głosowym Google na Androidzie? :)
Albo za darmo - wtedy to trochę roboty. Albo płatnie - wtedy to ~1
kliknięcie.
Jedna uwaga:
HA jako HA nie nadaje się do pracy. To tylko szkielet.
To czego szukasz, to HassIO. To cały system operacyjny zawierający HA,
gotowy do pracy, automatycznie updateowany, skonfigurowany, ze
wszsytkimi integracjami dostępnymi z repozytorium.
U mnie bangla na wirtualizowanym kompie (proxmox), ale wczesniej pomykał
sobie na Pi3 i też było dobrze.
Atlantis
Aug 18, 2022, 3:14:16 PM8/18/22
to
On 18.08.2022 19:10, heby wrote:
> Wymarzona robota dla:
> 1) wyłacznika sonoff
> 2) ESPHome
> 3) ewentualnie Tasmota (trudniejsze)
Generalnie wolę unikać stosowania WiFi tam, gdzie mogę nie stosować
> Wymarzona robota dla:
> 1) wyłacznika sonoff
> 2) ESPHome
> 3) ewentualnie Tasmota (trudniejsze)
WiFi. A szczególnie razi mnie marnowanie modułu WiFi, zasobów radiowych
i adresu IP na coś, co będzie pojedynczym włącznikiem. Tym bardziej, że
i tak trzeba będzie do tego podciągnąć zasilanie kablem.
Dlatego jakiś czas temu zacząłem projektować swoje własne moduły na
PIC32MX270F256, wyposażone w interfejs Ethernet, która mają
współpracować z czujnikami i układami wykonawczymi na magistrali I2C.
Cała elektronika zamknięta w hermetycznej obudowie, w której zbiegają
się kable biegnące od włączników i do źródeł światła.
Podobny moduł (z nieco innymi elementami wykonawczymi) może posłużyć do
skomunikowania się ze sterownikiem bramy albo stworzenia stacji
pogodowej. Nie wykluczam możliwości, że w pewnym momencie zastosuję też
inne magistrale (w tym bezprzewodowe) ale na razie, w miarę możliwości
będę chciał opierać się na Ethernecie tam, gdzie będzie się go dało bez
większego problemu podciągnąć.
heby
Aug 18, 2022, 5:02:12 PM8/18/22
to
On 18/08/2022 21:14, Atlantis wrote:
> Generalnie wolę unikać stosowania WiFi tam, gdzie mogę nie stosować
> WiFi.
W przypadku wyłącznika światła dużo rozwiązań innych nie ma, poza samoróbką.
> Generalnie wolę unikać stosowania WiFi tam, gdzie mogę nie stosować
> WiFi.
> A szczególnie razi mnie marnowanie modułu WiFi, zasobów radiowych
> i adresu IP na coś, co będzie pojedynczym włącznikiem.
problem z "marnowaniem"?
Zasoby radiowe? Te urządzenia komunikują się sporadycznie. Nie obciązają
sieci wifi w stopniu jakimkolwiek.
> Tym bardziej, że
> i tak trzeba będzie do tego podciągnąć zasilanie kablem.
specjalnie w każdej puszce oświetleniowej. Któraś wersja sonoff działa z
pasozytniczym zasilaniem, ale powoduje to lekkie problemy z niektórymi
typami oświetlenia.
Opcja desperacka: można zanabyć maulteńki sonoff mini, schowany w
żyrandolu a w gniazdko wsadzić sonoff T1 i zmajstrować sterowanie
jednego drugim w HA.
> Dlatego jakiś czas temu zacząłem projektować swoje własne moduły na
> PIC32MX270F256, wyposażone w interfejs Ethernet, która mają
> współpracować z czujnikami i układami wykonawczymi na magistrali I2C.
Jeśli chcesz, są moduły na 433MHz, ale to jest absolutnie dno jeśli
chodzi o możliwości.
> Cała elektronika zamknięta w hermetycznej obudowie, w której zbiegają
> się kable biegnące od włączników i do źródeł światła.
Topologia "gdziebądź".
> Podobny moduł (z nieco innymi elementami wykonawczymi) może posłużyć do
> skomunikowania się ze sterownikiem bramy albo stworzenia stacji
> pogodowej.
A wyłączniki na Wifi. Po co lepsze? Wifi się popsuje - wyłacznik dalej
działa jak wyłacznik.
> Nie wykluczam możliwości, że w pewnym momencie zastosuję też
> inne magistrale (w tym bezprzewodowe) ale na razie, w miarę możliwości
> będę chciał opierać się na Ethernecie tam, gdzie będzie się go dało bez
> większego problemu podciągnąć.
bezproblemowo, tanio, wygodnie. Może nie warto ciągnąc ethernetu.
Krytycznej automatyki na wifi nie pociągnę, ale głupi wyłacznik światła
w ścianie jest niekrytyczny.
Na marginesie: sonoff z ESPHome pracuje u mnie w ścianie już ~3 lata bez
awarii. Dostępny cały czas w HA. Nic nei znika, rozpina się, głupieje.
Stabilne jak skała. Drugi, z Tasmotą, zaliczył jedną wpadkę - nie wstał
po mignięciu zasilania (ale dalej działał jako zwykły wyłacznik). Działa
też koło 3 lat.
Jesli strasznie się boisz wifi, to są Zigbee i Z-Wave. Mam z nimi o
wiele więcej problemów niż z wifi.
LordBluzg®🇵🇱
Aug 18, 2022, 5:20:38 PM8/18/22
to
W dniu 18.08.2022 o 17:57, Atlantis pisze:
Tak nawiasem, akurat ja, używam rozwiązań Supla (heby nie lubi).
Jak dla mnie znacznie bardziej korzystne i co najważniejsze to ciągle
się to rozwija. Można mieć wszystko u siebie albo korzystać z chmury
obcej. Dodatkowo są skrypty i wszelakie wariacje na ten temat, gdzie
można bez problemu robić sobie sceny, zależności, cokolwiek, sonoffy,
wemosy, arduino, maliny, można tym karmić. Jak dla mnie, idealne
rozwiązanie na automatykę domową. Mam na tym cały alarm na działce,
stację pogodową (całe stada czujników wszelakich) i co najważniejsze, to
powiadomienia/eventy...cokolwiek
Jak dla mnie znacznie bardziej korzystne i co najważniejsze to ciągle
się to rozwija. Można mieć wszystko u siebie albo korzystać z chmury
obcej. Dodatkowo są skrypty i wszelakie wariacje na ten temat, gdzie
można bez problemu robić sobie sceny, zależności, cokolwiek, sonoffy,
wemosy, arduino, maliny, można tym karmić. Jak dla mnie, idealne
rozwiązanie na automatykę domową. Mam na tym cały alarm na działce,
stację pogodową (całe stada czujników wszelakich) i co najważniejsze, to
powiadomienia/eventy...cokolwiek
Marek
Aug 19, 2022, 12:39:54 PM8/19/22
to
On Thu, 18 Aug 2022 13:07:08 +0200,
LordBluzg®🇵🇱<mka...@poczta.onet.pl> wrote:
> Raczej nie znasz języków :)
Nie muszę znać języków, żeby stwierdzić że coś po polsku brzmi głupio.
LordBluzg®🇵🇱<mka...@poczta.onet.pl> wrote:
> Raczej nie znasz języków :)
--
Marek
Marek
Aug 19, 2022, 12:46:40 PM8/19/22
to
On Thu, 18 Aug 2022 23:02:00 +0200, heby <he...@poczta.onet.pl> wrote:
> Krytycznej automatyki na wifi nie pociągnę, ale głupi wyłacznik
> światła
> w ścianie jest niekrytyczny.
Jaka rezponsywność? Przełączając przycisk osoba wyczuje, że to nie
> Krytycznej automatyki na wifi nie pociągnę, ale głupi wyłacznik
> światła
> w ścianie jest niekrytyczny.
jest klasyczny wyłącznik? Co z problemami na switchu, AP?
--
Marek
heby
Aug 19, 2022, 1:31:59 PM8/19/22
to
On 19/08/2022 18:46, Marek wrote:
> 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
> Jaka rezponsywność? Przełączając przycisk osoba wyczuje, że to nie jest
> klasyczny wyłącznik? Co z problemami na switchu, AP?
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.
Marek
Aug 19, 2022, 1:40:20 PM8/19/22
to
On Fri, 19 Aug 2022 19:31:48 +0200, heby <he...@poczta.onet.pl> wrote:
> Natychmiastowa. Jestem uczolony na responsywność, dlatego to dla
> mnie
> krytyczne.
A druga część pytania?
> Natychmiastowa. Jestem uczolony na responsywność, dlatego to dla
> mnie
> krytyczne.
--
Marek
heby
Aug 19, 2022, 1:53:03 PM8/19/22
to
On 19/08/2022 19:40, Marek wrote:
>> Natychmiastowa. Jestem uczolony na responsywność, dlatego to dla mnie
>> krytyczne.
> A druga część pytania?
Problemy na switchu i AP są problemami na switchu i AP. Kupisz lepsze,
>> Natychmiastowa. Jestem uczolony na responsywność, dlatego to dla mnie
>> krytyczne.
> A druga część pytania?
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.
Marek
Aug 19, 2022, 2:20:02 PM8/19/22
to
On Fri, 19 Aug 2022 19:52:52 +0200, heby <he...@poczta.onet.pl> wrote:
> Problemy na switchu i AP są problemami na switchu i AP. Kupisz
> lepsze,
> problem nie istnieje.
No ale dla usera jest to nadal problem wyłącznika bo nie działa, co
> Problemy na switchu i AP są problemami na switchu i AP. Kupisz
> lepsze,
> problem nie istnieje.
się po drodze zepsuło to kwestia wtórna.
> Niedaleko mnie jest dom, gdzie automatykę zrobiono "profesjonalnie"
(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.
--
Marek
heby
Aug 19, 2022, 2:35:33 PM8/19/22
to
On 19/08/2022 20:19, Marek wrote:
>> Problemy na switchu i AP są problemami na switchu i AP. Kupisz lepsze,
>> problem nie istnieje.
> No ale dla usera jest to nadal problem wyłącznika bo nie działa, co się
> po drodze zepsuło to kwestia wtórna.
Wyłącznik działa. Nie działa zdalne sterowanie tym wyłącznikiem z aplikacji.
>> Problemy na switchu i AP są problemami na switchu i AP. Kupisz lepsze,
>> problem nie istnieje.
> No ale dla usera jest to nadal problem wyłącznika bo nie działa, co się
> po drodze zepsuło to kwestia wtórna.
W wyniku awari dostajesz normalny dom, nieinteligentny, ale i niepopsuty.
>> Niedaleko mnie jest dom, gdzie automatykę zrobiono "profesjonalnie"
> Na czym?
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.
> Ogólnie to bardzo mnie
> ciekawi jak rozwiązania profesjonalne się sprawdzają w porównaniu do
> tych otwartych.
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.
Marek
Aug 19, 2022, 2:56:24 PM8/19/22
to
On Fri, 19 Aug 2022 20:35:22 +0200, heby <he...@poczta.onet.pl> wrote:
> Wyłącznik działa. Nie działa zdalne sterowanie tym wyłącznikiem z
> aplikacji.
No *nie* działa. Jesteś już w drodze 300km od domu i sobie
> Wyłącznik działa. Nie działa zdalne sterowanie tym wyłącznikiem z
> aplikacji.
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.
> W wyniku awari dostajesz normalny dom, nieinteligentny, ale i
> niepopsuty.
> Przedstawiłem mu, co ja potrzebuje.
> Więcej jak połowa niewykonalna.
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.
> jak wejdziesz do łazienki itp "profesjonalne" zastosowania. A ja
> chce
> czytać falwonik PV po RS485 i sterować adekwatnie pompą grzania
> basenu.
--
Marek
heby
Aug 19, 2022, 3:12:46 PM8/19/22
to
On 19/08/2022 20:55, Marek wrote:
>> Wyłącznik działa. Nie działa zdalne sterowanie tym wyłącznikiem z
>> aplikacji.
> No *nie* działa. Jesteś już w drodze 300km od domu i sobie
> przypomniałeś, że w pokoju zostawiłeś włączone światło.
Ok. Nie działa. Jak często? Jedyny problem, to kiepski AP. Stabilnośc
>> Wyłącznik działa. Nie działa zdalne sterowanie tym wyłącznikiem z
>> aplikacji.
> No *nie* działa. Jesteś już w drodze 300km od domu i sobie
> przypomniałeś, że w pokoju zostawiłeś włączone światło.
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 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.
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...
>> Przedstawiłem mu, co ja potrzebuje.
>> Więcej jak połowa niewykonalna.
> No ale czy trochę nie przesadzasz z potrzebami?
potrzeby niewykonalne, jedynie wymagajace większego wysiłku do ich
zaspokojenia.
Przesadzałbym, gdyby takie rozwiązanie nie istniało.
>> jak wejdziesz do łazienki itp "profesjonalne" zastosowania. A ja chce
>> czytać falwonik PV po RS485 i sterować adekwatnie pompą grzania basenu.
> Margines potrzeb.
Ale co najbardziej śmieszne: HA ma możliwośc sterowania niektórymi z nich.
Czy w tym momencie staja się nieprofesjonalne?
Mirek
Aug 19, 2022, 3:29:53 PM8/19/22
to
On 19.08.2022 21:12, heby wrote:
> 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 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?
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.
--
Mirek.
Mirek
Aug 19, 2022, 3:39:36 PM8/19/22
to
klientowi na nic czego sami nie uznamy za potrzebne.
BTW - po co po 485 jak każdy falownik ma wifi?
--
Mirek.
heby
Aug 19, 2022, 3:48:14 PM8/19/22
to
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
> BTW - po co po 485 jak każdy falownik ma wifi?
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.
Mirek
Aug 19, 2022, 4:09:28 PM8/19/22
to
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 -
> a) nie udało mi się po wifi wyjąć tego, co wyjmuje po RS485.
klientowi to wystarcza, ale faktycznie wiele więcej tam nie ma.
--
Mirek.
Piotr Gałka
Aug 22, 2022, 8:08:28 AM8/22/22
to
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.
> Natychmiastowa. Jestem uczolony na responsywność, dlatego to dla mnie
> krytyczne.
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.
J.F
Aug 22, 2022, 8:32:49 AM8/22/22
to
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.
> 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.
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.
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.
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.
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.
RoMan Mandziejewicz
Aug 22, 2022, 9:34:25 AM8/22/22
to
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!)
Monday, August 22, 2022, 2:08:26 PM, you wrote:
[...]
> Do tej pory sądziłem, że nie ma głupich norm.
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!)
Piotr Gałka
Aug 22, 2022, 2:21:58 PM8/22/22
to
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.
> Co zaraz powoduje problemy pod tytulem kolizje.
> Wykrywacie?
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 ...
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 :-(
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".
ż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 :-)
Standardu Wiegand też nikt nie przenosi na ethernet :)
P.G.
Mirek
Aug 22, 2022, 4:24:29 PM8/22/22
to
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?
> 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.
Od czytnika do kontrolera czy od kontrolerów do jakiejś centralki?
--
Mirek.
Piotr Gałka
Aug 23, 2022, 4:53:43 AM8/23/22
to
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.
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.
J.F
Aug 23, 2022, 7:36:08 AM8/23/22
to
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
> 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.
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.
> 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.
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.
>> 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.
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ł).
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 :)
znalazlo :-)
J.
Piotr Gałka
Aug 23, 2022, 11:21:37 AM8/23/22
to
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.
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ą ? :-)
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 :-)
>> 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.
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.
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.
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 :-)
>>> 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.
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 :-)
Musisz łopatologicznie bo Ethernet to dla mnie czarna magia.
P.G.
J.F
Aug 23, 2022, 11:56:13 AM8/23/22
to
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
> 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.
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.
>> 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).
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.
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.
Mateusz Viste
Aug 23, 2022, 2:32:08 PM8/23/22
to
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
> 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.
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
Mateusz Bogusz
Aug 23, 2022, 2:42:23 PM8/23/22
to
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
> 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.
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.
i użyłeś takiego skrótu myślowego?
--
Pozdrawiam,
Mateusz Bogusz
Piotr Gałka
Aug 23, 2022, 2:42:45 PM8/23/22
to
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.
> Jak masz 50 urzadzen na szynie .... ciekawe, czy mogą tak dociązyc
> kontroler/serwer, ze nie nadązy odpowiadac :-)
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 ...
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 :-)
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.
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 ...
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.
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.
Mateusz Viste
Aug 23, 2022, 2:57:34 PM8/23/22
to
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
> > 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.
"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
heby
Aug 23, 2022, 3:05:44 PM8/23/22
to
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
>> 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?
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.
Mateusz Bogusz
Aug 24, 2022, 1:11:03 AM8/24/22
to
powiadomienie "Dzisiaj się kąpiesz"? :-D
--
Pozdrawiam,
Mateusz Bogusz
heby
Aug 24, 2022, 4:46:11 AM8/24/22
to
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"
>> 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
kończy się kąpielą.
W razie czego jest switch "dzisiaj nie grzej".
Piotr Gałka
Aug 24, 2022, 12:56:59 PM8/24/22
to
W dniu 2022-08-23 o 20:57, Mateusz Viste pisze:
> 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.
A o tym też zupełnie zapomniałem. Ja wtedy nie rozróżniałem co to hub,
switch, router, bridge...
A i teraz wiem tylko z grubsza. :)
P.G.
> 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.
switch, router, bridge...
A i teraz wiem tylko z grubsza. :)
P.G.
Mateusz Bogusz
Aug 24, 2022, 2:33:40 PM8/24/22
to
On 24.08.2022 10:45, heby wrote:
> Czytam PV, analizuję pogodę i na podstawie tego, algorytmicznie,
To faktycznie może wymagać kawałka customowego kodu którego się "nie
> Czytam PV, analizuję pogodę i na podstawie tego, algorytmicznie,
wyklika", ale
> steruje czy właczyć PC i pompę wymiennika ciepła z basenem.
bezpotencjałowe wejścia dla: pozwól działać pompie, pozwól na grzanie,
pozwól na chłodzenie. Mogę też wszystko inne po prostu ustawić przez
POST z odpowiednim jsonem na adres PC - ale ok, to już była opcja a nie
standard ;-)
--
Pozdrawiam,
Mateusz Bogusz
LordBluzg®🇵🇱
Aug 24, 2022, 2:39:54 PM8/24/22
to
W dniu 24.08.2022 o 18:56, Piotr Gałka pisze:
> A o tym też zupełnie zapomniałem. Ja wtedy nie rozróżniałem co to hub,
> switch, router, bridge...
Megaproste :)
hub-centralka
switch-przełącznik
router-trasownik
bridge-mostek
Używanie angielskich nazw generalnie wielu z niczym się nie kojarzy i
często zapominają znaczeń/roli/.
--
LordBluzg®🇵🇱
<<<ƧiԳ ćɒdɘႱ i Putina i ęjcaredefnoK>>>
> A o tym też zupełnie zapomniałem. Ja wtedy nie rozróżniałem co to hub,
> switch, router, bridge...
hub-centralka
switch-przełącznik
router-trasownik
bridge-mostek
Używanie angielskich nazw generalnie wielu z niczym się nie kojarzy i
często zapominają znaczeń/roli/.
--
LordBluzg®🇵🇱
<<<ƧiԳ ćɒdɘႱ i Putina i ęjcaredefnoK>>>
heby
Aug 24, 2022, 2:44:42 PM8/24/22
to
On 24/08/2022 20:33, Mateusz Bogusz wrote:
>> steruje czy właczyć PC i pompę wymiennika ciepła z basenem.
> Już można obsłużyć za pomocą np. sonoffa.
Obsługuje za pomocą sonoffa banglającego na ESPhome ;)
>> steruje czy właczyć PC i pompę wymiennika ciepła z basenem.
> Już można obsłużyć za pomocą np. sonoffa.
> W swojej PC mam
> bezpotencjałowe wejścia dla: pozwól działać pompie, pozwól na grzanie,
> pozwól na chłodzenie. Mogę też wszystko inne po prostu ustawić przez
> POST z odpowiednim jsonem na adres PC - ale ok, to już była opcja a nie
> standard ;-)
automatyzacjami tego typu, staram się zachować bardziej stan
"monitoring" niż "automatyzacja" ale ta jedna jest niekrytyczna, więc
czemu nie.
Marek
Aug 27, 2022, 5:27:15 AM8/27/22
to
On Fri, 19 Aug 2022 20:35:22 +0200, heby <he...@poczta.onet.pl> wrote:
> Mieli tam wypasioną automatykę, że wentylator się właczy
> jak wejdziesz do łazienki itp "profesjonalne" zastosowania.
BTW, czy już wymyślono jakieś skuteczne rozwiązanie na wykrywanie
> jak wejdziesz do łazienki itp "profesjonalne" zastosowania.
człowieka w pomieszczeniu bez względu na to czy się rusza czy nie?
Proste zastosowanie: zapal światło gdy człowiek jest w pomieszceniu
(żywy lub martwy), zgaś światło gdy opuści pomieszczenie (i własnych
siłach lub nogami do przodu). Może źle szukam ale okazuje się, że
taka prosta funkcjonalność w 21 wieku jest praktycznie ciągle
niedostępna...
--
Marek
Mateusz Bogusz
Aug 27, 2022, 6:43:11 AM8/27/22
to
On 27.08.2022 11:27, Marek wrote:
> BTW, czy już wymyślono jakieś skuteczne rozwiązanie na wykrywanie
> człowieka w pomieszczeniu bez względu na to czy się rusza czy nie?
> Proste zastosowanie: zapal światło gdy człowiek jest w pomieszceniu
> (żywy lub martwy), zgaś światło gdy opuści pomieszczenie (i własnych
> siłach lub nogami do przodu). Może źle szukam ale okazuje się, że taka
> prosta funkcjonalność w 21 wieku jest praktycznie ciągle niedostępna...
Jak nie jest jak jest np. termowizja, kamera z IVS,...tylko pewnie
> BTW, czy już wymyślono jakieś skuteczne rozwiązanie na wykrywanie
> człowieka w pomieszczeniu bez względu na to czy się rusza czy nie?
> Proste zastosowanie: zapal światło gdy człowiek jest w pomieszceniu
> (żywy lub martwy), zgaś światło gdy opuści pomieszczenie (i własnych
> siłach lub nogami do przodu). Może źle szukam ale okazuje się, że taka
> prosta funkcjonalność w 21 wieku jest praktycznie ciągle niedostępna...
szukasz "do 50zł".
A jak chcesz z tanich komponentów to jeden nie wystarczy aby spełnić
Twoje wymagania tylko trzeba je łączyć i pisać "logikę grupową".
--
Pozdrawiam,
Mateusz Bogusz
Marek
Aug 27, 2022, 10:52:16 AM8/27/22
to
On Sat, 27 Aug 2022 12:43:09 +0200, Mateusz Bogusz <mab...@o2.pl>
wrote:
Kamera wymaga odpowiedniego kąta patrzenia, nie nadaje się do każdego
pomieszczenia.
Ja wiem, że z podchodząc tak akademicko to teoretycznie da się, ja
pytam o gotowe praktyczne moduły spełniające te funkcje. Mogą być
hybrydowe. Rzeźbienie w opencv też na razie bym chciał uniknąć.
--
Marek
wrote:
> Jak nie jest jak jest np. termowizja, kamera z IVS,...tylko pewnie
> szukasz "do 50zł".
Nie szukam do 50zl. Termowizja się nie sprawdza w każdym przypadku.
> szukasz "do 50zł".
Kamera wymaga odpowiedniego kąta patrzenia, nie nadaje się do każdego
pomieszczenia.
Ja wiem, że z podchodząc tak akademicko to teoretycznie da się, ja
pytam o gotowe praktyczne moduły spełniające te funkcje. Mogą być
hybrydowe. Rzeźbienie w opencv też na razie bym chciał uniknąć.
--
Marek
heby
Aug 27, 2022, 12:41:37 PM8/27/22
to
On 27/08/2022 11:27, Marek wrote:
> BTW, czy już wymyślono jakieś skuteczne rozwiązanie na wykrywanie
> człowieka w pomieszczeniu bez względu na to czy się rusza czy nie?
https://novelda.com/
> BTW, czy już wymyślono jakieś skuteczne rozwiązanie na wykrywanie
> człowieka w pomieszczeniu bez względu na to czy się rusza czy nie?
Gdzieś mieli filmik z którego wynikało, że ogarniają przeciętny pokój.
Cen nie znam. Zapewne drogo.
Mirek
Aug 27, 2022, 1:55:03 PM8/27/22
to
On 27.08.2022 11:27, Marek wrote:
> Proste zastosowanie: zapal światło gdy człowiek jest w pomieszceniu
> (żywy lub martwy), zgaś światło gdy opuści pomieszczenie
Jeśli chodzi o kibelek, to wystarczy czujka plus kontaktron. Jeśli do
> (żywy lub martwy), zgaś światło gdy opuści pomieszczenie
pomieszczenia wchodzi więcej niż jedna osoba, to sprawa się komplikuje.
Są kamery liczące osoby - montuje się je z góry nad drzwiami - służą
właśnie do tego, żeby było wiadomo ile osób jest w danej chwili w
pomieszczeniu. Oczywiście kilka wejść nie stanowi problemu.
--
Mirek.
Marek
Aug 27, 2022, 4:44:21 PM8/27/22
to
On Sat, 27 Aug 2022 18:41:22 +0200, heby <he...@poczta.onet.pl> wrote:
> Cen nie znam. Zapewne drogo.
$80/1000szt za gotowy moduł. Tragedii nie ma, a na filmach dość
> Cen nie znam. Zapewne drogo.
obiecująco to wygląda...
--
Marek
Mateusz Bogusz
Aug 29, 2022, 1:47:22 AM8/29/22
to
On 27.08.2022 19:55, Mirek wrote:
> Są kamery liczące osoby - montuje się je z góry nad drzwiami - służą
> właśnie do tego, żeby było wiadomo ile osób jest w danej chwili w
> pomieszczeniu. Oczywiście kilka wejść nie stanowi problemu.
Jeżeli łazienka jest mała, to równocześnie w kadrze może być więcej niż
> Są kamery liczące osoby - montuje się je z góry nad drzwiami - służą
> właśnie do tego, żeby było wiadomo ile osób jest w danej chwili w
> pomieszczeniu. Oczywiście kilka wejść nie stanowi problemu.
jedna osoba.
Dodatkowo ja mam np. łazienkę z dwoma otworami drzwiowymi.
--
Pozdrawiam,
Mateusz Bogusz
JDX
Sep 10, 2022, 1:53:14 AM9/10/22
to
On 19.08.2022 21:39, Mirek wrote:
[...]
> BTW - po co po 485 jak każdy falownik ma wifi?
>
Wifi może słabo działać przez dwa zbrojone stropy i ścianę (jak np. u
mnie). Poza tym nie jest odporne na dowcipnisi z jammerami wifi (za
moich szczenięcych czasów robiło się zakłócacze sygnału TV :-) ). Poza
tym IMO bezmyślne parcie na wifi może być szkodliwe – vide kamery
monitoringu gadające po wifi – znane są przypadki gdy złodzieje
zakłócili kamery i spokojnie okradli monitorowane miejsce.
[...]
> BTW - po co po 485 jak każdy falownik ma wifi?
>
Wifi może słabo działać przez dwa zbrojone stropy i ścianę (jak np. u
mnie). Poza tym nie jest odporne na dowcipnisi z jammerami wifi (za
moich szczenięcych czasów robiło się zakłócacze sygnału TV :-) ). Poza
tym IMO bezmyślne parcie na wifi może być szkodliwe – vide kamery
monitoringu gadające po wifi – znane są przypadki gdy złodzieje
zakłócili kamery i spokojnie okradli monitorowane miejsce.
Marek
Sep 10, 2022, 5:22:59 AM9/10/22
to
On Sat, 10 Sep 2022 07:53:11 +0200, JDX <j...@onet.pl> wrote:
> mnie). Poza tym nie jest odporne na dowcipnisi z jammerami wifi (za
> moich szczenięcych czasów robiło się zakłócacze sygnału TV :-) ).
Na wsi? Czy mówimy zakłócaniu fotowoltaiki w bloku?
> mnie). Poza tym nie jest odporne na dowcipnisi z jammerami wifi (za
> moich szczenięcych czasów robiło się zakłócacze sygnału TV :-) ).
--
Marek
Mirek
Sep 10, 2022, 7:14:05 AM9/10/22
to
miedź i 485, ale do cholery z optoizolacją!
Z tydzień temu miałem zlecenie: padło sterowanie bramkami wejściowymi do
pewnego obiektu.
Diagnoza: upalone dwa porty USB w komputerze, konwerter USB/485, tablica
informacyjna.
W sumie banał, ale obiekt stoi i nie zarabia.
Przyczyna (hipoteza): gdzieś na ciągu komunikacyjnym wieszano coś na
ścianie i przewiercono przewody zasilające (fakt), z tego obwodu
zasilana była tablica informacyjna, nastąpiło zwarcie PE z L, dalej już
można się domyślić. Mogło być gorzej. Mogło popalić wszystko łącznie z
ssd z danymi w komputerze.
--
Mirek.
alojzy nieborak
Sep 10, 2022, 8:02:01 AM9/10/22
to
Marek napisał(a):
Są reż bida kamery IR robione przez kitajców
oparte o matryce IR. Rozdzielczość jakaś śmieszna,
? 16x16, 32x32 czy 64x64 pix.
> rusza czy nie?
Jak to nie rusza się?
Śpi, medytuje albo nie żyje. Więc światło mu średnio potrzebne.
> BTW, czy już wymyślono jakieś skuteczne rozwiązanie na wykrywanie
> człowieka w pomieszczeniu bez względu na to czy się rusza czy nie?
Jednopikselowy PIR lub/i czujnik mikrofalowy z ali.
> człowieka w pomieszczeniu bez względu na to czy się rusza czy nie?
Są reż bida kamery IR robione przez kitajców
oparte o matryce IR. Rozdzielczość jakaś śmieszna,
? 16x16, 32x32 czy 64x64 pix.
> rusza czy nie?
Jak to nie rusza się?
Śpi, medytuje albo nie żyje. Więc światło mu średnio potrzebne.
Marek
Sep 11, 2022, 3:26:16 PM9/11/22
to
On Sat, 10 Sep 2022 05:02:00 -0700 (PDT), alojzy nieborak
<alojzy....@gmail.com> wrote:
> Jednopikselowy PIR lub/i czujnik mikrofalowy z ali.
> Są reż bida kamery IR robione przez kitajców
> oparte o matryce IR. Rozdzielczość jakaś śmieszna,
To są zabawki wykrywające ruch a ja pytałem o wykrywanie obecności.
<alojzy....@gmail.com> wrote:
> Jednopikselowy PIR lub/i czujnik mikrofalowy z ali.
> Są reż bida kamery IR robione przez kitajców
> oparte o matryce IR. Rozdzielczość jakaś śmieszna,
Wystarczy przestać się ruszać i gasi światło. A to ma wykrywać
*obecność* a nie ruch.
Heby podał dość obiecujące rozwiązanie.
--
Marek
0 new messages