Eclipse Community Forums: Eclipse SmartHome » Thing Status Listeners

Search

Help

Login

Home » Archived » Eclipse SmartHome » Thing Status Listeners

Show: Today's Messages :: Show Polls :: Message Navigator

Switch to threaded view of this topic

Create a new topic

Submit Reply

Thing Status Listeners [message #1718834]

Wed, 30 December 2015 21:57

Dan Cunningham is currently offline

Friend

Messages: 44
Registered: March 2014

Member

Hi, when a Thing's bridge is initialized "bridgeHandlerInitialized" is called on the thing. What i would like to do is then register a listener on the bridge so I know when it's moved to from an "initializing" state to a "online" state. Right now I have a custom listener interface to do this, but this seems clumsy to me . Is there a way for a thing to hear when its bridge status changes?

Report message to a moderator

Re: Thing Status Listeners [message #1719295 is a reply to message #1718834]

Wed, 06 January 2016 20:23

Dan Cunningham is currently offline

Friend

Messages: 44
Registered: March 2014

Member

anyone

Wink

Report message to a moderator

Re: Thing Status Listeners [message #1719486 is a reply to message #1719295]

Fri, 08 January 2016 10:41

Andre Fuechsel is currently offline

Friend

Messages: 28
Registered: December 2015

Junior Member

I don't know our implementation, but why do you rate it "very clumsy"?

Each thing is propagating status changes on the event bus on the topic "smarthome/things/{thingUID}/statuschanged". You can just subscribe to this event.

Within the framework you could use the ThingHandlerCallback#statusUpdated method to be informed about any status update.

Report message to a moderator

Re: Thing Status Listeners [message #1719543 is a reply to message #1719486]

Fri, 08 January 2016 17:47

Dan Cunningham is currently offline

Friend

Messages: 44
Registered: March 2014

Member

By clumsy I meant my own listening implementation, I had created a listener/subscriber pattern between the bridge and things that did not use the ESH bus. I was not at all talking about the ESH framework, in fact I was assuming there was a better way within the ESH framework. I'll take a look at listening to the event bus, do you know of an example of this?

Report message to a moderator

Re: Thing Status Listeners [message #1719546 is a reply to message #1719543]

Fri, 08 January 2016 18:26

Dan Cunningham is currently offline

Friend

Messages: 44
Registered: March 2014

Member

Let me ask this a different way to make sure I'm thinking about this the right way.

A thing in my binding only cares when the bridge is online or offline, not when it's initialized. So in order for a thing to know when it's bridge is online or offline do I need to listen to the bus, or is there a simplier way I'm not seeing?

If I do need my things to listen to the bus, it looks like I need to register a listener via a OSGI Declarative service. Is the best way of doing this to have my HandlerFactory (which creates my thing handlers) be registered as an event listener and somehow pass a reference to my things?

Thanks and sorry if this is not very clear.

Report message to a moderator

Re: Thing Status Listeners [message #1719675 is a reply to message #1719546]

Mon, 11 January 2016 10:47

Andre Fuechsel is currently offline

Friend

Messages: 28
Registered: December 2015

Junior Member

Please have a look into the documentation about events: https://www.eclipse.org/smarthome/documentation/concepts/events.html. Here the status events are mentioned as well and the difference between status and statusChanged events. You do NOT need to listen to OSGi events using declarative services!

If you want to get hold of the thing handler of your bridge, you might want to implement a method like get in the Hue-Binding: HueLightHandler#getHueBridgeHandler. But you cannot access the bridge handler's ThingHandlerCallback so this won't help you for getting information of status changes of the bridge.

Report message to a moderator

Re: Thing Status Listeners [message #1719706 is a reply to message #1719675]

Mon, 11 January 2016 15:25

Kai Kreuzer is currently offline

Friend

Messages: 673
Registered: December 2011

Senior Member

Dan, may I ask you why you need to be informed about online/offline in the first place? Note that the framework already takes care of setting Things to OFFLINE, if their Bridge is OFFLINE.
Another note: This PR https://github.com/eclipse/smarthome/pull/769 will do quite some changes to the life cycle handling - I am not completely sure what changes this will imply exactly.

Report message to a moderator

Re: Thing Status Listeners [message #1719738 is a reply to message #1719675]

Mon, 11 January 2016 18:06

Dan Cunningham is currently offline

Friend

Messages: 44
Registered: March 2014

Member

Andre Fuechsel wrote on Mon, 11 January 2016 10:47

Please have a look into the documentation about events: https://www.eclipse.org/smarthome/documentation/concepts/events.html. Here the status events are mentioned as well and the difference between status and statusChanged events. You do NOT need to listen to OSGi events using declarative services!

At the bottom of that page its states

Each event subscriber must be registered via OSGi Declarative Services (DS) under the org.eclipse.smarthome.event.EventSubscriber interface.

Is this not the case then, or am I confusing something?

Report message to a moderator

Re: Thing Status Listeners [message #1719739 is a reply to message #1719706]

Mon, 11 January 2016 18:09

Dan Cunningham is currently offline

Friend

Messages: 44
Registered: March 2014

Member

Kai Kreuzer wrote on Mon, 11 January 2016 15:25

Dan, may I ask you why you need to be informed about online/offline in the first place? Note that the framework already takes care of setting Things to OFFLINE, if their Bridge is OFFLINE.

For some reason I thought this did not work for me, but I don't remember why, I'll check it again.
Quote:

Another note: This PR https://github.com/eclipse/smarthome/pull/769 will do quite some changes to the life cycle handling - I am not completely sure what changes this will imply exactly.

I'll take a look at that PR, thanks.

Report message to a moderator

Re: Thing Status Listeners [message #1719740 is a reply to message #1719739]

Mon, 11 January 2016 18:16

Kai Kreuzer is currently offline

Friend

Messages: 673
Registered: December 2011

Senior Member

> Is this not the case then, or am I confusing something?

I would not suggest to use events here - the whole relation between bridges/things/handlers are so far covered through the APIs and the base classes, so if something relevant is really missing here, we should add it.
Can you maybe elaborate your use case for which you need those listeners?

Report message to a moderator

Re: Thing Status Listeners [message #1719798 is a reply to message #1719738]

Tue, 12 January 2016 07:27

Andre Fuechsel is currently offline

Friend

Messages: 28
Registered: December 2015

Junior Member

Dan Cunningham wrote on Mon, 11 January 2016 19:06

At the bottom of that page its states
Each event subscriber must be registered via OSGi Declarative Services (DS) under the org.eclipse.smarthome.event.EventSubscriber interface.
Is this not the case then, or am I confusing something?

Dan, you are completely right and I was wrong. Smile

Smile

But I agree with Kai that as long as you are inside the binding you should not rely on events but use the binding API. However, AFAIK there is no easy way to get informed about status updates from your bridge, although you are able to get hold of your bridge handler easily as I explained earlier.

Report message to a moderator

Re: Thing Status Listeners [message #1719803 is a reply to message #1719798]

Tue, 12 January 2016 08:13

Andre Fuechsel is currently offline

Friend

Messages: 28
Registered: December 2015

Junior Member

The framework ensures, that in case the Bridge goes OFFLINE, the children are going OFFLINE as well, with status detail "Bridge offline". If the Bridge is going online again, the children remain OFFLINE, but the status detail "Bridge offline" is removed. The framework cannot distinguish between children being OFFLINE, because of the bridge was OFFLINE or children being OFFLINE for somer other reason. Therefore you must handle the ONLINE case yourself as for instance the Hue binding does. The BaseThingHandler provides a method bridgeHandlerInitialized that you can override (the above mentioned PR moves this method into the ThingHandler interface) to handle your children accordingly in case the bridge goes ONLINE.

Report message to a moderator

Re: Thing Status Listeners [message #1719869 is a reply to message #1719803]

Tue, 12 January 2016 18:08

Dan Cunningham is currently offline

Friend

Messages: 44
Registered: March 2014

Member

Andre Fuechsel wrote on Tue, 12 January 2016 08:13

The framework ensures, that in case the Bridge goes OFFLINE, the children are going OFFLINE as well, with status detail "Bridge offline". If the Bridge is going online again, the children remain OFFLINE, but the status detail "Bridge offline" is removed. The framework cannot distinguish between children being OFFLINE, because of the bridge was OFFLINE or children being OFFLINE for somer other reason. Therefore you must handle the ONLINE case yourself as for instance the Hue binding does. The BaseThingHandler provides a method bridgeHandlerInitialized that you can override (the above mentioned PR moves this method into the ThingHandler interface) to handle your children accordingly in case the bridge goes ONLINE.

Thanks Andre for the clarification. So then is bridgeHandlerInitialized called when the bridge moves to the INITIALIZED state or when it moves to a ONLINE state? I was assuming the former. I wonder if it would be more flexible to have a method like bridgeHandlerStateChanged so a thing can have more granular information about it's bridge state?

Report message to a moderator

Re: Thing Status Listeners [message #1719916 is a reply to message #1719803]

Wed, 13 January 2016 07:48

Marcel Verpaalen is currently offline

Marcel Verpaalen

Friend

Messages: 59
Registered: September 2014

Member

I'm running into the same 'issue'
The bridge being initialized does not mean that the bridg is online.
Hence once the bridge-offline triggered the statuschange for all childthings to go-offline, it would be good to have a have a notification once it becomes online again. Indeed we can do something like the hue but I very much like the idea of having a bridgeHandlerStateChanged

Maybe it is something we can add once your PR https://github.com/eclipse/smarthome/pull/769 is merged

Report message to a moderator

Re: Thing Status Listeners [message #1720124 is a reply to message #1719869]

Thu, 14 January 2016 15:03

Stefan Bussweiler is currently offline

Stefan Bussweiler

Friend

Messages: 6
Registered: January 2016

Junior Member

Dan Cunningham wrote on Tue, 12 January 2016 18:08

Thanks Andre for the clarification. So then is bridgeHandlerInitialized called when the bridge moves to the INITIALIZED state or when it moves to a ONLINE state? I was assuming the former. I wonder if it would be more flexible to have a method like bridgeHandlerStateChanged so a thing can have more granular information about it's bridge state?

Some notes regarding PR-769: ThingHandler.bridgeHandlerInitialized() is called when the according handler of the Bridge has been initialized. Only Things/Bridges in status ONLINE or OFFLINE will be considered as `initialized` by the framework.

With other words: ThingHandler.bridgeHandlerInitialized() will be called if the status of the Bridge has been set to ONLINE resp. OFFLINE.

Report message to a moderator

Re: Thing Status Listeners [message #1720159 is a reply to message #1720124]

Thu, 14 January 2016 19:36

Dan Cunningham is currently offline

Friend

Messages: 44
Registered: March 2014

Member

Stefan Bussweiler wrote on Thu, 14 January 2016 15:03

With other words: ThingHandler.bridgeHandlerInitialized() will be called if the status of the Bridge has been set to ONLINE resp. OFFLINE.

Thanks Stefan. Given the name of the method that's not what I would expect. Also, that fact that it's called for both ONLINE and OFFLINE changes does not seem to be helpful, one would need to go through the ESH code to understand what to expect. I guess a thing who implements bridgeHandlerInitialized could check its bridge status every time this method is called, but I wonder if using something like BridgeStatusUpdated(ThingStatus status) would not make this easier for developers to understand and implement.

Report message to a moderator

Re: Thing Status Listeners [message #1720197 is a reply to message #1720124]

Fri, 15 January 2016 07:55

Andre Fuechsel is currently offline

Friend

Messages: 28
Registered: December 2015

Junior Member

Stefan Bussweiler wrote on Thu, 14 January 2016 16:03

With other words: ThingHandler.bridgeHandlerInitialized() will be called if the status of the Bridge has been set to ONLINE resp. OFFLINE.

I don't think, it is called on each status change from ONLINE to OFFLINE. At least I did not see this in the code.

Report message to a moderator

Re: Thing Status Listeners [message #1720198 is a reply to message #1720197]

Fri, 15 January 2016 08:06

Kai Kreuzer is currently offline

Friend

Messages: 673
Registered: December 2011

Senior Member

> I don't think, it is called on each status change from ONLINE to OFFLINE

I doubt that as well and if it where the case, I agree with Dan that the method name is completely misleading.

> Maybe it is something we can add once your PR https://github.com/eclipse/smarthome/pull/769 is merged

+1. I agree with Marcel that we probably should replace bridgeHandlerInitialized by a bridgeHandlerStateChanged (which passes the new state). But let's first process PR 769, so that we do not get into any conflicts. I hope to find the time to review it next week - if one of you wants to have a look as well, please do so and leave your comments!

Report message to a moderator

Re: Thing Status Listeners [message #1720212 is a reply to message #1720197]

Fri, 15 January 2016 09:35

Stefan Bussweiler is currently offline

Stefan Bussweiler

Friend

Messages: 6
Registered: January 2016

Junior Member

Andre Fuechsel wrote on Fri, 15 January 2016 07:55

Stefan Bussweiler wrote on Thu, 14 January 2016 16:03

With other words: ThingHandler.bridgeHandlerInitialized() will be called if the status of the Bridge has been set to ONLINE resp. OFFLINE.

I don't think, it is called on each status change from ONLINE to OFFLINE. At least I did not see this in the code.

Yes you are right. Sorry for the confusion.

ThingHandler.bridgeHandlerInitialized() is called when the status of the bridge has been changed from INITIALIZING to ONLINE/OFFLINE (not for each ONLINE/OFFLINE status change). The status ONLINE/OFFLINE is set by the binding developer. The status change from INITIALIZING to ONLINE/OFFLINE signals the framework that the handler has been initialized. If the thing is a bridge, the child-things will be notified via ThingHandler.bridgeHandlerInitialized() about the bridge initialization.

I agree with Kai. Let's process with PR 769 in order to avoid conflicts. Afterwards we can thing about a bridgeHandlerStateChanged() method.

Report message to a moderator

Re: Thing Status Listeners [message #1720213 is a reply to message #1720212]

Fri, 15 January 2016 09:39

Kai Kreuzer is currently offline

Friend

Messages: 673
Registered: December 2011

Senior Member

> Afterwards we can thing

No, "think" Wink

Wink

Report message to a moderator

Re: Thing Status Listeners [message #1720269 is a reply to message #1720213]

Fri, 15 January 2016 16:20

Dan Cunningham is currently offline

Friend

Messages: 44
Registered: March 2014

Member

Sounds good.

Report message to a moderator

Switch to threaded view of this topic

Create a new topic

Submit Reply

Previous Topic:	Update thing status when bridge becomes online / offline
Next Topic:	What is the definition of a Thing!

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 12:46:34 GMT 2024

Powered by FUDForum. Page generated in 0.04995 seconds

.:: Contact :: Home ::.

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

Back to the top