BTH IoT Command — Bluetooth Connection Status

QBTH queries the device’s entire Bluetooth status in a single frame — the mirror of QCEL and QWIF for the third channel. In addition, the BTH signal (client connected) is available for event engine rules and EVAL expressions.

Available since firmware v1.09.26.

What is it for?

Use case	Description
🔗 Detect a connected gateway	Know whether a BT client is attached to the device (and since when it fails, with rules)
📶 Link diagnostics	Peer MAC and live RSSI of the connection
⚙️ Automate on connection	`TRG=BTH*` rules — fire actions when a client connects or leaves

Commands

Full query


>QBTH<
>RBTH,1,1,1,1,0,RINHO_IOT,AABBCCDDEEFF,-62<

#	Field	Meaning
0	`pwr`	Configured Bluetooth power (the switch, not the state)
1	`up`	The Bluetooth stack is running
2	`conn`	`1` = at least one client is connected
3	`nconn`	Number of active connections
4	`sesion`	`1` = there is an authenticated session (connection with login)
5	`nombre`	Bluetooth name of the device
6	`mac`	MAC of the last connected client (empty if no connection)
7	`rssi`	Live RSSI of the connection, in dBm (`0` without connection)

Single-field query


>QBTH02<
>RBTH02,1<

Index 00–07 (two digits), per the table above.

conn reflects the physical connection (GAP), whether or not there is an authenticated session. A gateway attached without logging in gives conn=1, sesion=0. pwr is the power configuration (CXBTH); up is the actual state of the stack.

The BTH signal (rules and EVAL)

BTH = 1 while there is a Bluetooth client connected. It is used just like any other device signal:


>QSSBTH<                          // → RSSBTH11 (connected) / RSSBTH00
>SRLA0E;TRG=BTH+;ACC={...}<       // rule: when a client connects
>SRLA1E;TRG=BTH-;ACC={...}<       // rule: on disconnection

In EVAL it is written BTH (no arguments). Do not confuse it with BTHPWR, which is only the power configuration.

In builds without Bluetooth the signal exists and always returns 0.

Compatibility

💾Firmware:v1.09.26

SP-IOT

SM-IOT

ZE-IOT