Programowalne instalacje elektryczne - wątek dla entuzjastów

[ravbc]

Kierunek z własnym softem - także widzi mi się jako kierunek z ogromnymi możliwościami. Ale wbrew pozorom taki prosty wcale nie jest. Oczywiście zależy od ilości wolnego czasu, ale przy budowie domu tego czasu zwykle nie ma. A po wybudowaniu - albo już się nic nie chce, albo trzeba odrabiać najpierw to co się zawaliło w czasie budowania domu. Piszę na podstawie własnych doświadczeń.

Niestety muszę się z tym zgodzić. No ale jak ma się wybór: zrobić samemu kiedyś, albo nie kupić (z braku odpowiednich funduszy) nigdy, to się nie ma wyboru

 

nie należy się nastawiać wyłącznie na sterowanie pecetowe

Jak mawia Adam_mk: "prawie prawda, tyle że... nie prawda" Jak dla mnie jedynymi używalnymi urządzeniami są takie o ekranach minimum 4" (jako pseudo pilot) albo nawet 7" (jako stały panel). Generalnie jeśli tej wielkości urządzenie nie posiada normalnej przeglądarki internetowej, to jest do bani Telefon to może i fajnie mieć pod ręką, ale telefony są wooooolne. I małe na dodatek. I niewygodne (te klawiatury i mikro-ekrany). No a jakbym miał się szarpnąć na lepszy telefon (z większym ekranem), to już chyba wolę dedykowanego pilota (palmtopa), bo wielkiego telefonu mi się nie będzie chciało nosić Poza tym praktycznie wszystkie nowsze telefony z dużymi ekranami mają normalne przeglądarki internetowe...

Jest jeszcze druga strona medalu: dla mnie ten interfejs webowy jest do "celów specjalnych", a nie standardowej obsługi domu. Do codziennego użycia to wolę włączniki na ścianach, a do zadań specjalnych mogę skorzystać z peceta (kilka takich "lokalnych ekranów" planuję umieścić w strategiczych miejscach domu - tj. tam gdzie najczęściej przebywam bez laptopa ).

 

potrzebna jest technologia typu push - AJAX to nie wszystko, to tylko odpytywanie; potrzebna jest możliwość sygnalizacji zdarzeń wywoływana przez sterownik/serwer; odpytywanie/pooling nawet co 1 sekundę - to półśrodek i prowizorka, która popsuje znacznie efekt;

To jest ograniczenie czystego HTMLa, z którego trzeba sobie zdawać sprawę. Oczywiście nie jest to wyjście najładniejsze, ale jeśli sprytnie zrobione, to przy nikłym obciążeniu jakie domowe panele mogą generować z obsługą zapytań nawet platformy typu embedded sobie poradzą. Poza tym bardzo trudno mi sobie wyobrazić sytuację gdzie ten 1-sekundowy interwał odświeżania informacji byłby problematyczny (choć to pewnie też kwestia budowy całej aplikacji). W każdym razie da się to ograniczenie obejść jak już bardzo się chce.

 

bezpośrednie skomunikowanie interfejsu użytkownika ze sterownikiem powoduje ograniczenia i kłopoty w większym systemie

To jest oczywiste nieporozumienie. Jedyna rozsądna droga, to moim zdaniem zbudowanie platformy pośredniczącej, która będzie z jednej strony odczytywać (ale i ustawiać) stan urządzeń wykonawczych (sterowniki, alarmy, itp.), a z drugiej strony wystawiać API dla interfejsu użytkownika. Przy czym API to powinno jedynie generować "zadania" dla tego pośrednika, które on ma zrealizować. Na dodatek zadania te wcale nie muszą (a nawet nie powinny) być związane z określonymi urządzeniami wykonawczymi (tj. z punktu widzenia użytkownika nieistotne jest co kontroluje zapalenie światła, ważne jest aby się to światło zapaliło).

Krótko mówiąc: model MVC jest tu jak najbardziej na miejscu, tylko że nieco bardziej "rozciągnięty".

 

Biorąc pod uwagę powyższe - nie chciałbym tego dłubać np. w php. Idealnie wszystkie warunki spełnia java, ale za to wymaga trochę mocniejszego w zasoby serwera (z PC to nie problem, ale jakby ktoś chciał na jakimś urządzeniu embedded to trzeba dokładnie sprawdzić). Pewnie jakieś inne też wchodzą w grę, ale nie znam.

php się nada do wszystkiego poza może faktyczną komunikacją z urządzeniami wykonawczymi. java jest niefajna - za ciężka, zbyt problematyczna (wersje), no i zbyt niskopoziomowa do większości rzeczy, a zbyt wysokopoziomowa do niektórych. A może po prostu ja nie lubię javy? W każdym razie je się aktualnie skłaniam do pythona - ładny, czysty język, o wielkich możliwościach, wysokopoziomowy, ale nie blokujący dostępu do funkcji niskiego poziomu. Nieco bardziej zasobożerny niż programy binarne, ale i tak znaacznie lżejszy niż java. No i istnieje zdaje się biblioteka modbusowa Aktualnie to mój faworyt.

 

Uwzględnienie tego wszystkiego, dobre zaprojektowanie - niestety wymaga czasu i pracy. Być może jakąś prowizorkę da się sklecić prościej, szybciej, i bez takich dywagacji. Ale przecież nie o prowizorki chodzi.

super proste to nie jest, ale i jakoś szczególnie skomplikowane być nie powinno. W końcu jeśli prawidłowo zacząć, to można to robić ewolucyjnie. Jak już będziemy mieli tą warstwę pośredniczącą, która umie tłumaczyć zlecenia z interfejsu na odpowiednie polecenia urządzeń wykonawczych, oraz przekazywać w zjadliwej formie stan tych urządzeń do wyświetlenia na interfejsie, to dodawanie kolejnych funkcji (poleceń) do interfejsu powinno być niemalże na poziomie copy&paste

 

Z gotowymi rozwiązaniami jednak łatwiej, to wszystko naprawdę jest wyłącznie dla hobbystów.

Tylko kogo na nie stać? No i o ile fajniej jest zrobić to "tak jak ja chcę", a nie tak jak producent sobie wymyślił...

 

A jakby ktoś chciał iść w panele operatorskie to przypominam, że mam nieużywanego niedrogiego weinteka do odstąpienia

Błędy młodości...

[odaro]

Napiszcie kto z Was zastosował elektrozawór do gazu i jak to rozwiązał tzn jaki tym elektrozaworu zastosował itd.

[mkrzeminski]

Potrzebuje przykłady programów w fateku. Wiem ze w googlu mozna wszystko znalezc ale nic mi sie konkretnego nie udalo odnalezc. Było coś na http://www.dom-inteligentny.com/ ale strona od jakiegoś czasu nie chodzi. A może macie jakąś dokumentacje o tworzeniu algorytmów na sterownikach plc. ściągnołem masę plików ale nic fajnego nie znalazłem. Puki relizowałem proste funkcje włącz/ wyłącz to wszystko było OK, ale jak potrzebuje stworzyć bardziej skomplikowane sterowanie to Fatek nie robi tego co mi się wdaje ze powinien robić. Musze się dokształcić

[civic9]

Jakoś nie było zainteresowania i zapomniałem o dom-inteligentny.com.

Przywróciłem tam najważniejszą zawartość - ale właściwie była tam tylko jedna rzecz, pewne podejście do dokładnego sterowania roletami. Nawet jeśli większość uzna to za przesadę w sterowaniu roletami, to możesz to wykorzystać jako przykład do przeanalizowania i nauczenia się jak zaprogramować pewne rzeczy, jakąś większą całość.

 

Musiałem zmienić adres strony w DNS - jeśli stronka jeszcze nie jest widoczna, to będzie niedługo, max. w ciągu 24h.

 

Nazbierałem już trochę rzeczy w swoim programie - jak będę miał trochę więcej czasu to powycinam, poopisuję i udostępnie.

[mkrzeminski]

Mam naprzykład taki problem

 

Jezeli w wiecej niz jednym miesjcu programu ustawiam stan powiedzmy M1000. To nie reaguje mi na wykrywanie zbocza narastajacego M1000. Jezeli M1000 ustawione jest tylko w jednym miejscu. To wszytsko jest ok.

 

Po co mi to ? Juz tlumacze. Chcialem rozdzielic czesc wykonawcza od interfejsu.

W czesci interfejsu czyli reakcji na nacisienicie klawiszy dzwonkowych wydawane sa polecenia. W w czesci interfejs pokoju 1 nacisiniecie przycsiku powaoduje wydanie rozkazu M1000 czyli set M1000. W innej czesci programu o okreslonej godzinie tez wydane jest polecenie M1000.

 

Czesc wykonawcza reague na zbocze wznoszoce m1000 i uruchamia zamykanie rolety kontoluje czasy ustawia stany itd.

 

Puki m1000 bylo ustawiane w jednym miejscu to dzialalo, a jak m1000 ustawiane jest w 2 miejscach to owszem stan m1000 zmiania sie z 0 na 1, ale nie jest wykonywane to co powinny byc przy wykryciu zbocza wznoszacego m1000

 

Wiem powinienem wstawic obrazek ale...moze ktos zrozumie ten belkot

[civic9]

ja bym wolał obrazek

 

najczęstsze problemy to właśnie mieszanie set/reset ze zwykłym ustawianiem coils oraz wzajemne powiązania wyjść na wyjściu, ze stanami wyjść jako warunki dalszych akcji. też pewnie nie jasno napisałem

[mkrzeminski]

a czym rózni sie operacje set/reset

 

 

ze zwykłym ustawianiem coils

[civic9]

w WinProLadderze, na pasku narzędziowym masz pod literkami:

 

O - Coil

Q - Inverse Coil

E - Set Coil

R - Reset Coil

 

pierwsze dwa powodują włączenie lub wyłączenie wyjścia na czas jednego cyklu programu. ostatnie dwa włączają/wyłączają wyjścia na stałe - do czasu następnej zmiany. można to oczywiście mieszać, ale jak się dobrze nie przemyśli to łatwo wpaść w na przykład taką sytuację, że z jednej strony robimy reset coil, i wydaje nam się, że wyjście powinno być wyłączone, a gdzieś w innym miejscu programu używamy zwykłego Coil, które to wyjście włącza. i na odwrót.

 

tak tylko o tym wspomniałem, bo nie raz szukałem błędu u siebie i takie właśnie coś się okazywało.

[odaro]

Czy takie panele dotykowe dałoby się połączyć w jeden system z sterownikami PLC.

 

Po szybkiej lekturze wydaję się da się je zaprogramować do wielu systemów nie tylko KNX.

 

Ciekawe tylko jaka jest cena na te panele.

 

http://www.aminstal.pl/divus.html

 

http://www.knxforum.pl/viewtopic.php?f=31&t=139

[ravbc]

Te ekrany to de facto PCety z Windowsem. Skoro mają przeglądarkę na pokładzie, to da się to połączyć z PLC, ale oczywiście za pośrednictwem dodatkowego "serwera" (czyli tak, jak to jest też łączone z KNX).

[odaro]

Te ekrany to de facto PCety z Windowsem. Skoro mają przeglądarkę na pokładzie, to da się to połączyć z PLC, ale oczywiście za pośrednictwem dodatkowego "serwera" (czyli tak, jak to jest też łączone z KNX).

 

Znalazłem cenę do KNX jest powalająca

 

Natknął się ktoś na takie ekrany.

[ravbc]

Poszukaj sobie pecetów z ekranem dotykowym (np. Asus Eee Top - sakramencko drogi ), albo po prostu ekranów dotykowych i podepnij je do zwykłego małego peceta. (BTW: ekran dotykowy można stosunkowo tanio zrobić niemal z każdego wyświetlacza LCD). Oczywiście nie będzie to wtedy wyglądało jak panel przemysłowy...

[mario0658]

tak szuka i szukam...

cos gdzies slyszalem ze jest jakis programik na komorke pod satela.

Na stronie producenta nie ma o tym ani slowa...

Ktos widzial / posiada owo cudo ?

[civic9]

jest jako dodatek do ich modułu ethernetowego.

http://www.satel.pl/pl/product/115/ETHM-1,Modul_komunikacyjny_TCP_IP_dla_central_INTEGRA_

[tomekkasztelan]

Witam

 

Trochę późno dołączyłem się do dyskusji, ale troszkę siedzę w temacie służbowo:)

 

W firmie mamy już wersję beta softu na smartphony z systemem Windows Mobile - prezentacja programu odbyła się w marcu 2009 na targach TARBUD we Wrocławiu.

 

Generalnie soft na GSM jest prosty:

 

* definiuje się sposób logowania/weryfikacji/autoryzacji

* tworzy się bazę danych komunikatów SMS (komend) do których przyszywa się konkretne ikony

* jeśli system obsługuje, można w jednym SMS'ie upchać ciąg komend

- uzbrój alarm

+opuść rolety w całym domu

+obniż ogrzewanie do stand by

+zgaś światło

+odetnij napięcie w wybranych gniazdach wew. i na zewnątrz budynku

(oczywiście jeśli światło jest już zgaszone, czynność taka nie zostanie wykonana)

* po wykonaniu czynności (jeśli mamy sygnały zwrotne w systemie) na komórkę zostanie wysłane potwierdzenie

* można odpytać też system o konkretne stany/statusy

 

Soft ten działa generalnie ze wszystkimi systemami automatyki budynku i centralkami alarmowymi i innymi otwartymi (konfigurowalnymi co do treści komend SMS) systemami. Sprawdziliśmy to na systemie DUPLINE, INELS, UNISYSTEM, SATEL i działa. Z KNX są problemy.

 

Nie chcę być zabanowany za ten tekst, ale soft jest przygotowywany dla beta-testerów, wiec będzie za free z pełnym supportem. Chętnie wymienię się doświadczeniami z testów i prób - także szukamy, próbujemy z innymi ... z różnym skutkiem.

 

Niestety Windows Mobile powoli przestaje być rozwojowy, trzeba się docelowo na JAVA'ę przesiąść, ale to później.

 

pozdrawiam

 

T.K.

[mario0658]

czy mozna prosic o linka do tego softu ?

[tomekkasztelan]

Niestety mam tylko wersję niestabilną. Poza tym czekam na zielone światło, żeby uruchomić program beta-testerów. Jak tylko wypuścimy wersję stabilną beta wrócę do wątku na forum (tu proszę moderatora o autoryzację wrzucenia linku).

 

Generalnie sterowanie GSM jest dobrą rzeczą zdalnie. Nas osobiście boli, że nasz telefon (wyposażony w komunikację WiFi - a jest to tylko kwestia czasu kiedy większość smartphonów będzie WiFi) w domu nie może zamienić się w pilot (np. "GSM" a'la Nevo S70). Jest to oczywiście wykonalne, przy czym system musiałby być także sterowany po IP (np. jak obsługa rejestratora, podgląd kamer w domu za pomocą domowej sieci WiFi i softu pod WEP).

 

Ale to prototypomyslenie.

[Kane76r]

Jako ze jestem juz po tynkowaniu okablowaniu itp a nieco za pozno zorientowalem sie czego bede potrzebowal w domu mam drobne pytanie.

Czy ktos moze znalazl gdzies sterowniki do alarmu ( oraz automatyki domu ) w postaci dotykowego LCD na ktorym mozna by zrobic rysunek domu z naniesionymi systemami ( rolety kontaktrony ogrzewanie itp ) i sterowac nimi ( albo sprawdzac ktore okno jest otwarte ). Mam centralke integra 64, ktora bedzie podlaczona do PCta ( jeszcze nie wiem czy przewodem RS czy skretka po ethernecie )

[zylko]

 

Najprostszą i najszybszą metodą jest spięcie wyjść alarmu z wejściami PLC. Pewnym ograniczeniem jest zapewnienie odpowiedniej ilości wyjść/wejść. Jednakże pomaga tutaj wiele logika samego np. Satela gdzie wyjście może być aktywowane zbiorem czujek lub akcją logiczną wejść alarmu - można w ten sposób ograniczyć liczbę potrzebnych wyjść/wejść. Jedną z praktycznych realizacji opisałem tutaj: Połączenie alarmu Satel do sterownika PLC

(zrobiłem update schematu - powinno być czytelniej)

 

PJ

Witam wszystkich,

 

Czytając ten wątek od kilku godzin (na razie dobrnąłem do 36 strony), przy temacie integracji SATELA z PLC FATEK chciałem zapytać czy osoby które orientuję się w możliwościach jednego i drugiego urządzenia oraz posiadają doświadczenia w ich integracji, były by uprzejme ocenić alternatywny sposób komunikacji urządzeń (w warstwie logicznej).

Odnotowałem (chyba że błędnie wówczas proszę o sprostowanie), że do integracji "poświęcane" jest jedno wyjście na integrze SATELA i jedno wejście na PLC (np. FATEK) do obsługi jednej funkcji (np uzbrojenie alarmu w jakieś strefie).

Zastanawiam się, czy możliwa była by komunikacja za pomocą zapisu/odczytu do kilku wyjść/wejść w jednym cyklu, takie binarne kodowanie stanu centrali. Wówczas np na 4 parach wyjście/wejście mogli byśmy zakodować 16 stanów (generalnie 2^n, gdzie n to ilość parr wejście/wyjście), co było by nie bez znaczenia dla kosztów instalacji.

Zapewne wiązało by to się, z jakimś mechanizmem cachowania po stronie nadawcy lub co najmniej odpowiednim doborem opóźnień, pytanie czy na pierwszy rzut oka jest z czym walczyć??

Jednocześnie zaznaczę, że nie jestem użytkownikiem ani alarmu ww. firmy ani sterownika PLC, więc może mój pomysł jest z jakiegoś powodu nie realizowalny . Wówczas proszę o jakieś krótkie wyjaśnienie, ponieważ szukam swojej drogi do domu, który będzie wyposażony w instalację automatyki i PLC wydaje się dobrym kompromisem ceny do funkcji, a będzie to miało niebagatelny wpływ na ilość potrzebnych wejść/wyjść.

 

Pozdrawiam,

Andrzej

[climber79]

 

Najprostszą i najszybszą metodą jest spięcie wyjść alarmu z wejściami PLC. Pewnym ograniczeniem jest zapewnienie odpowiedniej ilości wyjść/wejść. Jednakże pomaga tutaj wiele logika samego np. Satela gdzie wyjście może być aktywowane zbiorem czujek lub akcją logiczną wejść alarmu - można w ten sposób ograniczyć liczbę potrzebnych wyjść/wejść. Jedną z praktycznych realizacji opisałem tutaj: Połączenie alarmu Satel do sterownika PLC

(zrobiłem update schematu - powinno być czytelniej)

 

PJ

Witam wszystkich,

 

Czytając ten wątek od kilku godzin (na razie dobrnąłem do 36 strony), przy temacie integracji SATELA z PLC FATEK chciałem zapytać czy osoby które orientuję się w możliwościach jednego i drugiego urządzenia oraz posiadają doświadczenia w ich integracji, były by uprzejme ocenić alternatywny sposób komunikacji urządzeń (w warstwie logicznej).

Odnotowałem (chyba że błędnie wówczas proszę o sprostowanie), że do integracji "poświęcane" jest jedno wyjście na integrze SATELA i jedno wejście na PLC (np. FATEK) do obsługi jednej funkcji (np uzbrojenie alarmu w jakieś strefie).

Zastanawiam się, czy możliwa była by komunikacja za pomocą zapisu/odczytu do kilku wyjść/wejść w jednym cyklu, takie binarne kodowanie stanu centrali. Wówczas np na 4 parach wyjście/wejście mogli byśmy zakodować 16 stanów (generalnie 2^n, gdzie n to ilość parr wejście/wyjście), co było by nie bez znaczenia dla kosztów instalacji.

Zapewne wiązało by to się, z jakimś mechanizmem cachowania po stronie nadawcy lub co najmniej odpowiednim doborem opóźnień, pytanie czy na pierwszy rzut oka jest z czym walczyć??

Jednocześnie zaznaczę, że nie jestem użytkownikiem ani alarmu ww. firmy ani sterownika PLC, więc może mój pomysł jest z jakiegoś powodu nie realizowalny . Wówczas proszę o jakieś krótkie wyjaśnienie, ponieważ szukam swojej drogi do domu, który będzie wyposażony w instalację automatyki i PLC wydaje się dobrym kompromisem ceny do funkcji, a będzie to miało niebagatelny wpływ na ilość potrzebnych wejść/wyjść.

 

Pozdrawiam,

Andrzej

 

Faktycznie można by tak zrobić przy n liniach - jedną przeznaczyć na powiedzmy "zegar", jedna na stan i n-2 na adres.

Ustawiamy adres, stan linii i wtedy odpalamy wyjście zegarowe dając znać urządzeniu po drugiej stronie że stan na pozostałych liniach jest ustalony.

Jak zauważyłeś potrzebny by był jakiś cache po stronie nadawczej ponieważ ten sposób nie wystawiało by sie stanu na jakiejś linii a tylko przesyłało zdarzenia - np linia zał. / linia wył.

O ile jestem sobie to w stanie wyobrazić na PLC (choć pewnie nie trywialne) to na Integrze już mniej (no ale dobre by było chociaż w jedną stronę).

Zależy w jakim zakresie zamierzasz zintegrować PLC z alarmem - jesli w znacznym to jest o co walczyć