Background information:
Software-related incorporation of the EnOcean Com-Server
The established standard: OPC
Nearly all control and visualization systems available on the market already support the standard software interface OPC in their basic configuration or through use of available modules. Examples in this category include for example the Wonderware products, NI’s "LabView", "ShowIt" from Ing.-Büro Bauer, and many other powerful software packages which use the free W&T OPC server to enable a simple incorporation of the EnOcean Com-Server into the respective application.
The advantage of such a solution can be described briefly: You can concentrate almost exclusively on the actual problem without having to worry about what’s going on under the hood: The the only "administration" work required of the integrator is to assign the sensors and actuators to OPC variables. The rest of the task is the work of the actual functionality of the controlling or visualization system.
Such convenience does of course come at a price: On one hand the development tools are rather expensive solutions wherein costs for additional runtime licenses are generally incurred for the individual projects. On the other hand, becoming familiar with a professional visualization system is anything else but a trivial pursuit.Summary: OPC-based solutions represent the high road if you already have the software package to be used and you are familiar with using it or if you are considering frequent use of such a package in the future.
In this case the OPC route will provide the must usable solutions in the shortest possible time, though this is inherently restricted for the most part to the Windows world.
Do it yourself: Access via socket programming
If you do not use the OPC solution, processing the EnOcean protocol in any desired programming language yourself is no big deal.
The protocol is transmitted by the EnOcean Com-Server transparently from the network to the integrated TCM120 RF module, so that you can receive the RF telegrams over the network connection exactly as they are sent by the sensors. In the same way the telegrams need to be transmitted to the Com-Server just as you would send them directly to the transceiver module.
The EnOcean protocol is constructed comparatively simply and is documented in the manual for the TCM120 module which you can find on the Tools page for the EnOcean Com-Server.
A data telegram has a length of 14 bytes and begins with two constant Sync bytes (0xA5, 0x5a). The following bytes contain data and address information as well as several status bytes from which you can read the telegram type and data source. The end of the telegram consists of a checksum byte which is formed out of the sum of all user bytes (i.e. excluding Sync bytes) Modulo 256.
The following diagram shows an example for received telegrams which pressing and releasing a PTM100 button:
Send telegrams are constructed similarly to the receive telegrams in the above example. You only need to set the send/receive flag to 0x6B and be sure that the Address ID written into the structure originates from the address space of the integrated transceiver module.
Another alternative: The Windows COM Port Redirector
Everything we have said about access via socket programming applies here as well if you communicate with the EnOcean Com-Server using the W&T COM Port Redirector. The EnOcean Com-Server appears in this case like an additional virtual COM port in the system through which you can process the EnOcean protocol in the manner described above.
In conjunction with the TCM monitor you also have a diagnostic tool at your disposal which allows received EnOcean RF telegrams to be interpreted for content and allows telegrams to be sent with configurable content and provides for configuring the TCM120 transceiver module. The TCM monitor is a small but efficient software tool from EnOcean which is located on the serial port and work easily together with the combination "EnOcean Com-Server + COM Port Redirector".