Stop devices being deactivated after a time

Hi

Is there a way to stop the LoRa App Server from deactivating devices. Our devices are not always on and we use ABP. So when we come to use them, half the time they dont work because they have been deactivated. We then have to go back through and reactivate them all.

Thanks

Chris

You can increase the device-session TTL in your loraserver.toml configuration:

# Device session expiration.
#
# The TTL value defines the time after which a device-session expires
# after no activity. Valid units are 'ms', 's', 'm', 'h'. Note that these
# values can be combined, e.g. '24h30m15s'.
device_session_ttl="744h0m0s"
3 Likes

Hello Brocaar,

I have two questions:

1st
What should I do to activate the change of the device_session_ttl parameter?
Do I need to restart the loraserver service (sudo systemctl restart loraserver)?

2nd
I started using the latest version of the loraserver (3.2.1) and cannot find device_session_ttl parameter.
ABP session will no longer be time limited?
What about OTAA session ttl?

Thanks in advanced …

Thanks
István

Another question from me :slight_smile: I have the device_session_ttl set to default value, but the activation for all our devices on the server is removed at the same time, in random moments. Do you know what may be the cause of such behaviour? Devices are sending data every 10 minutes…

This could be a misconfiguration of your Redis database. Please see: https://redis.io/topics/persistence.

1 Like

It was a Redis issue indeed. We’ve found out that Redis port was opened on firewall and there were some kind of attacks on it, causing Redis to fail and loose our activation data.

Is also the unit ‘y’ valid?

Not sure, but did you try? :slight_smile: (note that a year could be 365 or 366 days so that could be a reason why it can’t be used as a unit).

As an additional note: please keep an eye on Store device-sessions in database to simplify backups and disaster-recovery · Issue #74 · chirpstack/chirpstack · GitHub. We have found a potential performance and moving the device-sessions to PostgreSQL might fix this.