Manual configuration

Implementation in TapHome

In TapHome, the Packet Parser is a hardware interface (Settings → Hardware → Add new interface → Packet parser) that is used to connect third-party devices to the controller. These devices can communicate with the control unit using either WiFi or LAN via TCP/IP protocol.

The Packet Parser uses a proprietary scripting language that is specifically designed for the TapHome system. This language is used to control and manage the connected devices and their communication with the controller. Click here for more information on the TapHome scripting language

Hierarchy

TapHome system uses a hierarchical structure for organizing the connected devices. In this structure, a Module acts as a parent device and can communicate with and control its child devices.

Module

An interface can contain one or more modules, which in most cases cover communication with the entire physical device. From a configuration point of view, the Module defines:

• IP address or mDNS name of a device
• Communication port
• Secure connection: See section Authentication in Service settings of a Module
• Ignore SSL certificate errors

Device

Represents a specific control element or sensor in the TapHome system. It must always be part of one parent Module.

Supported devices:

• Digital output
• Analog output
• Thermostat
• Multi-Value Switch
• Temperature sensor
• Variable
• Push button
• Electric meter
• Reed Contact
• Shutters, awnings, mix valves
• RGB Light
• Tunable white light

Scripts for reading and writing

TapHome control unit and the connected devices can communicate using HTTP or HTTPS GET / POST requests. The responses to these requests can be parsed using a set of specialized functions. For example, there may be a function that is specifically designed to parse XML responses, another function for parsing JSON responses, and yet another function for parsing byte array responses. These functions make it easier to interpret and use the information received in the responses, allowing for more efficient and effective communication with the control unit and connected devices.

TapHome defines multiple attributes that can contain script language:

• Initialize script: is run when the device starts (e.g. after the control unit is restarted)
• Read script: setting values of global variables or reading error states
• Read Value script: script for reading a specific value (quantity) from a connected device (e.g. set temperature on the thermostat or measured temperature on the thermostat)
• Write Value script: write the value to the connected device
• Listener script: is executed when each packet is received. More info in a separate section below

Supported protocols

• HTTP

• TCP

• UDP

• FTP

• MQTT

HTTP

SENDHTTPREQUEST

Sends HTTP request with specified parameters, waits for response and returns response as JSON string with values as Content, Headers, HTTP result code. Function is supported only in Packet parser scripts with HTTP protocol.

SENDHTTPREQUEST( path, method, body, header1, header2… )
SENDHTTPREQUEST( HttpRequest )

Examples:

SENDHTTPREQUEST("/getValue")		Result is:
{
  "Headers": [
    {
      "Key": "Content-Type", “Value": [“application/json"]
    },
    {
      "Key": "Content-Length", “Value": ["1007"]
    },
  ],
  "Content": "{\"value\":31}”,
  "ReasonPhrase": "OK",
  "StatusCode": 200,
  "IsSuccess": true
}

SENDHTTPREQUEST("/doSomething", “POST”, “someData”, “header1:value1”, “header2:value2”, “header3:value3”)

VAR request := HTTPREQUEST(“/path”, “PUT”, “someData”);
request.Headers := { “name1: value1”, “name2: value2” … };
request.Method := “POST”;
VAR response := SENDHTTPREQUEST(request);
 
IF response.IsSuccess
	VAR content := response.Content;
	…
END

TCP, UDP

SENDDATA

Sends specified data (string or Collection UInt8) using TCP or UDP protocol. If data is a string object, it’s implicitly converted to bytes using iso-8859-1 encoding. Function is supported only in Packet parser scripts with TCP or UDP protocol. Received bytes can be processed in Listener script.

SENDDATA( string/Collection<UInt8> )

Examples:

SENDATA(BYTECOLLECTION(“0a dd ef a2”)
SENDATA(“{\”value\”:212}”)

COMPLETESERVICEATTRIBUTE

Function is used in Listener scripts in Packet parser with TCP/UDP protocol, to notify completion of Service attribute value request. Eg. you create a request in Service attribute script using the SENDDATA function and after receiving the data in listener script, you complete the service attribute read.

COMPLETESERVICEATTRIBUTE( attributeName, value, error )

Examples:

COMPLETESERVICEATTRIBUTE(“Uptime”, “2d:21h:43m”)
COMPLETESERVICEATTRIBUTE(“Status”, “”, “Device is offline”)

COMPLETESERVICEACTION

Function is used in Listener scripts in Packet parser with TCP/UDP protocol, to notify completion of Service action request.
Eg. you create a request in Service action script using the SENDDATA function and after receiving the data in Listener script, you complete the Service action.

COMPLETESERVICEACTION( actionName, result )

Examples:

COMPLETESERVICEACTION(“Reboot”, “Rebooted successfully”)
COMPLETESERVICEACTION(“Enable cloud”, “Device is offline”)

FTP

FTPDOWNLOAD

Returns the file data (as Collection UInt8) from the FTP server. The function is only supported in Packet parser scripts with FTP protocol.

FTPDOWNLOAD( pathToFile )

Examples:

FTPDOWNLOAD(“/path/to/file”) 		(Result is Collection<UInt8>)

FTPUPLOAD

Uploads data (Collection UInt8 or string) to a file to FTP server.

FTPUPLOAD( pathToFile, data, mode )

Examples:

FTPUPLOAD(“/path/to/file”, “some data”, “write”)
FTPUPLOAD(“/path/to/file”, BYTECOLLECTION(“a7 ff e2”), “append”)

MQTT

In addition to the communication options mentioned above, the TapHome system also allows for communication with third-party devices using the MQTT protocol. MQTT, or Message Queuing Telemetry Transport, is a lightweight publish/subscribe messaging protocol that is designed for efficient and reliable communication between devices in machine-to-machine (M2M) and Internet of Things (IoT) contexts.

To enable communication with third-party devices using MQTT, it is necessary to create a separate module in Settings → Hardware → Add new interface → MQTT Broker. This module acts as an intermediary between the third-party devices and the control unit, allowing them to communicate using the MQTT protocol. The MQTT Broker can be run autonomously on the control unit, allowing for independent and efficient communication between the third-party devices and the TapHome system.

MQTTPUBLISH

The function is used on PacketParser devices with the MQTT protocol to publish a message to the MQTT broker.

MQTTPUBLISH( topic, message )

Examples:

MQTTPUBLISH(“shellies/deviceid/relay/0/command”, “off”)

Listener script

The listener script is invoked when each packet is received, specifically for MQTT the listener script is invoked when any message arrives via MQTT whose Topic matches the Topic-filter set in TapHome;; there can be hundreds of these messages per minute. Two things are important to mention here:

• The Topic filter needs to be set as restrictive as possible, so that messages with a different Topic value do not arrive at all and thus do not activate the listener script. For example, if we are only interested in topic a.b.c.d, the filter should be a.b.c.d, not just a.b.
• Some devices produce many different messages that have the same topic, or sometimes we have to set the topic e.g. to a.b because we are interested in messages a.b.c.d but also a.b.x.y, which of course will cause messages with topic a.b.k.l.m that we are not interested in to arrive as well. This is not bad in principle, but some devices generate various status updates or messages that contain field descriptions of other messages (metadata), and these can be hundreds of KB long and arrive relatively frequently - every few seconds (e.g., Zigbee2MQTT).

Because of the reasons mentioned above, in MQTT, in a listener script, it is very important to decide based on the Topic value whether it is a relevant message and if not, to stop the script execution immediately and not to analyze the message content unnecessarily at that time. The algorithm in the TapHome controller contains mechanisms to prevent MQTT from being overwhelmed by messages. Nevertheless, it cannot be ruled out that a very loosely set MQTT topic filter and a large number of large messages will not cause an increase in the response time of the controller.

The received packet is located in the variable (structure) RECEIVEDMSG. The received data can be read in the variable RECEIVEDMSG.Payload. Payload has the data type BLOB (large binary object), it is not a string or an array of bytes. If the payload is of type string, the TOSTRING function must be used, but in general the payload can be anything. RECEIVEDMSG also contains protocol-specific data, e.g. RECEIVEDMSG.Topic for MQTT. Using RECEIVEDMSG.TOPIC is a very fast and efficient way to find out the topic value, unlike the old way when RECEIVEDBYTES was used.

Improvements in version 2024.1

Instead of:

VAR jsonResponse := TOSTRING(RECEIVEDBYTES);

if parsejson(jsonResponse, "Topic") = "my-topic"

	Va := todouble(parsejson(jsonResponse, "Payload"));

end

it can be written like this:

if RECEIVEDMSG.TOPIC = "my-topic"

	Va := todouble(TOSTRING(RECEIVEDMSG.PAYLOAD));

end

How is this better - it saves one call to PARSEJSON to find out what the value of the topic is. If there are a lot of mqtt messages coming in and only some of them are interesting, it is more convenient to use this new method.

RECEIVEDMSG further contains mqtt specific values - e.g. CLIENTID, DUP, CONTENTTYPE, EXPIRY - their content depends on what the mqtt server is sending. The old syntax still works and will work.

RECEIVEDMSG also works with TCP and UDP, not just MQTT. In that case, it only provides the PAYLOAD and LENGTH properties.

Packet analysis

The information in the Service Settings of Packet Parser modules contains statistical data about received and sent messages - counts for the last 5 and 30 minutes, the number of received bytes, and for MQTT, the information is sorted by MQTT topics. This should help in debugging scripts and setting the most suitable topic filter to ensure that as few messages as possible that are not processed by Core are delivered.