Michael Mitchell

Forum Replies Created

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • April 11, 2019 at 11:22 pm in reply to: OTAA sessions and Conduit restart #27618
    Michael Mitchell
    Participant

    Not sure if this is your issue, but if you are not using a static whitelist, and you are doing device add operations, you need to run database backup after adding the devices, or they may not be in the database when it restarts.

    If you do this, you should not have to rejoin when the Conduit restarts.

    March 29, 2019 at 4:42 pm in reply to: Messages blocked in queue for ever #27573
    Michael Mitchell
    Participant

    @Jason, YEA! That helped on both fronts. Now I don’t have to flash all my nodes. Thanks!

    March 29, 2019 at 11:57 am in reply to: Messages blocked in queue for ever #27566
    Michael Mitchell
    Participant

    I am also having a problem with class C devices. My custom devices worked fine with mLinux with 3.3.6, but fail with 4.1.6. Here is what I found:

    1. The device was sending an empty unconfirmed packet after joining, but it was not working correctly to get the mac ADR response. It looks like a race condition, when I delayed the sending slightly, it started working.

    2. Even when added as Class C, after rejoining and sending the empty packet, “device stats” reports class A. If I then issue “device update XXX class C”, the server will send packets immediately.

    So I have two questions:
    1. Is there a way to change the servers behavior so that I do not have to re-flash all my devices?
    2. Why do we have to issue a device update for a device that was added as Class C?

  • Author
    Posts
Viewing 3 posts - 1 through 3 (of 3 total)