Tuya Developer Forum

proxy to mesh failed error when device is in mesh state : 6 . Device has been added to the group for the first time and mesh commands are sent from the smartlife app . Mesh proxy error occurs and the device is unable to forward data to the mesh group .

According to your log information, the issue of “proxy fail” is due to the APP controlling too quickly. The proxy node is responsible for converting GATT data into ADV data for transmission, and the rate of GATT is much higher than that of mesh ADV. If control commands are sent too quickly, it will cause the fifo within the proxy node to be insufficient, leading to the loss of data exceeding the fifo, which will output the log “proxy to mesh failed”.

This problem is limited by the characteristics of the mesh proxy node and the size of the proxy fifo in the chip SDK. It is recommended to reduce the control speed according to the actual application scenario. If the application scenario indeed requires such a high rate of operation, then we need to discuss other special optimization methods.

Hi

Can we increase the size of proxy fifo . let me know the parameters to change so that to this error does not occur or adjust other parameters to prevent the error as it causes the mesh devices not to receive data due to proxy failure.

percy(unwired) 2024年 Apr 16日 21:27

Hi

Can we increase the size of proxy fifo . let me know the parameters to change so that to this error does not occur or adjust other parameters to prevent the error as it causes the mesh devices not to receive data due to proxy failure.

We consulted with the chip manufacturer, and they do not recommend increasing the size of the FIFO. With the characteristics of the Proxy scheme, a larger FIFO could potentially cause data latency. For example, if there is rapid and substantial control from a mobile app, and then the control stops, the state of the device continues to change (because the control data in the FIFO is still queued for sending).

We have compared the Proxy schemes of several manufacturers, and most of them use a smaller Proxy FIFO to maintain the real-time nature of the data.

Additionally, according to the log screenshot you provided, a large number of color temperature control commands were sent after creating a group. Even if the FIFO is increased, if test data is sent rapidly for a long time, the Proxy FIFO may still be filled up, leading to a Proxy error (we can actually call this Proxy busy).

in that case is there a way in which we can reduce the rate at which the proxy device receives the commands or forwards the data to the mesh or group so that the error is not generated .

also whats is the best time parameter setting for :

1) DEFAULT_ADV_PARAMS(30, 60)

2) DEFAULT_SCAN_PARAMS(30, 30)

i find that decreasing the scan time parameters increases the rate at which commands are received by the device . this also reduces the number of commands lost due fast sending of data by app . Reducing the scan time parameter also helps reduce the proxy to mesh failure error messages .

The scanning behavior of mesh devices is implemented in the original SDK of the chip manufacturer. Devices that are not low-power will maintain a 100% scanning window in addition to sending packets to ensure the success rate of packet reception and reduce the probability of packet loss. This scanning behavior is in the library, and we do not have an interface that can be modified. Where did you get this interface for modification?

in file tal_bluetooth_def.h

the following macro is defined

#define TUYAOS_BLE_DEFAULT_SCAN_PARAM ((TAL_BLE_SCAN_PARAMS_T *) (&(TAL_BLE_SCAN_PARAMS_T) DEFAULT_SCAN_PARAMS(10, 10))) changing the default scan parameters here affects the rate at which data is received .

with the default parameters the device and the mesh group missed commands from the app and remote even if the commands were sent once every second . the commands would be received at a slow rate causing incorrect operation .

With the scan parameters set to DEFAULT_SCAN_PARAMS(10, 10))) the following changed were observed

1) The rate at which commands were received by the device increased . confirmed the same using serial output logs .

2) Reduced the loss of commands received from the app and remote switch under normal working no fast commands sent . fast sending of commands used only for checking recurrence of issue .

3) Reduced the delay between commands received from app / remote switch and processed by the sdk .

4) Reduced instances of command losses in the mesh group .

5) Reduced occurrences of mesh proxy failure error message .

Currently facing the following issues

1) Even after the above changes the mesh group still losses commands sent from the proxy device / switch /gateway the instances of the same have reduced .

2) All devices in the mesh group do not receive commands at the same time a brief delay is observed . This causes devices in the mesh to function out of sync . example : led drivers in mesh group . the brightness change command is not received by the devices at the same time causing devices in the mesh to be at different levels of brightness .

How can we sync all devices in mesh to receive and execute data at the same time in sync .

How can we reduce the instances of command lost in the mesh .

3) Only the proxy device reacts to the commands sent from app commands are not forwarded to the mesh group .

You mentioned earlier that the macro definition (#define TUYAOS_BLE_DEFAULT_SCAN_PARAM ) for changing scan parameters has not been adapted in the mesh SDK, so the configuration here is invalid. The reason has been replied to you before, the scan parameters of the mesh are implemented in the original factory SDK, so the test you did here is not meaningful.

As for the problems you have left now, the first one is the probability of packet loss in fast group control devices. If most devices are successful and only a few devices lose packets, it can be determined that packets are lost during device scanning. There are multiple reasons for scanning packet loss, such as RF signals being interfered with or blocked on the hardware, or timers or other peripherals occupying interrupts for a high frequency and long time in the program, causing the Bluetooth interrupt to be unable to enter (the tlsr825x series chip does not support interrupt nesting and interrupt priority configuration). It is recommended that you check from these directions. In addition, the mesh protocol is through flood communication, by a large number of retransmissions to improve the success rate of communication, you can try to modify the mesh network transmit and relay retransmit parameters to increase the number of retransmissions to improve the success rate. You can use the following functions:

/**
 * @brief   Set the network layer retransmit parameters.
 * @param   [in] cnt  transmit cnt = (cnt + 1) times
 * @param   [in] step  retransmission interval = (net_trans_steps + 1) * 10ms
 * @return  NULL
 * */
VOID tkl_mesh_network_transmit_set(UCHAR_T cnt, UCHAR_T step);

/**
 * @brief   Set the network layer relay retransmit parameters.
 * @param   [in] cnt  transmit cnt = (cnt + 1) times
 * @param   [in] step  retransmission interval = (net_trans_steps + 1) * 10ms
 * @return  NULL
 * */
VOID tkl_mesh_network_relay_retransmit_set(UCHAR_T cnt, UCHAR_T step);

The second problem is the brief unsynchronization of the device. Based on your description, I cannot determine the actual phenomenon. According to my analysis, it may be a synchronization problem between the proxy node and other nodes. That is, the proxy node controls the effect faster than other points. This is because the mobile phone sends data to the proxy node through gatt, and the proxy converts the data into adv and sends it out, so the processing of the proxy node must be faster, but this time is only a few hundred ms. If you use gateway communication, the gateway directly sends adv, there will be no proxy process, and there will be no problem that a certain node responds faster.

The third problem, only the proxy node can control the problem, has been explained in the previous reply, in the fast control with a large amount of data will cause the proxy fifo to be full, resulting in the inability to reduce some data sent out. This test method may be rare in actual application scenarios. If we adapt to this scenario, it may cause other problems when actually used.

Hi

As per our suggestion i have gone and increased the relay and retransmit functions parameters as follows :

VOID tal_mesh_state_callback(TAL_MESH_NET_STATE_T state)
{

case TAL_MESH_GROUP_SUB_ADD:
{

       
         tkl_mesh_network_transmit_set(10, 5); 
      
         
      
         tkl_mesh_network_relay_retransmit_set(8,10);
         
   
   
        
          }

break;
default:
break;
}

after these changes the mesh proxy error no longer appears however command loss is observed in the proxy mode . Also the issue with devices not being in sync occurs . Would you suggest further increasing the retransmission count of these functions .

Checked with gateway device the issue with command loss is not observed in the mesh group . also the devices work in sync .

How do we fix the issues with the proxy connection . Any parameters or functions that would help fix the proxy connection issues .

There are some issues with the parameter settings in your code. The maximum value for transmit cnt is 7, and the maximum value for step is 31.

I suggest you try:

    tkl_mesh_network_transmit_set(7, 0);
    tkl_mesh_network_relay_retransmit_set(4, 0);

By increasing the number of transmissions and reducing the transmission time, the data in the proxy fifo can be sent out quickly.