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”.
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:
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.
We usually should be able to setup in the gateway the frequency that it sends a stat message to the server. This usually is between 20-30 seconds.
If I’m not wrong, if you use the Semtech gateway bridge, you have the following parameter in the config file:
# Keep alive will set the amount of time (in seconds) that the client should
# wait before sending a PING request to the broker. This will allow the client
# to know that a connection has not been lost with the server.
# Valid units are 'ms', 's', 'm', 'h'. Note that these values can be combined, e.g. '24h30m15s'.
keep_alive="30s"
So Chirpstack compares the last stat connection of the gateway and this value to consider active/inactive.
If you set up for instance 4-5 minutes for stats messages and 30 seconds for keep_alive, most of the time the gateway will appear as disconnected.
I am using concetratord not sentech, only semtech uses that unfornately. Do you have any knowledge in regards to why this would happen when using Concetratord? I apologise for the late response as well.
@brocaar how does a gateway using concentratord gateway bridge. What is the logical equivalent for the keep_alive variable that @pulidoj was talking about. So what determines if the gateway is active/inactive for a concetratord gateway bridge. Please let me know. Thank you.
