Inteligentny Dom eHouse – Oprogramowanie Open Source eHouse4Java zawiera następujące moduły (.java – kod źródłowy, .class – klasa wynikowa):

• Ehouse4java.java – Rdzeń aplikacji i główny interfejs
• ehousecommunication.java – funkcje komunikacyjne i konfiguracji
• EhouseTCP.java – komunikacja i konfiguracja sterowników
• EventsToSend.java – pomocnicza obsługi zdarzeń
• EventToSend.java – definicja pojedynczego zdarzenia
• GraphicObject.java – definicje obiektów graficznych
• isys.java – zawiera funkcje dedykowane dla różnych vendor’ów
• RunEvent.java – klasa formularza tekstowego wysyłania zdarzeń
• StatusEhouse.java – klasa zawierająca jedną instancję dla każdego sterownika eHouse1
• StatusEthernet.java – klasa zawierająca jedną instancje dla każdego sterownika Ethernet eHouse
• StatusServer.java – Obsługa serwera rozsyłania wszystkich statusów sterowników po TCP/IP do klientów paneli (zewnętrznych poprzez LAN, WAN, Intranet, Internet)
• visualization.java – klasa Wizualizacji zgodnej z eHouse

Dokładny opis funkcji i zmiennych globalnych znajduje się w kodzie źródłowym oprogramowania eHouse4Java.

Oprogramowanie zawiera niezależne wątki (Threads) np. komunikacyjne, które są wykonywane w tle w stosunku do głównej, aby nie zatrzymywać aplikacji procesami które trwają zbyt długo co spowodowało by znaczne spowolnienie pracy aplikacji i możliwość zawieszeń w czasie oczekiwania na komunikacje (dead locks).

Głównymi wątkami są:

• Client TCP (do odbioru statusu ze sterownika po tcp/ip po sieci LAN, WAN, Internet, Intranet)
• Listener UDP (do nasłuchiwania broadcast’ów statusów po bezpołączeniowym protokole UDP) – tylko w ramach sieci LAN, Intranet
• Syntezer mowy do ewentualnego odtwarzania tekstowych komunikatów akustycznych
• Wielowątkowy Serwer TCP/IP do rozsyłania odbieranych statusów do połączonych paneli klienckich dowolnego typu (Po sieciach LAN, WIFI, Internet, Intranet, WAN)

Wątki komunikacji ze sterownikami są włączane przy pomocy ustawień na formularzu wyboru typu połączenia (LAN TCP, LAN UDP, Internet, Off).

Pozostałe wątki są uaktywniane przy pomocy zmiennych globalnych znajdujących się w klasach „EhouseTCP” lub „ehousecommunication”.

Aplikacja wykorzystuje wizualizację zgodnie ze standardem eHouse, wygenerowaną z aplikacji CorelDraw przy pomocy skryptów pozwalających na:

• import konfiguracji systemu eHouse
• utworzenie obiektów graficznych manualnie lub przy pomocy skryptu
• wyeksportowanie danych dla wszystkich metod wizualizacji dla dowolnych systemów

Zostało to omówione szerzej w artykule:

tworzenie wizualizacji i sterowania graficznego inteligentnego domu eHouse.

Oprogramowanie wizualizacji jest oparte na zasadzie skalowanej grafiki wektorowej SVG. Taka metoda pozwala na „bezstratne” i bez utraty jakości rysowanie krzywych, tekstu, prostych figur geometrycznych, bez względu na rozmiar powiększenia, przesunięcia ekranu, itd.

Nie było by to możliwe przy zastosowaniu obrazów typu jpg, bitmap itd, czy tła graficznego.

Oprogramowanie wizualizacji zostało tak zoptymalizowane aby zmniejszyć utylizację procesora oraz czas przetwarzania grafiki przy pracy online. ze względu na dużą ilość danych do przetwarzania, obrazy graficzne są buforowane z podziałem na odpowiednie sygnały sterownika i przetwarzane podczas odbioru statusu danego sterownika, a wyświetlane na ekran znacznie szybciej z takiej pamięci podręcznej „cache” wizualizacji każdego sterownika.

Pozwala to na:

• znaczne ograniczenie przetwarzanych danych do wizualizacji przy zmianach obrazu

znaczne skrócenie migotania przy zmianie wyświetlanych obrazów

• znaczne zmniejszenie obciążenia procesora i przetwarzania danych wizualizacji
• wykorzystanie znacznie „słabszego”, mniej wydajnego i tańszego sprzętu komputerowego, paneli graficznych, tabletów itd. jako panel sterujący przy zachowaniu komfortowej pracy
• zmniejszenie zużycia energii elektrycznej co jest szczególnie ważne przy sprzęcie bateryjnym i mobilnym

Zostało to dokładniej omówione wraz ze zrzutami ekranów w artykule:

Wizualizacja i sterowanie graficzne inteligentnego domu w Javie

Komunikacja eHouse4Java ze sterownikami inteligentnego domu

eHouse 1 Pod nadzorem komputera PC

W tej wersji systemu aplikacja eHouse.exe pracuje jako odbiornik statusów z magistrali RS-485 (z konwertera RS-485/RS-232) i przesyła te statusy bez żadnych zmian dalej na dwa sposoby nie kolidujące ze sobą:

• eHouse.exe pracuje jako serwer TCP/IP odpowiadający na zapytania paneli o statusy nawiązując kolejne połączenia z panelami i utrzymując je do momentu rozłączenia z dowolnych przyczyn. Ta metoda jest szczególnie cenna przy pomocy próby łączności paneli spoza sieci LAN, np z internetu gdzie nie jest możliwe odbieranie statusów UDP.
• eHouse.exe wysyła broadcast’y po protokole bezpołączeniowym UDP dla dowolnej liczby klientów w sieci LAN, intranet.

  Oznacza to, że panel nie nawiązuje połączenia z serwerem lecz nasłuchuje komunikatów nadawanych przez aplikacje „eHouse.exe”. Dzięki temu niezależnie ile jest paneli odbierających dane statusów nie zmienia się obciążenie sieci ani komputera na którym pracuje aplikacja „eHouse.exe”. Niestety nie jest możliwe albo jest mocno utrudnione nadawanie broadcast’ów UDP poprzez sieć internet więc w tym przypadku należy stosować metodę pierwszą.

eHouse 1 Pod nadzorem CommManager’a

W tej wersji systemu CommManager odbiera nadchodzące statusy z magistrali RS-485 (sterowników eHouse 1) i przesyła te statusy bez żadnych zmian dalej na dwa sposoby nie kolidujące ze sobą:

• CommManager pracuje jako serwer TCP/IP odpowiadający na zapytania paneli o statusy nawiązując kolejne połączenia z panelami i utrzymując je do momentu rozłączenia z dowolnych przyczyn. Ta metoda jest szczególnie cenna przy pomocy próby łączności paneli spoza sieci LAN, np z internetu gdzie nie jest możliwe odbieranie statusów UDP.
• CommManager wysyła broadcast’y po protokole bezpołączeniowym UDP dla dowolnej liczby klientów w sieci LAN, intranet.

  Oznacza to, że panel nie nawiązuje połączenia z serwerem TCP CommManager’a, lecz nasłuchuje komunikatów nadawanych przez niego. Dzięki temu niezależnie ile jest paneli odbierających dane statusów nie zmienia się obciążenie sieci ani CommManager’a. Nadawanie broadcast’ów UDP nie jest możliwe albo jest mocno utrudnione poprzez sieć internet więc w tym przypadku należy stosować metodę pierwszą.

Ethernet eHouse (eHouse4Ethernet)

W tej wersji systemu sterowniki Ethernetowe: CommManager, EthernetRoomManager’y itd niezależnie przesyłają swoje statusy na dwa sposoby nie kolidujące ze sobą:

• Każdy sterownik pracuje jako serwer TCP/IP odpowiadający na zapytania paneli o statusy nawiązując kolejne połączenia z panelami i utrzymując je do momentu rozłączenia z dowolnych przyczyn. Ta metoda jest szczególnie cenna przy pomocy próby łączności paneli spoza sieci LAN, np z internetu gdzie nie jest możliwe odbieranie statusów UDP.

  Jednak w przypadku wielu sterowników Ethernetowych konieczne jest utrzymywanie jednego połączenia z serwerem TCP/IP każdego sterownika, aby odebrać kompletny status systemu bezpośrednio ze sterowników. Może to powodować większe obciążenie procesora panela sterującego, nasilenie problemów związanych z komunikacją. W tym wypadku korzystne jest postawienie po stronie sieci LAN aplikacji, która odbiera statusy UDP lokalnie, a przesyła dalej po TCP/IP przez internet. Może to być omawiana aplikacja eHouse4Java, która to umożliwia. Wadą jest konieczność utrzymania dodatkowego sprzętu komputerowego który wykonuje te funkcje.

• Każdy sterownik wysyła broadcast’y po protokole bezpołączeniowym UDP dla dowolnej liczby klientów w sieci LAN, Intranet. Oznacza to, że panel nie nawiązuje połączenia z serwerem TCP Sterownika, lecz nasłuchuje komunikatów nadawanych przez niego. Dzięki temu niezależnie ile jest paneli odbierających dane statusów nie zmienia się obciążenie sieci ani Sterownika. Nadawanie broadcast’ów UDP nie jest możliwe albo jest mocno utrudnione poprzez sieć internet więc w tym przypadku należy stosować metodę pierwszą. Możliwość transmisji po UDP jest czasami możliwe w zależności od typu łącza, wydajności. Czasami jest możliwe uzyskania broadcast’u UDP przez poprawnie skonfigurowane łącze VPN, jednak nawet w tej sytuacji pakiety mogą być gubione ze względu na brak mechanizmów zabezpieczeń przy UDP. Błędne dane są automatycznie anulowane przez oprogramowanie paneli eHouse w przypadku niezgodności sumy kontrolnej (check sum)