Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse SmartHome » Bridge/Thing lifecycle question
Bridge/Thing lifecycle question [message #1747474] Tue, 15 November 2016 09:44 Go to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
All,

I am trying to get a grasp of the new B/T lifecycle improvements. The documentation now states:

Quote:
A ThingHandler is notified about Bridge status changes to ONLINE and OFFLINE after a BridgeHandler has been initialized. Therefore, the method ThingHandler.bridgeStatusChanged(ThingStatusInfo) must be implemented (this method is not called for a bridge status updated through the bridge initialization itself).


and

Quote:
Only Things with status (cf. Thing Status) ONLINE or OFFLINE are considered as initialized by the framework. To achieve that, the status must be reported to the framework by a callback. Furthermore, the framework expects initialize() to be non-blocking and to return quickly. For longer running initializations, the implementation has to take care of scheduling a separate job which must set the status at the end


Fine in itself, but pretty often bridges have to set up some sort of communication link to an external physical gateway. This is typically done during initialize(), and based on that, the ThingStatus of the Bridge is set to OFFLINE or ONLINE. As a consequence, child Things would not be notified of a changed state of the Bridge, as per above documentation

Do I understand correctly that based on this, and the doc, that by default we have to schedule a separate job for this connection pattern? More generally, if the ONLINE/OFLINE status of a Bridge depends on an interaction with a physical device, or other configuration bit, can't we change BaseThingHandler in such a way that an abstract method is defined that is called by a Runnable so that binding implementors have to implement that method for connection/initialisation/other purposes, and thus, child Things do get notified of a state change of the bridge?
Re: Bridge/Thing lifecycle question [message #1747946 is a reply to message #1747474] Thu, 17 November 2016 08:16 Go to previous messageGo to next message
Stefan Bussweiler is currently offline Stefan BussweilerFriend
Messages: 6
Registered: January 2016
Junior Member
Quote:

A ThingHandler is notified about Bridge status changes to ONLINE and OFFLINE after a BridgeHandler has been initialized. Therefore, the method ThingHandler.bridgeStatusChanged(ThingStatusInfo) must be implemented (this method is not called for a bridge status updated through the bridge initialization itself).


This behavior has not changed, it's the same as before.

Quote:

Only Things with status (cf. Thing Status) ONLINE or OFFLINE are considered as initialized by the framework. To achieve that, the status must be reported to the framework by a callback. Furthermore, the framework expects initialize() to be non-blocking and to return quickly. For longer running initializations, the implementation has to take care of scheduling a separate job which must set the status at the end


Same here, same behavior as before. ThingHandler.initialize() should never block. Long running initializations must be scheduled in a separate job.

Quote:

Fine in itself, but pretty often bridges have to set up some sort of communication link to an external physical gateway. This is typically done during initialize(), and based on that, the ThingStatus of the Bridge is set to OFFLINE or ONLINE. As a consequence, child Things would not be notified of a changed state of the Bridge, as per above documentation


Correct. But the initialize() methods of the child things are called after the bridge has been initialized (bridge status is ONLINE/OFFLINE).

Quote:

Do I understand correctly that based on this, and the doc, that by default we have to schedule a separate job for this connection pattern?


If the connection should be established in ThingHandler.initialize() - yes.

Quote:

More generally, if the ONLINE/OFLINE status of a Bridge depends on an interaction with a physical device, or other configuration bit, can't we change BaseThingHandler in such a way that an abstract method is defined that is called by a Runnable so that binding implementors have to implement that method for connection/initialisation/other purpose


We can think about such a method in the BaseThingHandler implementation. In my opinion it should not so much effort to handle this in the concrete handler implementation. As already mentioned, this behavior has not been introduced with the life cycle refactoring.

In the "old" implementation a child thing handler could be initialized although if no bridge was there. In the "new" implementation a BridgeHandler of a bridge is initialized before ThingHandlers of its child things are initialized. If there is a child thing without an initialized bridge, the child thing handler will not be initialized until the bridge handler has been initialized.

[Updated on: Thu, 17 November 2016 08:39]

Report message to a moderator

Re: Bridge/Thing lifecycle question [message #1747948 is a reply to message #1747946] Thu, 17 November 2016 08:38 Go to previous messageGo to next message
Karel Goderis is currently offline Karel GoderisFriend
Messages: 198
Registered: March 2014
Senior Member
Stefan

Did anything change in the new lifecycle with respect to updating the structure of a Thing? e.g. addition of new dynamic channels?

If I remember well I ran into problems in the past when doing that during the initialize()
And is initliaize() called whenever a new channel is added to the Thing? I know there is the callback for changes in the configuration of the Thing, but what with a changing structure.

Tx
K
Re: Bridge/Thing lifecycle question [message #1748248 is a reply to message #1747948] Mon, 21 November 2016 15:18 Go to previous message
Stefan Bussweiler is currently offline Stefan BussweilerFriend
Messages: 6
Registered: January 2016
Junior Member
Quote:

Did anything change in the new lifecycle with respect to updating the structure of a Thing? e.g. addition of new dynamic channels?


No.

Quote:

And is initliaize() called whenever a new channel is added to the Thing? I know there is the callback for changes in the configuration of the Thing, but what with a changing structure.


If the structure of a thing has been changed the binding is informed via ThingHandler.thingUpdated().
Previous Topic:Contribute CM11A binding for X10 devices
Next Topic:MQTT not getting configuration
Goto Forum:
  


Current Time: Sun Nov 18 09:43:57 GMT 2018

Powered by FUDForum. Page generated in 0.02110 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top