Hi,
We have observed below mentioned log in webUI
"The node has not been activated yet or device has been inactive for long time"
Is this an expected behavior if we are not using the Node or target board which runs lora server more than 2 months?
Is this applicable for OTAA and ABP methods?
Got the same question over here.
Is there an option to disable this feature / issue?
This is already configurable using the loraserver.toml configuration https://www.loraserver.io/loraserver/install/config/
# 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"
Thank you.
How can I disable this feature?
With a 0s?
You can’t, but you can set the TTL to a really high value.
OK. Thanks. 
Please note that the reason behind expiring these sessions is that Redis is a key / value store and there are no queries like with SQL to cleanup this storage. Therefore I think it is better to always have a TTL so eventually this store is “garbage collected” 
E.g. on PostgreSQL you could do something like:
delete from device_session where last_seen < $SOME_TIMESTAMP;
Hello everyone!
I posted a different topic about a problem that appeared to my assigned (in Loraserver) devices, but if you tried this and find a solution:
Device Session Expiration has to do with “no activity” devices,as below, right?
If i set device_session_ttl=“0h30m0s”, these devices will be expired, and i may create them (Again) using the same EUI’s?
May all this problem is “garbage collection” as @brocaar mentioned yesterday?
Thanks,
Nikos.
Hi,
I am passing the parameters like through the command arguments not through the configuration file.
Example loraserver --net-id ----band IN_865_867 …
In that case,if we are not passing the “device_session_ttl” parameter,what can be the expected device-session expiring timeout.
CLI arguments are not supported anymore, you must use a configuration file.
What are the minimum, maximum value allowed for “device_session_ttl”?
What is the default value taken by LoRa server if this parameter is not defined in configuration file?
The defaults are documented here: https://www.loraserver.io/loraserver/install/config/. The max value is the max value that is supported by Redis to set the expiration using this command: https://redis.io/commands/pexpire. I’m not sure if there is a maximum.
Thanks for the reply.
According to https://www.loraserver.io/loraserver/install/config/, default value is 744 hours.
We are running brocaar LoRa server on ARM device and passing the parameter through command line arguments. We could not implement configuration file support.
In this case, what value will be used by LoRa server?
What is LoRa server behavior when “device_session_ttl” is not set?
Whether LoRa server will use default value 744 hours?
You should not use cli arguments to pass these values. They have been deprecated and still work to support the migration from env. vars to config values. In one of the next releases, this will be removed completely.
Yes. I understand. We are running LoRa server on ARM platform. We will take sometime to migrate from CLI to configuration file format. Till that time I need below information.
What will be the default value which will be used for “device_session_ttl” by LoRa server? Is it 744 hours?
You can see all (default) values by running loraserver configfile It will generate a (new) configuration file. Please note that when there already a config file exists in one default configfile locations, it will re-use these values.
loraserver -v
loraserver version 0.22.0
loraserver configfile
FATA[0000] NetID parse error: lorawan: exactly 3 bytes are expected
What is the meaning of above error? This error could be because of not passing CLI “net_id”.
It looks like configfile option is not supported by this version of loraserver. Any other way to find default value used for “device_session_ttl”?
Hi,
I am using Loraserver 0.22.0 and LoRa app server 0.14.1 ARM binaries. How device session ttl is handled in this version? As this version does not support configuration file, what will be the default device session timeout value?
Also After device session timeout is occurred,it is necessary to remove and add the LoRa node device again through Web UI. Any way to avoid this?
When you run the binary with --help you will see all the (config) flags for your version. When the session has expired it only means the device needs to re-join or you need to reactivate through ABP.
I have checked all the configuration flags. There is no flag for configuring the device session ttl value. It looks like In this version (Loraserver 0.22.0 and LoRa app server 0.14.1), LoRa server internally setting the device session ttl value to 744 hours. Is that correct?
When the session expired, following steps are mandatory.
OTAA - rejoin from node device
ABP - reactivate the ABP using WEB UI.
Whether my understanding is correct?
