2024.1

Configurable speed of push buttons

Additional settings have been added for all Push Buttons in TapHome devices, including touch devices and UI devices defined as push buttons (e.g., 32UI module).

Requirements: The latest firmware version of the module

Select one or more push buttons:

Service settings → Supported Click Types: The fewer options you select, the less time the algorithm will need to wait before executing the push button action. For example, if ‘Support Long Press,’ ‘Support Double Click,’ and ‘Support Tripple Click’ are all disabled, the push button action will be triggered as soon as the button is pressed, without waiting for it to be released.
Service settings → Longpress duration / Click speed. Adjust the duration required for longpress or double or tripple clicks.

Adding TapHome devices via QR code

The new TapHome devices have a sticker with a QR code that contains serial number information.

In Settings → Hardware → TapHome Bus, the Find new devices option has been added to the Add device option. This allows you to add only one specific module to the bus, without having to scan the entire bus and add all the newly connected modules at once.

Warning: the device must be connected to the bus at the time of scanning.

Spectrogram for the new Presence sensor and PBT2.0 touch buttons

Ability to analyze what is happening directly in the module on individual channels. It is possible to save and then play back the recording. Only available in the Windows application.

Open Presence module (forthcoming) or PBT module → Service settings → Run diagnostic

In the case of the Presence sensor, the individual levels of the radar wave reflection distance and the changes in the infra-red spectrum from the PIR sensor are displayed. It is illustrated over time whether the set threshold values are correct for a given room.

For PBT 2.0 touch buttons, it is possible to see the measured capacities in (almost) real time.

Packet parser improvements

Added support for Blinds

Simplify and speed up message processing in Packet Parser language

How it's better: it saves one PARSEJSON call to find out what the value of topic is. If there are very many mqtt messages coming in and only some are interesting, it is more convenient to use this.

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.

Original:

VAR jsonResponse := TOSTRING(RECEIVEDBYTES);
if parsejson(jsonResponse, "Topic") = "my-topic"
	Va := todouble(parsejson(jsonResponse, "Payload"));
end

New version:

if RECEIVEDMSG.TOPIC = "my-topic"
	Va := todouble(TOSTRING(RECEIVEDMSG.PAYLOAD));
end

Minor Packet Parser improvements

PARSEJSON, PARSEXML functions work more efficiently - require less RAM and CPU
Too many listener messages should no longer reduce the overall response time of the control unit.
The service information of packet parser modules contains statistical data on 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-topic. This should help when debugging scripts and setting the most appropriate topic filter to deliver as few messages as possible to Core that it does not process at all.

For more information about Packet Parser, see Compatibility list → Packet parser → Manual configuration