This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to identify dulicate messages

I have a problem collating model publish events arriving at two different nodes in my mesh.

My application is an array of sensors publishing through generic on off and generic level models. Two (or more) nodes in my mesh are “gateways” that report model events from the mesh to an observer computer via UDP over ethernet. Here is my architecture in ASCII art.

Sensor 1 <------------> Gateway 1    ===wired==
(unicast 0x0010)        (unicast 0x0030) |
    ^    \       /               |
    |     --------\ /                         v
    |              /     Observer computer
    |     ---------/ \                         ^
    V    /       \               |
Sensor 2 <------------> Gateway 2    ===wired===
(unicast 0x0020)        (unicast 0x0040)

So, a sensor reading on Sensor 1 is published as an event. It is published to a group address subscribed to by both Gateway 1 and Gateway 2. Each receives the event and reports it back to the observer computer. How does the observer computer recognize the two messages as relating to the same event?

Using nRF SDK for Mesh 3.1.0, I wrote this client event handler for the level status event:

static void app_gen_level_client_status_cb(
    const generic_level_client_t * p_self,
    const access_message_rx_meta_t * p_meta,
    const generic_level_status_params_t * p_in) {

    // my function for reporting the event via UDP
    tx_model_event(
        p_meta->src.value,
        p_in->present_level,
        p_meta->p_core_metadata->params.scanner.timestamp);
}

However, I did not get the results I expected. The UDP messages arrived from both gateways, but had different timestamps on them. I dug around a bit and found that the timestamp part of the metadata is applied in the *receiver* (i.e. independently by each gateway) in scanner.c in the function radio_handle_end_event().

I’ve poked around in the debugger and cannot find any sequence number, token or ID that identifies the event message. I guess there *must* be some way that the mesh avoids delivering the message twice to a node through two routes (e.g. Sensor 1 -> Gateway 1, Sensor 1 -> Sensor 2 -> Gateway 1).

How do I uniquely identify a message from e.g. Sensor 1 so that the observer computer doesn't process it twice when it arrives from different gateways?

Can anyone help me?

Parents
  • Hi Hugh, 

    In theory this issue can be solved by the TID (transaction ID) that should be unique for each message. However it's not included in the Generic On Off Status message definition. I can see in our code that we have the generic_onoff_state_t struct that contain the on_off status and the transaction ID. But we haven't used it.

     
    I would need to double check with the Mesh team to see if there is anything defined in the spec about this. 

    Otherwise you would need to send it as a proprietary access packet. Or create your own model for the purpose. 

Reply
  • Hi Hugh, 

    In theory this issue can be solved by the TID (transaction ID) that should be unique for each message. However it's not included in the Generic On Off Status message definition. I can see in our code that we have the generic_onoff_state_t struct that contain the on_off status and the transaction ID. But we haven't used it.

     
    I would need to double check with the Mesh team to see if there is anything defined in the spec about this. 

    Otherwise you would need to send it as a proprietary access packet. Or create your own model for the purpose. 

Children
No Data
Related