Messages blocked in queue for ever

[thierry.brincourt@free.fr]

Hello,

I have a serious problem with a MTCAP-868-001A (Firmware 1.7.2).

The gateway is just unable to send downlinks to class-C devices. The messages are just stuck in th queue for ever, whatever sendig parameters.

Any idea ?

Thanks.

Downlink Queue

Device EUI Port Size Ack RxWnd Queued Details
70-b3-d5-9b-a0-00-5c-47 5 2 Yes 0 34 minutes ago
70-b3-d5-9b-a0-00-60-0c 1 2 Yes 2 5 minutes ago
70-b3-d5-9b-a0-00-5f-f9 1 2 No 0 4 minutes ago

[Michael Mitchell]

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?

[Jason Reiss]

In the network section of the config the defaultProfile can be set for devices joining with NetworkID and NetworkKey. This setting is resetting the device back to A on re-join.

“defaultProfile” : “DEFAULT-CLASS-A”,

Change to class C for devices to join as class C.
“defaultProfile” : “DEFAULT-CLASS-C”,

Otherwise using the whitelist local keys each device can be configured to a specific class when joining.

[Michael Mitchell]

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

[Author]

Posts