Updating thing properties of initialised thing handlers

Development
1

Hello everyone,

I’m currently developing my first binding and I still have a lot to learn. However I’ve got one question that I could not find in the docs so far: Given that I have a perfectly fine initialised thing/thing handler. What happens to this thing (in terms of lifecycle events) when I change a property of the thing in the UI? Does this create some kind of trigger event that I can use to reinitialize the thing handler if necessary? Or will the handler be disposed and reinitialised by the framework anyway (my first experiments seem to lead to the conclusion that the latter is not the case)? Thank you for your insights :blush:

2

I believe it will call the method annotated with @Modified in your component, with the new configuration map.

3

Thank you JimT, I will try that :blush:

4

As far I remember thing properties are read only and can not be influenced by end user. What user can change are configurations which are defined in thing xml / config descriptor. Update to such config triggers thing lifecycle (destruct/initialize).
The @Modified annotation is something which works on different level - namely on OSGi services. This is a different mechanism which will impact ThingHandlerFactory if peoperly applied.

5

Oops yes. Property is set by the thing, not the user and is read-only.

I was assuming that @DrRSatzteil meant configuration changes.

6

If I assume you mean CONFIG is changed by the user after the thing is online.
The dispose() is called allowing you to do any cleanup, then the initialise() is called allowing you to update the CONFIG class and perform any needed code.

The dispose() should stop any extra created threads and it gets called if you remove a thing, or if a CONFIG gets changed.

There is a lifecycle flow chart in the docs somewhere.

I use the pause button on the thing to test this life cycle or can change a config.

7

Thanks everyone, yes exactly I meant a configuration change. I just used the wrong terminology :see_no_evil:

This really helps, now I just have to find some time to continue coding :grimacing:

8

Ok… There is still one thing I don’t get when it comes to thing/handler initialization.

I have the following init method in my handler:

    @Override
    public void initialize() {
        BridgeConfigOptions config = getConfigAs(BridgeConfigOptions.class);
        this.basetopic = config.basetopic;
        this.appLockTimeout = config.appLockTimeout;
        this.discoverDefaultApps = config.discoverDefaultApps;
        this.channelPrefix = thing.getUID() + ":";
        logger.debug(
                "Configured handler with baseTopic {}, channelPrefix {}, appLockTimeout {}, discoverDefaultApps {}",
                this.basetopic, this.channelPrefix, this.appLockTimeout, this.discoverDefaultApps);
        bridgeStatusChanged(getBridgeStatus());
    }

Everything works fine when I create an item either manually or through discovery. However when I change e.g. the parameter appLockTimeout in the UI the initialize method gets called twice by the framework.

In the first call the config matches the changed config in the UI. In the second call, the config options are back at their defaults. I’m pretty sure that I’m missing something rather obvious there but I have no idea what that could be!?

Edit: I realised that this only happens to my bridge. Other things get initialised only once. The special thing about this bridge is that it is itself bound to another bridge. However I don’t really see how this would have an impact on the way things get initialised. I also thought there might be an exception thrown somewhere but this does not seem to be the case (tried with a surrounding try catch for the whole method code).

Edit2: I added another config parameter. What should I say: When I change this parameter it works as expected. When I change any of the ones in my code above I still get the double initialisation issue…

9

I finally got behind the mystery. The properties were always reset through discovery results happening in the background. I wasn’t expecting that a new discovery result would simply overwrite the user defined properties. However now that I know this was simple to solve: I just removed these properties in the discovery service and now I can change the properties manually.

One exception remains the base topic but that property cannot be left empty in the discovery. Other mqtt apps behave the same way.

10

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.