eHouse4Java Software modules for eHouse Smart Home
Smart Home
eHouse4Java (eHouse for Java) – Open Source Software contains the following modules ( .java – source code , .class – resulting class ) :
- Ehouse4java.java – The core of the application and the main interface
- ehousecommunication.java – communication functions and configuration
- EhouseTCP.java – communication and configuration of controllers
- EventsToSend.java – Auxiliary handle events
- EventToSend.java – the definition of a single event
- GraphicObject.java – definitions of graphical objects
- isys.java – includes dedicated functions for different vendor
- RunEvent.java – class text form send events
- StatusEhouse.java – class contains one instance for each eHouse1 controller
- StatusEthernet.java – class contains one instance for each Ethernet controller eHouse
- StatusServer.java – Server Support broadcast all statuses drivers over TCP / IP to the clients of panels ( external via LAN , WAN , Intranet , Internet)
- visualization.java – Visualization class in accordance with eHouse
The most important functions and global variables is in the software source code eHouse4Java.
The software includes independent threads (Threads) eg. communication , that are performed in the background in relation to the main program ,
not blocking main application processes that take too long which resulted to a significant slowdown of work (look and feel) and possibility of hangs while waiting for communication (dead locks ) .
The main motifs are :
- TCP Client ( to receive the status of the controller on the tcp / ip on the LAN , WAN , Internet , Intranet )
- UDP Listener ( for listening to broadcast ‘ ‘ s status in the connectionless UDP ) – Only in the LAN, WiFi, Intranet network,
- The voice synthesizer to play any text messages acoustic
- Multithreaded TCP/IP Server to route the received status to the connected client panels, smartphones, PADs, PC etc of any type ( after LANs , WIFI , Internet , Intranet , WAN)
Communication Threads for controllers are included with the settings on the form for choose the type of connection ( LAN TCP , LAN UDP , Internet , Off ) .
Other threads are activated using global variables are in classes ” EhouseTCP ” or ” ehousecommunication ” .
The application uses the visualization according to eHouse standard , generated from CorelDraw using scripts that enable:
- import system configuration eHouse
- creation of graphical objects manually or using JavaScript
- export data for all visualization methods for arbitrary systems
This is discussed in more detail in the article: creating graphical visualization and control for eHouse smart home .
Software visualization is based on a scalable vector graphics SVG . This method allows the “lossless” and without loss of quality drawing curves , text , simple geometric figures , regardless of the size of magnification , shift the display , etc. .
This would be impossible in case of background images such as jpg , bitmaps , etc. .
Software visualization has been optimized in order to reduce the utilization of the CPU and graphics processing time when working online . Because of the large amount of data processing, graphic images are cached by concerned controller signals and processed when receiving the status of the controller , and displayed on the screen much faster with the cache “cache” visualization of each driver.
This allows:
- significant reduction of the processed data to visualize the changes in the image
- significant reduction in flicker when changing projected images
- significant reduction of processor load and processing visualization
- use much ” weaker ” , less efficient and less expensive hardware , graphic panels , PADs , he control panel while maintaining a comfortable working
- reduction in electricity consumption which is especially important in battery and mobile equipment
This is further discussed along with the screenshots in the article: Graphical visualization and control of smart home in Java
EHouse4Java communication with controllers smart home variants
eHouse 1 Under the supervision of the PC
In this version of the application eHouse.exe works as a receiver status of the RS-485 ( via RS-485 / RS-232 convarter) and transmits the status without any further change in two ways not conflicting with each other:
- eHouse.exe works as a TCP/IP server responds to the query panel of statuses referring another connection to the panels and maintaining them until disconnected for any reason. This method is particularly valuable when trying to help communications panels outside the LAN , e.g., the Internet where it is not possible to receive UDP status .
- eHouse.exe sends a broadcast the connectionless UDP protocol for any number of clients on the LAN , intranet . This means , that the panel does not connect to the server , but listens to messages sent by applications “eHouse.exe ” all over the network. No matter how many panels recipients status does not change the load on the network or computer on which the application is running “eHouse.exe” .
Unfortunately it is not possible or is very difficult to transmit UDP broadcast via the Internet so in this case the first method should be used.
eHouse 1 Under the CommManager supervision
In this version of CommManager receives incoming status of the RS-485 ( eHouse 1 controllers) and sends the status adding its own status:
- CommManager works as a TCP/IP server responds to the query panel of statuses referring another connection to the panels and maintaining them until disconnected for any reason . This method is particularly valuable when trying to help communications panels outside the LAN , e.g., the Internet where it is not possible to receive UDP status
- CommManager sends broadcast via connectionless UDP protocol for any number of clients on the LAN , WiFi, intranet . This means , that the panel does not connect to the TCP server of CommManager, but listens to broadcast messages. Now, no matter how many panels recipients of status, does not change the network load or CommManager processor utilization . If the UDP broadcast is not possible or is very difficult via the Internet first method should be used.
Ethernet eHouse ( eHouse4Ethernet )
In this version of Ethernet controllers : CommManager , EthernetRoomManager so independently send their status in two ways not conflicting with each other :
- Each controller works as a TCP/IP server responds to the query panel of statuses referring another connection to the panels and maintaining them until disconnected for any reason . This method is particularly valuable when trying to get communications panels outside the LAN , e.g., the Internet where it is not possible to receive UDP status.
However, in the case of multiple Ethernet controllers is necessary to maintain a connection to the TCP/IP server each eHouse controller , to pick up a complete status of thesystem directly from controllers. This may cause higher CPU load control panel , the severity of the problems associated with communication. In this case, it is preferable to place on the LAN side application (eHouse4JavaC, ehouse.exe, eHouse.PRO server) , which receives UDP status locally , and forwards via TCP/IP over the Internet. The disadvantage is the need to maintain additional hardware that performs these functions .
- Each controller sends a broadcast the connectionless UDP protocol for any number of clients on the LAN , Intranet . this means , that the panel does not connect to the server TCP Controller , but listens to broadcast messages. Now, no matter how many panels recipients status does not change the network load or Controller utilization. UDP Broadcasting is not possible or is very difficult via the Internet so in this case the first method should be used. The ability to transmit the UDP status is sometimes possible depending on the type of link , performance . Sometimes it is possible to obtain a UDP broadcast properly configured VPN connection. However, even in this situation, the packets may be lost by the absence of the protection and verification mechanism in UDP . Erroneous data is automatically canceled by the software eHouse panels in case of wrong checksum