Chinese Traditional

eHouse4Java eHouse家庭自動化的開放源碼軟件

eHouse 家庭自動化 eHouse4Java – JAVA（開源）軟件包括以下模塊（ . JAVA – 源代碼 , . 類 – 由此產生的類）：

  • Ehouse4java . JAVA – 的應用程序的核心和主界面
  • ehousecommunication . JAVA – 通信功能和配置
  • EhouseTCP . JAVA – 通信和配置​​的控制器
  • EventsToSend . JAVA – 次要事件處理
  • EventToSend . JAVA – 一個單一的事件的定義
  • GraphicObject . JAVA – 圖形對象定義
  • ISYS . JAVA – 包括對供應商的專用功能
  • RunEvent . JAVA – 從文本的形式發送事件
  • StatusEhouse . JAVA – 類包含一個實例為每個eHouse1控制器
  • StatusEthernet . JAVA – 類包含一個實例為每個以太網eHouse控制器
  • StatusServer . JAVA – 輔助TCP / IP服務器 , 通過LAN發送所有控制器的狀態通過TCP / IP客戶端板（外部 , 廣域網 , 內部網 , 互聯網）
  • 可視化 . JAVA – 按照與的eHouse可視化和圖形控制標準的可視化/圖形控制類

在軟件源代碼eHouse4Java的描述函數和全局變量 .
該軟件包括獨立的線程 , 例如： . 通訊 , 這些關係到主應用程序在後台執行的 .
這不阻止或延緩的應用程序的過程要花很長時間 , 導致到一個顯著慢下來的應用程序和懸浮液的可能性，同時等待通信（死鎖） .
的主要思路是：

  • TCP客戶端（接收狀態的控制器 , 在局域網上的TCP / IP , 廣域網 , 網際網路 , 內聯網）
  • UDP監聽器（用於收聽廣播狀態，在無連接的UDP） – 僅在局域網內 , 內部網
  • 語音合成器來播放任何聲音的短信
  • 多線程的TCP / IP服務器 – 來路由接收到的狀態的任何類型的連接的客戶端面板（通過局域網 , WIFI , 網際網路 , 內部網 , WAN）

與控制器的通信介質的名稱所包含的設置形式選擇的連接類型（LAN TCP , LAN UDP , 網際網路 , 關） .
其他線程被激活使用全局變量是在類 ” EhouseTCP ” 或 ” ehousecommunication ” .

該應用程序使用一個可視化的根據eHouse標準 , 從CorelDraw應用程序中使用腳本，使：

  • 進口eHouse系統配置
  • 手動或通過腳本的圖形對象的創建
  • 將數據導出為所有面板的可視化方法 , Web瀏覽器 , 個人計算機 , 片 , 智能手機和其他系統

進一步討論這個問題的文章：
” ，創建圖形可視化和控制eHouse智能家居 ” .
可視化軟件是基於一個可伸縮矢量圖形（SVG） .
此方法允許您 ” 無損 ” 品質的繪圖曲線 , 文本 , 簡單的幾何圖形 , 不論放大的規模的 , 畫面位移 , 等 .
它不會有可能使用背景圖形圖像，如JPG , 位圖 , 等 . .
軟件可視化已被優化，以減少聯機工作時，利用CPU和圖形處理時間 , 由於大的數據量處理 . 當接收狀態控制器，圖形圖像緩存分為適當的控制信號和處理 , 並顯示在屏幕上要快得多從可視化每個控制器的緩存 .

這使得：

  • 用於可視化處理後的數據的圖像的變化顯著減少
  • 顯著減少閃爍時，改變投影圖像
  • CPU和數據可視化的負載顯著減少
  • 使用多 ” 弱 ” , 更有效和更昂貴的硬件 , 圖形面板 , 片 , 控制面板 , 等 . , 同時保持一個舒適的工作
  • 減少功率消耗，這是特別重要的，在電池和移動設備和長度對電池的工作

這是討論在文章中的截圖：
” 在Java的圖形可視化和智能家居控制 ”

EHouse4Java通信控制器 家庭自動化

eHouse1的監督下，PC

在這個版本的應用程序eHouse . exe文件作為接收器的狀態的RS – 485（與轉換器RS – 485/RS – 232）和發送的狀態沒有任何變化的兩個方法不互相碰撞：

  • eHouse . EXE工程作為一個TCP / IP服務器響應查詢的狀態面板 , 指連接面板和維護，直到斷開以任何理由 . 此試圖建立通信通過網絡與外部的TCP / IP面板的方法是特別有價值的。 , 諸如因特網，這是不可能接收UDP狀態 .
  • eHouse . exe文件發送任意數量的客戶端在LAN上的廣播無連接的UDP協議 , 內部網 . 這意味著 , 面板沒有連接到服務器 , 但監聽廣播消息 ” eHouse . exe文件 ” 應用程序 . 在這種方式中，沒有多少收件人板狀態不改變網絡負載 , 或計算機上 ” eHouse . exe文件 ” 運行應用程序 . 不幸的是，它是不可能的或是十分困難的，所以在這種情況下，通過因特網發送UDP廣播應使用第一種方法 .

監督CommManager eHouse1在

在這個版本中 , CommManager接收傳入的狀態，通過RS – 485（來自eHouse1控制器），並發送該狀態沒有任何變化的兩個方法不互相碰撞：

  • 的CommManager作品為TCP / IP服務器響應查詢的狀態面板 , 指連接面板和維護，直到斷開以任何理由 . 這種方法顯得尤為可貴嘗試建立通信與局域網以外的面板 , 諸如因特網，這是不可能接收UDP狀態 .
  • CommManager發送廣播（連接），UDP協議是局域網上的任何數量的客戶端 , 內部網 .
    這意味著 , 該小組沒有連接到服務器的TCP CommManager , 但聽著從CM的廣播消息 . 在這種方式中，沒有多少收件人面板的狀態 , 它不會改變的網絡負載或CommManager的CPU利用率 . 廣播UDP廣播是不可能的 , 或在很大程度上阻礙通過互聯網，以便在這種情況下，應使用的第一種方法 .

以太網eHouse（eHouse4Ethernet）

在這個版本的以太網控制器：CommManager , EthernetRoomManager , 等 . , 獨立兩種方式發送自己的狀態 , 不互相碰撞：

  • 每個控制器都可以作為一個TCP / IP服務器響應查詢的狀態面板 , 指連接面板和維護，直到斷開以任何理由 . 此方法是特別有價值的，試圖建立通信的LAN外部的與面板 , 諸如因特網 , 它是不可能接收UDP狀態 .
    但 , 在多個以太網控制器的情況下，有必要維持一個連接到TCP / IP的每個控制器 , 直接從控制器接了一個完整的系統狀態 . 這可能會導致在處理器的控制面板上的更大的負載 , 的通信相關的問題的嚴重程度 . 在這種情況下 , 優選的是，放置在LAN側應用程序 , 接收本地UDP狀態 , 並轉發該TCP / IP上經由因特網 . 這是實現和的應用eHouse4Java討論 , 這使得這種解決方案 . 其缺點是需要保持額外的硬件執行這些功能 .
  • 每個控制器發送一個廣播（無連接）UDP協議是任意數量的LAN上的客戶端 , 內部網 . 這意味著 , 面板沒有連接到TCP服務器控制器 , 但聽的消息廣播的所有控制器 . 在這樣無論有多少受助板狀態不改變網絡負載或控制器的CPU利用率 . 廣播UDP數據包是不可能的，或通過互聯網在很大程度上阻礙 , 所以在這種情況下，應使用第一種方法 . 的UDP傳輸的可能性，有時是鏈接的類型可能取決於 , 性能 . 有時有可能獲得廣播UDP通過VPN正確配置的鏈路 , 但 , 即使在這種情況下 , 數據包可能會丟失 , 由於缺乏為UDP的安全機制 . 不正確的數據將被自動取消的軟件eHouse板的非校驗（校驗和）