Eclipse Community Forums: Eclipse SmartHome » Best update strategy for a polled device ?

Help

Home

Home » Archived » Eclipse SmartHome » Best update strategy for a polled device ?

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

Best update strategy for a polled device ? [message #1759271]

Sun, 09 April 2017 16:56

Charles Brouwers

Messages: 7
Registered: April 2017

Junior Member

If a thing has multiple channels and needs to be polled to be updated; and the polling is computationally expensive, what is the best strategy for updating channels ? Here is what I have implemented, is it OK ?
-----------------------------------------------------------------------------------------------------
1. I have an a general updating method that does the following

Checks if the last update was recent and returns if it is the case (this is to prevent polling to frequently, this test is bypassed if needed)
Otherwise polls the device
Updates all channels with the updateState method.

2. The intialize(...) method creates a recurring task calling the updating method

3. When the ThingHandler receives a Refresh command on any channel, the updating method is also called (and all channels are updated unless it was already done recently)

4. This is not important but some other commands also trigger an update when received because of side effects in the device.
-----------------------------------------------------------------------------------------------------

Does this make sense ?
Should the recurring task issue refresh commands to the channels instead of directly refreshing the channels
Is it OK to call the updateState method without checking if the channel state really needs to be changed first ? Is it computationally expensive ?
Does updating with updateState automatically triggers an update if the UI (in openhab) , what does ?
This is a somewhat related question : when are refresh commands naturally triggered by the framework ?

Report message to a moderator

Re: Best update strategy for a polled device ? [message #1759321 is a reply to message #1759271]

Mon, 10 April 2017 14:17

Simon Kaufmann

Messages: 51
Registered: January 2011

Member

Quote:

Does this make sense ?

Yes!

Quote:

Should the recurring task issue refresh commands to the channels instead of directly refreshing the channels

No, it is good to directly do it. The REFRESH commands are just used to communicate from an "external" party (UI, framework) to the binding that it should be done now. It's good like you did it.

Quote:

Is it OK to call the updateState method without checking if the channel state really needs to be changed first ? Is it computationally expensive ?

Yes, it is okay. The framework checks whether the value changed and issues a ItemStateEvent (always) and ItemStateChangedEvent (only if it really changed), so that receivers can subscribe to whatever fits best their needs. Usually it's the ItemStateChangedEvent, unless it is important (for whatever reason) how old the information is.

Quote:

Does updating with updateState automatically triggers an update if the UI (in openhab) , what does ?

Yes, it does. Most UIs subscribe to the mentioned ItemStateChangedEvent and therefore will get notified automatically.

Quote:

This is a somewhat related question : when are refresh commands naturally triggered by the framework ?

The major use-case is on start-up, especially when an item gets linked to a channel. But there is no restriction to that.

[Updated on: Mon, 10 April 2017 14:19]

Report message to a moderator

Previous Topic:	Channels cannot be linked if dynamically created
Next Topic:	Items, Locations and core types

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 16 13:58:36 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter