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

MQTT connection fail while "THREAD_RADIO_MODE_RX_OFF_WHEN_IDLE" - SED

Hi,

I use a pca10056 with the "mqttsn_sleepy_publisher" example. Unfortunately, I cant connect to the mqttsn gateway. It throws me:

"NRF_LOG_ERROR("CONNECT message could not be sent. Error: 0x%x\r\n", err_code);"

I use the standard code for the DK and the border router. I just formed my own thread network and adjusted the credentials (panid ...) within the DK. Connecting and transmitting with radio ON works fine. 

I have found that ticket. So I guess it might has something to do with those values:

#define DEFAULT_CHILD_TIMEOUT    40                                     /**< Thread child timeout [s]. */
#define DEFAULT_POLL_PERIOD      1000                                     /**< Thread Sleepy End Device polling period when MQTT-SN Asleep. [ms] */
#define SHORT_POLL_PERIOD        100                                      /**< Thread Sleepy End Device polling period when MQTT-SN Awake. [ms] */
#define SEARCH_GATEWAY_TIMEOUT   5                                          /**< MQTT-SN Gateway discovery procedure timeout in [s]. */                                   

Do you have any idea, whether those values need to change? I know what they should do, but changing them didnt help much. 

Ps: I use Linux, SDK17, VS-Code, pca10056

  • Sorry for the late answer. I am struggling a bit to understand where you are stuck, and what the issue is.



    <p>I am not familiar with this website. Have you tried to check openthread's own <a href="">openthread.io/.../a> or guides?</p>

    Maboo said:
    But the explanations on the RFC 3306 webside are too confusing for me.

    I am not familiar with this website. Have you tried to check out openthread's own documentation or guides?

    Maboo said:
    The problem why I ask is, as long as I use the standard values from nRF it would work I guess. But when I create my own network it automatically creates its own mesh local prefix (learned this last week).

    What works and what do you change, and what doesn't work after you change it? Is this something that I can reproduce using a couple of nRF52840 DKs?

    I guess you have stumbled upon this guide? If not, perhaps it will answer some of your questions?

    Best regards,

    Edvin

  • Hi Edvin,

    my goal is to form my own thread network and let several SED (Sleepy End Devices - rx-off-when-idle) communicate with the border router -> Homeassistant. That means the SED wakes up every 5 min and publishes a status update. Homeassistant subscribes to the SED topic and displays the new status.

    When I form my own thread network (you can do this on the local border router website). I can connect all the sensors as FTD (Full Thread Device - rx-on-when-idle) and the thread network works perfectly.

    When I flash them as an SED (rx-off-when-idle) I think I need to change "GatewayUDP6Broadcast" address in /etc/paho-mqtt-sn-gateway.conf. to fit the new MeshLocalPrefix (which was created by forming the network) [see below] Otherwise the SED won't find a gateway.

    wpan0 => [
    "NCP:State" => "associated"
    "Daemon:Enabled" => true
    "NCP:Version" => "OPENTHREAD/20191113-00534-gc6a258e3; NRF52840; Apr 5 2020 21:51:18"
    "Daemon:Version" => "0.08.00d (; Apr 21 2020 19:11:43)"
    "Config:NCP:DriverName" => "spinel"
    "NCP:HardwareAddress" => [F4CE36791D40C566]
    "NCP:Channel" => 11
    "Network:NodeType" => "leader"
    "Network:Name" => "OpenThreadDemo"
    "Network:XPANID" => 0x1111111122222222
    "Network:PANID" => 0xABCD
    "IPv6:LinkLocalAddress" => "fe80::1028:6768:6ee4:2727"
    "IPv6:MeshLocalAddress" => "fd11:1111:1122:0:3ab1:cb84:a673:bf93"
    "IPv6:MeshLocalPrefix" => "fd11:1111:1122::/64"
    "com.nestlabs.internal:Network:AllowingJoin" => false
    ]

    If I am using the statndard network parameters from nrf, the standard MeshLocalPrefix from nrf is: "fdde:ad00:beef::/64" and the standard GatewayUDP6Broadcast is "ff33:40:fdde:ad00:beef:0:0:1". As you can see, it somehow fits. And everthing works, even if I flash it as SED.

    But if I form my own network, my MeshLocalPrefix is "fd11:1111:1122::/64", so it doesn't fit to the GatewayUDP6Broadcast address anymore + the SED can't connect to the gateway. So now is the question, do I have to create a new fitting GatewayUDP6Broadcast or is there even more I have to change to get the SED connecting to the thread network?

    The answer from Carl Richard suggested I must change the address to match the network prefix.

    But how do i do it? And which address does he mean? GatewayUDP6Broadcast? Or am I wrong here?

    First, thank you for the extensive logs. The result you see in Test 2 is expected, as SEDs doesn't support multicast address "ff03::1". I reached out to a colleague about the issue with the other address. It seems like you may be using the wrong mesh-local prefix. The default (from wpan status) should be: 

    Fullscreen
    1
    "IPv6:MeshLocalPrefix" => "fdde:ad00:beef::/64"
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    but you have,
    Fullscreen
    1
    "IPv6:MeshLocalPrefix" => "fd11:1111:1122::/64"
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    You must change the address to match the network prefix.

    Ps: the openthread documentation doesn't help me here. Regarding SEDs it just refers to the RFC 3306 webside.

  • Hello,

    Sorry for the late reply. I have tried a couple of times to get a OTBR up and running but so far with no luck. 

    I believe that the MQTT-SN Gateway uses a realm-local all thread nodes multicast address. By default the "gatewayUDP6Broadcast" address is ff33:40:fdde:ad00:beef:0:0:1. This is a multicast address defined in Thread, so all Thread devices are reached with that particular mesh-local prefix (default fdde:ad00:beef). If you use another prefix address, you need to change that in the paho configuration to use your new prefix. 

    I see that it looks like you already changed this. But I can't see that it is used in the sniffer trace that you uploaded a screenshot of earlier (and I can't see that you uploaded the actual sniffer trace, but perhaps I just can't see it. Please correct me if I am wrong). 

    This is quite down the openthread specification rabbit hole. If I knew the answer I would tell you immediately, but I can try to figure it out together with you. You may want to open some communication in an openthread forum as well, as you may get help quicker there. 

    Best regards,

    Edvin

  • Hi Edvin,

    thanks a lot for your effort! So my current status: I tested the OTBR image from there website combined with the paho-mqtt-sn gateway and installed both on a RPi 4. There I played around a bit with the mesh local prefix and other parameters. Eventually I was able to send a gateway request from a pca10056 (flashed mqtt-sn-publisher example) by pressing the button.

    The result on gateway side was:

    pi@raspberrypi:/etc/paho.mqtt-sn.embedded-c/MQTTSNGateway/bin $ sudo ./MQTT-SNGateway 
    
     ***************************************************************************
     * MQTT-SN Gateway
     * Part of Project Paho in Eclipse
     * (https://github.com/eclipse/paho.mqtt-sn.embedded-c.git)
     *
     * Author : Tomoaki YAMAGUCHI
     * Version: 1.5.1
     ***************************************************************************
     ConfigFile  : ./gateway.conf
     ClientList  : /path/to/your_clients.conf
     Broker      : mqtt.eclipseprojects.io : 1883, 8883
     RootCApath  : (null)
     RootCAfile  : (null)
     CertKey     : (null)
     PrivateKey  : (null)
     SensorN/W   : Multicast Address: [ff33:40:fdde:ad00:beef:0:0:1]:1883, Gateway Port:47193, Interface: wpan0, Hops:1
     Max Clients : 30
    
    20211202 092716.374 PahoGateway-01 starts running.
    
    
    20211202 092719.544   SEARCHGW          <---  Client                              03 01 01
    20211202 092719.545   GWINFO            --->  Clients    

    The Result on DK side via JLinkLogger was:

    SEGGER J-Link V7.50 - Real time terminal output
    J-Link OB-SAM3U128-V2-NordicSemi compiled Feb  2 2021 16:47:20 V1.0, SN=683835218
    Process: JLinkExe
    <info> app_timer: RTC: initialized.
    <info> app: Thread version   : OPENTHREAD/20191113-00534-gc6a258e3; NRF52840; Apr  5 2020 21:51:18
    <info> app: Network name     : NordicOpenThread
    <info> app: Thread interface has been enabled.
    <info> app: 802.15.4 Channel : 11
    <info> app: 802.15.4 PAN ID  : 0xABCD
    <info> app: Radio mode       : rx-on-when-idle
    <warning> app_timer: RTC instance already initialized.
    <info> app: State changed! Flags: 0x011FD33D Current role: 1
    
    <info> app: State changed<info> app: State changed! Flags: 0x00000064 Current role: 3
    
    <info> app: MQTT-SN event: Gateway discovery procedure has finished.
    
    <info> app: MQTT-SN event: Gateway discovery result: 0x3.

    0x3 means, it couldn't find an active gateway. 0x0 should have been the answer. I still think I mix stuff up regarding all the addresses.

    So just to make it clear to myself: If I have a different mesh local prefix and I want to change the old one. I just have to change the old one inside the paho gateway config:

    • new mesh local prefix e.g.: "fd11:1111:1122::/64"
    • results in "gatewayUDP6Broadcast" address ff33:40:fd11:1111:1122:0:0:1 ??

    The sniffer results are quite old. I haven't used the standard mesh local prefix there. But I can create new ones.

    Good idea, I will ask the question in an openthread forum as well.

    Best regards,

    maboo

Related