Closed steveregev closed 4 years ago
AFAIK, there is nothing which prevents to implement it.
How could this look like ?
Well, I tried to add it myself but couldn't successfully send the update command to the registration engine instance from my custom server class. Was wondering if someone had already tried it and succeeded since it's not in the demo client.
I'm finishing something and I will try this. If you have code to share this could help. Maybe @danielhqv play with this recently and could tell us if it works for him?
Yeah, I needed this... :) https://github.com/eclipse/leshan/pull/405
I'm using it like this in our sensor simulator, in a class that extends the org.eclipse.leshan.client.object.Server object:
@Override
public ExecuteResponse execute(final int resourceid, final String params) {
if (resourceid == Lwm2mConstants.Server.v1_0.RESOURCE_REGISTRATION_UPDATE_TRIGGER) {
sensor.getClient().triggerRegistrationUpdate();
LOG.info("Trigger registration update received (sensor: {})", sensor.getEndpointName());
return ExecuteResponse.success();
}
....
Tested with master, I added this is at the end of LeshanClientDemo :
// Change the location through the Console
try (Scanner scanner = new Scanner(System.in)) {
while (scanner.hasNext()) {
String nextMove = scanner.next();
if ("u".equals(nextMove)) {
client.triggerRegistrationUpdate();
} else {
locationInstance.moveLocation(nextMove);
}
}
}
When I type ureturn in standard input, it triggers successfully an update.
Is it also possible to add the same functionality when the client receives an execute request to resource /1/0/8 from the server?
Yes, I think this is the sample of code provided by @bolddp above.
@bolddp How do you get the client object in order to trigger the registration update?
I have a Sensor class that owns both the LeshanClient and the settings for it. This sensor is then injected into a subclass of org.eclipse.leshan.client.object.Server. That way, the Server instance, that is created before the actual client it will belong to, can reference the client later on like in the code sample above.
Hi bolddp, is it possible for you to share the skeleton of your sensor class? How do you inject the sensor into a the subclass you mentioned?
Sure. I've removed some irrelevant code, and some constant references are not included so it doesn't compile, but I hope it's clear enough: https://gist.github.com/bolddp/d4f13efe502d0915c550e4fc429aeb0a
@bolddp That helped a lot. Thanks!
I reopen this because we could implement this in Leshan demo.
Hi @sbernard31,
I have a question. When lifetime is set to 60 seconds, the client will send the update every 54 seconds. So, basically, the client will send the update right before lifetime expires.
It is possible to make the client update more frequent such that sending two updates in 60 seconds. Is it possible ? is there a configurable ? if code change is required, where should the change be ?
Thanks :)
Currently, update
is triggered automatically based on lifetime value. (a bit before lifetime expires)
You can also sent update manually using client.triggerUpdate() method.
But I suppose this would be a good idea to be able to define a period value for lifetime which is less than server lifetime.
(See https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/283)
Hi @sbernard31 I usually modify the value by sending write request through leshan server. Is there a way to modify the lifetime internally inside leshan client ? Do you have code example ? Thanks :)
In https://github.com/eclipse/leshan/wiki/Getting-Started-:-Client#create-my-own-objects
You can set the lifetime at client creation :
initializer.setInstancesForObject(LwM2mId.SERVER, new Server(12345, YOURLIFETIME, BindingMode.U, false));
You can also set a large lifetime and create your own periodic task and call client.triggerUpdate()
Thanks @sbernard31 I looked into the code yesterday. What I have in mind is to change redis expire in RedisTokener class so that It won't expire that long. So, this will be used for the session timeout. I specified session timeout in seconds in a properties file.
As for the server object defined in LWM2M, the lifetime will serve as update period. I am thinking about making session timeout independent from update period. How does this approach sound ?
Thanks :)
What is RedisTokener
? maybe you mean RedisTokenHandler ?
I'm not sure to get the point.
Yes, should be RedisTokenHandler. I think. The one put the key with expiration in Redis. I make its expiration time to be read from my own property file, isntead of from registration message. I put a bigger value there. That is how I achieve two update message before expiration.
Regards :)
I created a PR #802 which adds a new update
command for leshan-client-demo.
Update registration trigger is not implemented in the demo client. Is there anything preventing the implementation?