Deactivation of device

@brocaar my device keeps deactivating in chirpstack web interface.

I have tried this:

But no luck. Shuts of at random times. Advice? Please let me know. Thank you.

Have you verified that devices send regular frames within the interval you specify? I have sensors such as push-buttons and these show up as inactive until someone presses them :slight_smile: One way around this is to sacrifice a little battery life and configure a supervisory message to be sent every 24/48 hrs, which has added benefit of sending you a regular heartbeat/battery & link status.


Update uplink interval settings in your device-profile.

By “verified” I meant, did you capture a few dozen frames for each device/sensor and confirm that ChirpStack is receiving at least one actual frame every that interval you set via that field (not gateway frames, but actual decoded payload sensor frames)?

BTW, if the first screen capture you included is actual data, it’s also troubling that (center) Gateways stat doesn’t show any active gateways.

FYI, I have confirmed that this code on ChirpStack works for my gateways and sensors, except for those devices that lack supervisory/timed transmissions.

Hi @sagarpatel I will try this and let you know how it goes. thank you.

1 Like

Hi @fmgst sometimes it stays on and when it does the gateway is active and red turns to green. and the device is sending data regularly while its on and everything is ok. But it only stays on for an hour or so at a time.

@fmgst thank you for your response as well

Then ChirpStack is the proverbial “messenger” here, making you aware that you’re having network and/or hardware issues.

Q: Do you have the means to configure a second gateway? If so, you could try process-of-elimination to exclude hardware and/or network failures. I like my gateways on WiFi (so no need to run Ethernet) but, in my office, I do have one gateway that’s over Ethernet, to exclude “wifi-related” issues. I have a Node-RED flow that looks for both types of gateways and shoots me an email if it’s not seen a recent packet. Life-saver!

Q: Do you have the means to configure one sensor that’s configured to send timed supervisory packets? If so, you can use that for “heart-beat” for the rest of your system. I have a few RS191 temperature & RH % sensors that give me that functionality - rock solid. Then, I have a Node-RED flow that looks for only these few sensors and shoots me an email if it’s not seen a recent packet. Life-saver!

Just some ideas on how to troubleshoot your current issue and how to minimize down-time in the future.

@fmgst all good points I will check. I am suspicious it has something to do with the TTL in Redis cache. What do you think? I am interested to hear your and @brocaar thoughts.

It works fine for me in all cases, so I have no reason to suspect the software. All things of this nature that I have run into before were issues with general network instability, folks unplugging my gateways, etc etc. I can only suggest that you update your installation and see what might be suboptimal in your setup.

If you have evidence that ChirpStack is at fault (beyond what you’ve posted here), please document a way to reproduce issue and open a ticket under appropriate application.

@fmgst Sorry for the late response. I have been busy with other assignments (at school) . No software fault the TTL is just an attribute in the redis cache. Like device session time on the network server. Would you happen to know what the file name is called? I have only seen the redis.config file, but I cannot find the TTL attribute in it. Please let me know, thank you.

I have no idea what you’re looking for. That said, when looking around ChirpStack sources on github, we find “ttl” in several places. Given that redis is just a “in-memory data structure store, used as a database, cache, and message broker”, references to “ttl” are likely propagated from there.

This has nothing to do with the TTL. The Inactive state in ChirpStack is driven by the expected uplink interval in the device-profile. If (now() - last uplink) > expected uplink interval (with some small margin), then the device is considered “inactive”.

Hi @brocaar we have tried this. but I will give it another go, perhaps some sort of error on my part. Thank you.

@brocaar this is strange how the device is active but the gateway is not. Thoughts?

As @brocaar mentioned, Chirpstack does not know if a gateway or device is online or alive.
Chirpstack only compares the current time with the interval of time set to know when last connection of a device or gateway was.
If this difference is smaller than set, it considers that is active, otherwise, is offline or inactive.


@pulidoj thank you your elaboration on the point. The deactivation is random though. Have you ever experienced this? One would think if there was a logical piece of code that was making this occur then the deactivation would be systematic.

In addition I have changed the uplink data to 15 seconds and restarted the chirpstack netowrok server on my EC2 instance on AWS and when I see these messages:

As you can see the interval here is greater then the expected uplink time which is this:

yet the device is still active and sending data. please explain?

Thank you.

@brocaar please explain the above message i have sent with the two images, I must be missing something as it does not make initial sense. Thank you.

Hi @marcoaerlic

I’m sorry but I don’t catch your point.

If you send uplinks every 15 seconds and your Uplink Interval is also 15 seconds you should usually see the device as active and it would be difficult for you to see the device as inactive when you refresh the device page.
Think also that the active signal is not automatic refreshing continuosly, just compared when you refresh the device page.

I suggest you to do this, set the device uplinks every 2/3 minutes for instance and 30 seconds for Uplinks interval.

When you receive an uplink and you refresh the device status it shoud be active.
Check it again one minute later and it should be inactive.

Keep also in mind that usually LoRa devices don’t trasmit every xx seconds, usually every some minutes or even hours, so if there is a difference of some seconds when signalling active or inactive is not usually a problem.