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,0,0<

#	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)
8	`rol`	`0` = slave, `1` = master (has a `peer` configured)
9	`enlace`	Link status when acting as master (table below)

Single-field query


>QBTH02<
>RBTH02,1<

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

Device-to-device link status (field 9)

Since v1.09.26 a device can actively connect to another one over BLE (CXBTH). Field 9 shows where that link stands:

Value	Status	What it means
`0`	Inactive	The device is a slave: no `peer` configured
`1`	Searching	Cannot find the remote device (powered off, out of range, or a different name)
`2`	Connecting	Found it, establishing the connection
`3`	Authenticating	Connected, sending the PIN
`4`	Linked	Link is up: reports sent to `;@BTH` travel to the other device
`5`	PIN rejected	The remote did not accept the PIN — check both share the same one


>QBTH09<
>RBTH09,4<        // linked

State 5 is not retried at the normal rate: after several failed attempts the device waits a minute between tries, so the PIN is not repeated over the air. Fixing the PIN with SCXBTH restores the link on its own.

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