IO_Ports

Since version 0.0.1.26, IO Ports support has been introduced. Support for serial port is introduced in 0.0.1.28.

• Configuration
• Conditions
• Actions
• Example

Configuration

The configuration of io ports is located in the services section. Each IO port has an identifier that can be used in conditions and actions to send and receive data over it.
Here's an example of ioports configuration:

<ioports>
    <ioport id="irtrans" host="192.168.0.18" port="21000" rxport="21001" />
    <ioport id="test-tcpcli" type="tcp" host="127.0.0.1" port="1030" />
    <ioport id="test-serial" type="serial" dev="/dev/ttyS0" speed="9600" framing="8E1" />
</ioports>

The supported parameters are:

• id : The IO port identifier (mandatory) used by conditions and actions
• type : The port type can be udp or tcp. Default=udp

The other parameters are type-dependent.
For port type udp:

• host : The destination used for sending udp data (optional, only needed for sending)
• port : The destination port used for sending udp data (optional, only needed for sending)
• rxport : The local port used to listen for incoming udp data (optional, only needed for reception)

For port type tcp:

• host : The destination used for sending udp data (optional, only needed for sending)
• port : The destination port used for sending udp data (optional, only needed for sending)
• permanent : If "true", the connection will be kept open after sending data. If some conditions are configured, the connection is always kept open.

For port type serial:

• dev : The serial port device (e.g.: /dev/ttyS0)
• speed : Baudrate (200, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200 or 23400)
• framing : 3 characters (nb of data bits, parity and nb of stop bits; Default: "8N1" ) describing the framin settings. Nb of data bits range from 5 to 8 included. Parity is E (even), O (odd) or N (none). Nb of stop bits is 1 or 2.
• flow : Flow control setting (none, xon-xoff or rts-cts; Default: none).

For the moment, the TCP io port can only connect as a client to external TCP servers. It's not possible for linknx to be the server allowing TCP clients to connect to it.
The message delimitation is also not implemented, so the received data is transferred to conditions chunk-by-chunk as it is received. This can make a difference in case of big messages if they are fragmented in smaller parts. In future release, the massage delimitation (based on delimiter characters or timeouts) will be added.

Conditions

The following attributes can be used for ioport-conditions.

• ioport : the name (id) of the ioport the condition listens to
• expected : the value to compare with. Please take note of the remark in the Example below.

Actions

These are the attributes for action type="ioport-tx".

• ioport : the name (id) of the ioport to send data to
• data : the data to send
• hex : If "true", the data is sent as hexadecimal (default is "false").

Example

Here's an example of rule that receives a message corresponding to an IR code from IRtrans infrared receiver/transmitter and send a sequence of ir commands to another device (use the red teletext button to power-on dvd player and play a dvd):

        <rule id="start-dvd">
            <condition type="ioport-rx" expected="samsung,red" ioport="irtrans" trigger="true"/>
            <actionlist>
                <action type="ioport-tx" ioport="irtrans" data="snd dvd,power" />
                <action type="ioport-tx" ioport="irtrans" data="snd dvd,menu" delay="5"/>
                <action type="ioport-tx" ioport="irtrans" data="snd dvd,enter" delay="7"/>
            </actionlist>
        </rule>

There is currently a limitation on ioport-rx conditions. Any message received and starting with the value of parameter expected will trigger the condition. So in this case if the irtrans could send a message like "samsung,redisplay", it would also trigger the rule.