To support my recent replacement of mailbox delivery notification mechanism a means to use serial communication with mcsMQTT was introduced in version 5.5.0.0. http://mcsSprinklers.com/mcsMQTT_5_5_0_0.zip for HS3/HS4 and http://mcsSprinklers.com/HSPI_mcsMQTT_5_5_0_0.zip for native HS4.
Serial messages are managed as MQTT messages with the topic “Serial/xxx” where xxx is the port address that was setup. Other features of mcsMQTT such as JSON decoding, Regular Expressions, History retention, Charting, etc are available for the serial messages. This should allow convenient use of serial devices without too much additional work by the user.
Serial communication is normally provided via a bidirectional set of wires using a Universal Asychronous Receiver Transmitter (UART) that is contained within the computer or provided by a USB to Serial adapter. The technology to perform serial communication over Ethernet provides a similar capability but is not as ubiquitous as the UART. mcsMQTT supports both of these mechanisms.
The setup is done on the TCP page, Serial tab as shown below. In this example the first row identifies a serial connection to a Lantronix IP/Serial device. The IP/Serial device baud rate needs to be setup manually as no provisions exists to communicate meta data over the Ethernet link.
The second row identifies port 1 at 4800 baud. The other serial parameters are set to No Parity, eight bits, one stop bit (N,8,1). Port 1 will be COM1 for Windows or /dev/ttyUSB1 for Linux. In the Linux case mcsMQTT will search for other /dev/ttyUSB ports if USB1 is not available. Linux switches ports, especially when error conditions are detected so mcsMQTT tries to be tolerant of this. If multiple serial ports are in use then this could be problematic on Linux.
The serial data received is treated as a MQTT payload. The payload is the data that is received between End Of Line characters. This defaults to the Line Feed (LF)/Chr(10) byte. It can be change in the setup for each serial port. If this field is left blank then a message end is defined as three second pause in the reception of serial data.
Provisions have also been made on the transmit side to limit the rate of message transmission. This is not normally needed, but if a limited link budget exists then it could be useful.
Data is transmitted via the DeviceString of the HS device that was created for each serial port such as shown below. Three controls are provided. The Submit button will send the DeviceString to the serial port. The Close and Open buttons will close and open the serial port. If strings are going to be sent through other mechanisms the CAPI is used to interface with mcsMQTT.
Serial messages are managed as MQTT messages with the topic “Serial/xxx” where xxx is the port address that was setup. Other features of mcsMQTT such as JSON decoding, Regular Expressions, History retention, Charting, etc are available for the serial messages. This should allow convenient use of serial devices without too much additional work by the user.
Serial communication is normally provided via a bidirectional set of wires using a Universal Asychronous Receiver Transmitter (UART) that is contained within the computer or provided by a USB to Serial adapter. The technology to perform serial communication over Ethernet provides a similar capability but is not as ubiquitous as the UART. mcsMQTT supports both of these mechanisms.
The setup is done on the TCP page, Serial tab as shown below. In this example the first row identifies a serial connection to a Lantronix IP/Serial device. The IP/Serial device baud rate needs to be setup manually as no provisions exists to communicate meta data over the Ethernet link.
The second row identifies port 1 at 4800 baud. The other serial parameters are set to No Parity, eight bits, one stop bit (N,8,1). Port 1 will be COM1 for Windows or /dev/ttyUSB1 for Linux. In the Linux case mcsMQTT will search for other /dev/ttyUSB ports if USB1 is not available. Linux switches ports, especially when error conditions are detected so mcsMQTT tries to be tolerant of this. If multiple serial ports are in use then this could be problematic on Linux.
The serial data received is treated as a MQTT payload. The payload is the data that is received between End Of Line characters. This defaults to the Line Feed (LF)/Chr(10) byte. It can be change in the setup for each serial port. If this field is left blank then a message end is defined as three second pause in the reception of serial data.
Provisions have also been made on the transmit side to limit the rate of message transmission. This is not normally needed, but if a limited link budget exists then it could be useful.
Data is transmitted via the DeviceString of the HS device that was created for each serial port such as shown below. Three controls are provided. The Submit button will send the DeviceString to the serial port. The Close and Open buttons will close and open the serial port. If strings are going to be sent through other mechanisms the CAPI is used to interface with mcsMQTT.
Comment