Cooperation control panels directly from Ethernet eHouse smart home controllers over UDP

Smart Home ,
intelligent building eHouse Ethernet version enables direct communication with virtually unlimited number of panels display the current status of microprocessor controllers using the UDP protocol in the LAN .

home automation ehouse – update panels over UDP ( User Datagram Protocol) .

Unlike the TCP protocol UDP is a connectionless protocol. Does not require a permanent connection between the client and the server, session tracking , lack of mechanisms to control data , flow and retransmission .
This makes the protocol much faster than TCP, However, it is possible to loosing data and other errors.
In the case of the User Datagram ( Individual frames for any system ) , correctness transmission must address the communication software.

UDP is ideal for sending broadcast ( messages , broadcast to multiple devices at once without establishing new connections with clients from the server ) . The most important features are the following :

• Connectionless protocol more receiving devices are not charged to the server
• messages are sent globally to all devices on the LAN
• the server does not matter whether you send messages to 0 or more devices or how much equipment hears these messages
• transmission errors have no impact on the sending server data
• data transmission is unprotected against errors , there is no confirmation , The flow control

Because UDP does not have a protected transmission errors, to use it in the system eHouse and to enable error checking data packets are sent twice.
This allows them to compare and use of client-side when two packages are identical. It does not burden the server which delivers data checksum algorithms counting or forming other safeguards transfer (symmetric) . eHouse system , Data for comparison is the responsibility of the client and its software .
Data is sent from the server in binary form and must be decoded by the client software . The server sends the data to the specified port (default 6789 ) , and the client must listen to incoming messages asynchronously on the port. Asynchronous transmission is , that data is not cached , and your device must receive packets on a regular basis at the time of dispatch. From the architecture of the system and the type of installation depends , if all the controllers are shipped parcel status on the same port or each on different and can be selected individually from system applications eHouse .

Data packet is the same as in the case of TCP transmission using Ethernet communications with drivers or software eHouse.exe for PC sending binary data over UDP. This allows the use of a single function ( procedure ) decoding of a frame regardless of the transmission medium or protocol .

The data are not secured in order to facilitate their decoding by the individual control panels and software for visualization and additionally burdening their server coding. This will allow you to display information on the panels in quantities limited only by the IP subnet mask that is 255 . Since these are only statuses devices without the possibility of switching on/off of individual devices , or run the system event , may be released to the public outside the LAN through the firewall . In special cases , you can create a VPN (Virtual Private Network) – tunneled connection to receive the status of drivers for external panels outside the network , or use a TCP connection with login type challenge – response (verification of dynamic code ) , which is still active . These data are not critical and no decoding application packages , however, a packet of ones and zeros , which must be decoded by the software package eHouse system for any type of panel .

eHouse.exe Software has been updated so , that allowed the reception of the data by the UDP – User Datagram Protocol . To do this, run the application eHouse parameter “ehouse.exe /VIAUDP” capitalization does not matter. This will allow for a much more reliable reception of the status of CommManager , and devices attached to controllers eHouse 1 working after RS-485 connected to CM. eHouse Application receiving ( listening ) only incoming packages from controllers. Packages are sent twice and in case of any data errors are simply ignored, and will be updated with the correct reception of the next package containing the status of the controller .

This method also frees clients from the server and network errors , routers , switch , since there is no case of breaking the communication with the server , due to the connectionless UDP protocol idea . This does not cause the suspension or permanent loss of the application updates , As with the protocol of the connection to the server , but only temporary for the duration of a link failure, and only loosing packages during breakdown or excessive load on the network .
Losing parcel status of the drivers is acceptable , because they are cyclically repeated when changing the status of each controller , and the minimum frequency is about 16 seconds if there is no change .

If you select this option for applications eHouse ceases to send its own binary status of the UDP , because these are the same data , which currently are spread directly from Ethernet controllers eHouse .
Text Status ( decoded by the application eHouse ) can still be broadcasted, if enabled in the application eHouse.exe , giving the user the ability to use the old control panels , text -based logs and binary packages not . In this case, the data passed by the application eHouse.exe , which is another link in the chain , from which the call panels with drivers depends additionally on .
Such use , however, is good for the system working completely in eHouse 1 standard (no CommManager ) as it gives you the opportunity to work with panels receiving data from the application eHouse.exe despite the lack of built-in Ethernet transmission controllers .