| Bridge/Thing lifecycle question [message #1747474] |
Tue, 15 November 2016 09:44  |
 Karel Goderis
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  |
Stefan Bussweiler
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 |
|
|
|
|
Powered by
FUDForum. Page generated in 0.02599 seconds
] 
Search
Help
Register
Login
Home
