Eclipse Community Forums: Eclipse SmartHome » .items processed after .things: how to time/deal with this?

Help

Home

Home » Archived » Eclipse SmartHome » .items processed after .things: how to time/deal with this?

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

.items processed after .things: how to time/deal with this? [message #1439922]

Tue, 07 October 2014 17:39

Karel Goderis

Messages: 198
Registered: March 2014

Senior Member

Hi architects Wink

Just came across the following situation when developing the KNX 2.0 binding. When the ESH/OH2 runtime is started the .things files are processed first, and only after some time the .items files are parsed. As part of the .things processing the KNX Things are instantiated, as it should be. As soon as the Things are created, their handlers start to interact with the KNX bus, and as part of the initialisation (similar to KNX 1.x) the KNX bus is queried to read out some variables, and a Channel is updated with this value. However, this happens before the .items is read and Items are instantiated, which is inconvenient when the Items have to initialised with a value read from the physical network.

Question: how can one time the ThingHandler to wait for the instantiation of the Items that are bound to some specific Channels?

Karel

Report message to a moderator

Re: .items processed after .things: how to time/deal with this? [message #1439975 is a reply to message #1439922]

Tue, 07 October 2014 19:29

Dennis Nobel

Messages: 166
Registered: September 2014

Senior Member

Hi Karel,

I see your problem, but at the moment there is no solution.

For me this has nothing to do with the DSL files, this could also occur at runtime, when links are created after a thing was added through the inbox. So a solution must be implemented at a higher level than the DSLs.

It would be possible to provide a callback in the ThingHandler (e.g. channelBound(ChannelUID channelUID) ), so that the thing handler can update the state afterwards. But for this the ThingManager must actively track the links between items and things, which it does not do yet. And there are lot of possible lifecycle problems to handle. For example the link could exists, before the thing handler is initialized.

@Kai: What do you think?

Dennis

Report message to a moderator

Re: .items processed after .things: how to time/deal with this? [message #1440297 is a reply to message #1439975]

Wed, 08 October 2014 07:19

Karel Goderis

Messages: 198
Registered: March 2014

Senior Member

it could also be the responsibility of the binding to have these queries at a specified interval? (at least, that specific "feature" is demanded by a few people using the OH1.x binding)

Report message to a moderator

Re: .items processed after .things: how to time/deal with this? [message #1440312 is a reply to message #1440297]

Wed, 08 October 2014 07:47

Dennis Nobel

Messages: 166
Registered: September 2014

Senior Member

Yes, for the actual bindings (yahooweather, hue and lifx) there was no problem, because we update the state periodically. So if the first update was missed, the second update will change the state. But I could imagine bindings where a periodic polling is not appropriate, because it might be too resource-intensive.

Report message to a moderator

Re: .items processed after .things: how to time/deal with this? [message #1440577 is a reply to message #1440312]

Wed, 08 October 2014 14:44

Karel Goderis

Messages: 198
Registered: March 2014

Senior Member

Kai, I just read through the Calimero API: you never considered using tuwien.auto.calimero.buffer in the original OH1.x KNX implementation?

"Support for temporary storage of KNX network messages.
This is done by using a network buffer with one or more configurations added to it. This allows to build up and maintain a local process image to answer user queries. Benefits might be a decreased network load and smaller response time.
Using a network buffer allows polled mode of communication, since handling of incoming messages can be delayed to some later point in time.
A configuration determines what messages to keep and what messages to ignore by the use of filters. These filters might be user defined implementations set for that particular configuration. Two predefined filters are available to allow state based and command based network buffering."

in combination with tuwien.auto.calimero.buffer.StateFilter

"Predefined filter for filtering KNX messages of datapoints with state semantic into the associated network buffer configuration.

This filter might be used in a configuration to build up and maintain a process image of the KNX network the used network link communicates with. The buffer will keep the most up to date state to a KNX group address / datapoint."

Do you happen to know if the Calimero lib is multi-thread safe? e.g. the ProcessEvents delivered by the lib, are they treated in sequence or not?

K

Report message to a moderator

Re: .items processed after .things: how to time/deal with this? [message #1441831 is a reply to message #1439975]

Fri, 10 October 2014 08:46

Kai Kreuzer

Messages: 1
Registered: September 2014

Junior Member

I wonder whether we could make use of the new REFRESH command here - if a link+item exists, the ThingManager could simply call handleCommand(REFRESH) and the binding could send the current status as an event. Good thing is that this mechanism can also be called from rules to send read requests (just as people asked for for KNX 1.x).

Still, this obviously means that the ThingManager has to track a few more things - but this is imho better than having the handlers to do anything additional. Actually, there is a related issue that I would like to solve as well: A handler should have a chance to see which channels are "active", i.e. linked to some item. The reason is that the handlers do not have to do (potentially expensive) operations to send events for these channels, if they are not in use at all.

@Karel, wrt Calimero buffer: No this is indeed not used and I do not really see the need for it - after all, in openHAB/ESH the items are the "buffer" and the binding should communicate with the real world and not add another caching layer in between.

Report message to a moderator

Re: .items processed after .things: how to time/deal with this? [message #1443138 is a reply to message #1441831]

Sun, 12 October 2014 07:23

Karel Goderis

Messages: 198
Registered: March 2014

Senior Member

With respect to KNX I would rather prefer to have a Thing attribute that defines a polling interval (and a polling mechanism) for the Handler, than having to write a Rule that triggers a read request for each read request.

Report message to a moderator

Previous Topic:	Running ESH/OH2 parallel to OH1.x
Next Topic:	Issues Compiling Tests

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 09:40:15 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter