Integracja centrali z automatyką budynkową

Zaczęty przez irekp, Marzec 22, 2012, 14:49:53

Poprzedni wątek - Następny wątek

irekp

Witam,
planuję połączyć centralę z automatyką budynkową opartą na PLC. Na początek odczyt stanu wejść, sterowanie wyjściami, czuwaniem. Chciałbym aby połączenie było przewodowe.
W sterowniku mam dostępne m.in. RS232 i ethernet (prot. TCP/IP i inne).
1. RS232: wydaje się, że można by się włączyc w magistralę systemową 485 - czy udostępniacie protokół komunikacyjny (konkurencja nie ma w tym zakresie tajemnic).
2. Ethernet: czy planujecie wyposażyć centralę w złącze i/lub kartę Ethernet
3. Inne: a może można inaczej?

RobertH

#1
Witam

Do systemu NEO nie przewidujemy bramek itp. do integracji z innymi systemami.
Będzie dostępne inne rozwiązanie w nowym systemie VISUM i VISUM GSM.

Informacje na PW

irekp

Witam,
dziękuję za odpowiedź,
Kierunek na komunikację IP, webserwer uważam za słuszny.
Co do BACnet\'u - na pewno przeanalizowaliście wszystkie za i przeciw. Dla mnie BACnet jest drogi, mało w Polsce popularny. Moim skromnym zdaniem, jeżeli iść w kierunku BMS\'a i magistrali komunikacyjnej \"budynkowej\" lepszy byłby KNX lub LON.

Co do meritum: wydaje mi się, że z centralą NEO możnaby \'\'pogadać\' bez \"bramek itp.\" po magistrali systemowej, gdyby był dostępny protokół. Rozumiem, że protokołu nie udostępniacie?

SATEL swój protokół publikuje na oficjalnych stronach i znam przynajmniej kilka osób, które tylko dlatego wybrały centralę SATEL w swoich zastosowaniach.
Ja w chwili obecnej stoję przed wyborem centrali. Zaczątek BMS\'a już mam, centralę wybieram i możliwość porozumienia się z nią jest istotnym kryterium.

Pozdrawiam
Ieneusz Puchała

RobertH

Witam

Wybór standardowego protokołu do komunikacji i integracji nie ma tylko na celu \'otwarcie\' systemu ale zasadniczo ma stworzyć założenia systemu, który może być rozwijany przez lata bez tzw. \'grubych kresek\' czyli zmiany logiki i funkcjonalności po każdej walidacji potrzeb dla \'nowej\' wersji.
Zgodzę się z Panem, że LON lub KNX ma lepszą integralność na poziomie warstwy komunikacji budynkowe ale mają podstawowe wady:
- są protokołami płatnymi,
- operują na określonej warstwie fizycznej, wymagają konkretnego rozwiązania sprzętowe.

BacNet zapewnia:
- sprawdzone mechanizmy komunikacji i obsługi zdarzeń,
- różne warstwy fizyczne np. EIA-485, ETHERNET obecnie już trwają prace nad BacNet KNX virtual layer tj. KNX będzie kolejną warstwą fizyczną dla KNX (i jest uruchomiona standaryzacja KNX-> BacNet),
- przewiduje większość funkcji i algorytmów wymaganych dla SSWiN, KD, CCTV itd.
- jest bezpłatny i można implementować na dowolne platformy,
- system rozproszony z podziałem na bloki funkcyjne nawet w ramach tylko naszych urządzeń.

BacNet może na razie jest mało popularny ale liczba \'vendorów\' rośnie wykładniczo i już obecnie jest ich 500 (a np. KNX 150). Nie przewiduje aby urządzenia z BMS BacNet  miały duże zastosowanie w typowych aplikacjach automatyki domowych z kilku powodów: cena , narzędzia konfiguracyjne, wiedza integratora.  Jednakże taka możliwość będzie i dodatkowo można zastosować typowe bramki do integracji miedzy systemami: BacNet-KNX itd.

Reasumując: VISUM i VISUM GSM powinien zapewnić dużo funkcji dla automatyki domowej.  Rozbudowa i skalowalność  zasobów będzie opierała się o protokół BacNet (w ramach naszego systemu nie będzie potrzebna wiedza o tym protokole i inne narzędzia konfiguracyjne)  . W typowych aplikacjach najwięcej funkcjonalności wniesie komunikacja IP i sterowania z poziomu smartfonów, PC. Docelowo powstanie także API do integracji w ramach TCP/IP i Android.

W przypadku pytań służę pomocą.

irekp

Witam,

trochę zboczyliśmy z tematu wątku choć o wadach i zaletach róznych standardów możnaby długo dyskutować.
Dziękuję za informacje o planach.
U mnie jest tak, że sterownik już mam (sprawdzałem - ten sam sterownik z BACnet\'em kosztowałby 2x drożej),
stoję przed zakupem centrali, którą tenże sterownik ma \"rządzić\". I na dzień dzisiejszy raczej nie będzie to NEO (na dekodowanie protokołu nie mam czasu).

Pozdrawiam,
Ireneusz Puchała

RobertH

Witam

NEO jest małą centralą i nie było nigdy projektowane do integracji.
Kkomunikacja po EIA 485 jest oczywiście ale ponieważ nie była przewidziana opcja API zawiera kilka sztuczek.
Nie przekaże Panu danych, które nigdy nie były weryfikowane z producentami trzecimi.
Na tym etapie nie pomogę Panu

ps. pomijając już aspekt integracji w VISUM funkcje  PLC (LogicProcessor)  są obecnie konieczne w kontrolerach obiektowych, centralach. VISUM ma za zadanie dać określone zasoby: centrala + sterownik PLC (nawet interpretator skryptu).

irekp

Witam,

1. \"NEO jest małą centralą \" - tak, takiej właśnie szukam.
2. \"funkcje PLC (LogicProcessor) są obecnie konieczne w kontrolerach obiektowych\" - tak, u mnie kontrolerem obiektowym jest/będzie sterownik Wago, który ma m.in komunikację IP, ma serwer WWW na pokładzie, jest programowany graficzne zgodnie z IEC 61131-3 (IL, LD, ST, FBD, SFC, CFC ), do którego dostępna jest praktycznie nieograniczona liczbę bibliotek.
3. \"Kkomunikacja po EIA 485 jest oczywiście ale...\" - no jest i normalnie nie potrzeba do tego bramek, interfejsów, API, sztuczek. Po ustaleniu parametrów transmisji pozostają już bity, bajty, telegramy = protokół. Rozumiem, że protokół może być tajny bo np.:
- polityka firmy (nie, bo nie),
- protokół nieopracowany (luźne zapiski, w różnych miejscach...)  - to już gorzej.
Zakładam, że to pierwsze.

Kończąc chyba ten wątek dziękuję za pomoc i pozdrawiam,
Ireneusz Puchała

RobertH

#7
Witam

ad.3
Protokół nigdy nie przewidywał innych urządzeń na magistrali EIA 485 niż paneli i zasilacza PSR-ECO.
Dlatego oprócz \"ustaleniu parametrów transmisji\' wymagane jest odpowiednie adresowanie i identyfikacja.
Nie ma w protokole identyfikatora dla innych urządzeń np. \'wirtualnej klawiatury\' i dlatego NEO nie będzie dedykowane do integracji.
Po wakacjach wprowadzamy VISUM , który ma całkowicie inne założenia i to jest nasze stanowisko.

Z poważaniem
Robert Hodurek