• State Verified Answer
  • Replies 11 replies
  • Subscribers 63 subscribers
  • Views 316 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 324647
Options

Matter - fastest time from power up to first detected Event?

AMarch

We have implemented a simple contact switch using the nrf52840 and the latest zip generator (v99). The device connects to a Samsung Smart things edge router. A contact device shows up in the application and pressing button 2 makes the device close on the screen. I was able to script closures into turning on lamps. So that appears "functional".

What I was hoping I could find information about is the length of time a device needs to contact the router and be detected, from a power off state. 
Some testing has shown it can take a very long time. The test is generally holing the switch down and powering on the device. The power profiler shows what appears to be continuous transmission of the button state, however the application can take a minute to finally detect it.

Is there a known set of configuration values that allow the device to inform the edge router that it is not just intermittent but when it does come on it needs to be configured ASAP? 

I am very sorry that I do not know the proper MATTER/Thread terminology here.

Does the 32Khz crystal allow the device to be detected faster? 

Parents
  • 0

    Hi,

    What I was hoping I could find information about is the length of time a device needs to contact the router and be detected, from a power off state. 

    If the device is in a power-off state, Thread must be enabled before it can reconnect to the network. In that case, you can use the Thread state as explained in  Matter/Thread event indicating "ready to update status" and "status confirmed updated" ? .

    Is there a known set of configuration values that allow the device to inform the edge router that it is not just intermittent but when it does come on it needs to be configured ASAP? 

    Can you explain what you mean by configured?

    I am not sure I understand the end goal. If you want the device to be low-power but also be able to quickly send a message upon an event, I recommend using Sleepy End Device (SED) or Synchronized Sleepy End Device (SSED) instead of power-off. You can read more about this here: Reducing power consumption in Matter.

    Best regards,
    Marte

  • 0 in reply to Marte Myrvold
    Marte Myrvold said:
    Is there a known set of configuration values that allow the device to inform the edge router that it is not just intermittent but when it does come on it needs to be configured ASAP? 

    Can you explain what you mean by configured?

    What I want is to inform the hosting system that a device should be assumed present, even if it hasn't communicated lately. 

    Thanks for re-pointing me to the SED /SSED page, from my cursory look at the "differences in the 2.6.0" document I made an assumption that SED/SSED terminology is replaced with ICD. But that is only for Matter portions of the documentation and firmware. 

    Anyways, the end goal is to have a device that is not only in low power mode but essentially off. The device will power on and transmit its current state and then power off, pretty typical. From the "Reducing power consumption in Matter" page it appears that I want to implement a long idle time device. Unfortunately, this is documented as provisional, and I guess...not supported.

    When the device powers on, I imagine it needs to handshake with the edge router/host to validate it exists. Perhaps I am wrong in this assumption. Perhaps just starting to send messages should give the host system (again a Samsung Smart things hub) all the required information about the devices presence. Unfortunately, what happens it the device floods output with the closed switch state and the application monitoring the Smartthings hub doesn't show a closed switch, for several seconds. 

    Let me make some more modifications and come back to this, 

    Your link back to my previous response needs amended a little, since in 2.6 the event handling is in  \v2.6.0\nrf\samples\matter\common\src\board\board.cpp . 

    A M

  • 0 in reply to AMarch

    Hi,

    I will continue to help with this ticket.
    I hope to give some answer to your previous reply tomorrow

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Sigurd Hellesvik
    AMarch said:
    the end goal is to have a device that is not only in low power mode but essentially off.

    For a sanity check here: What is your expected "sleep times"  here?
    What you describe is only power-efficient if you sleep long enough. Since powering on and off uses a lot more current than toggling low power modes, it is only recommended for sufficiently long off-periods

  • 0 in reply to Sigurd Hellesvik

    Ok, a long delay here while I circle around to this project again. It looks like we could be sleeping for up to an hour. 

  • 0 in reply to AMarch

    Hi,

    You will not gain much from powering the device off completely compared to being in idle mode when it is off or sleeping for just an hour. Reconnecting to the networks and re-establishing all Matter CASE sessions after reboot consumes a lot of power compared to simply waking up from sleep.

    If the device is supposed to be activated on button press, the latency will also be relatively high. It might require several seconds, or even a minute if the device needs to reattach to a different Thread parent, before the device is ready to transmit, which will significantly impact the user experience.

    The best option is to use SED/SSED and long idle time (LIT). As you mentioned, LIT is not currently fully supported, but it will be supported in a later version of the nRF Connect SDK.

    Best regards,
    Marte

  • 0 in reply to Marte Myrvold

    In our case power off isn't so much a power saving mode as a general power up condition. Like something being charged by a solar cell. Sometimes it will have power, sometimes it will come online after gaining power and MUST report its current status as soon as possible.

Reply Children
Related