Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse SmartHome » Thoughts on extending Item properties
Thoughts on extending Item properties [message #1339010] Wed, 07 May 2014 13:24 Go to next message
gael lhopital is currently offline gael lhopitalFriend
Messages: 3
Registered: May 2014
Junior Member
I wanted to suggest additional properties to GenericItem on the openHAB group, and was told that this was the right place...hope it is Smile

I'd like to add the following properties on GenericItem :
- Calendar lastChange : timestamp of the last State change
- Calendar lastUpdate : timestamp of the last State refresh (wether changed or not)

These informations may currently be difficult to find throught the persistence mecanisms (and even for non persisted items, it's a value).

The counterpart of these introduction would also be to have
- int updateFreq : period (in msec) on wich at least one update is awaited

This also introduces another notification type, to be held by dedicated rule :
rule testOutdated
when Item outdated
then
' do whatever you need when an item has not been updated
' during a certain time
end

I've made all the needed modifications on a forked version of openHAB and it seems to work great.
Your comments ?
Re: Thoughts on extending Item properties [message #1342103 is a reply to message #1339010] Thu, 08 May 2014 20:07 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 85
Registered: December 2011
Member
Hi Gael,

Yes, you are at the right place!

In order to evaluate your suggestion, I would like to ask you for the concrete use cases for which you need these properties.
From the rule syntax, I assume you want to notice, if a device stopped working correctly and might have gone offline (not sending any more updates). I actually would not like to see such things "leaking" from devices to the item model. Only the binding should imho deal with communication details and possible failures.

Another question would be: Where would these properties make the most sense to you? Does it have to be the GenericItem (i.e. a specific implementation)? Or the Item interface itself? Or maybe it could be a new feature of the ItemRegistry only? Or maybe rule extensions, so that according methods are available that way? You see, there are many options and I would like to understand for which situations it would be helpful.

Cheers,
Kai
Re: Thoughts on extending Item properties [message #1343740 is a reply to message #1342103] Fri, 09 May 2014 12:36 Go to previous messageGo to next message
gael lhopital is currently offline gael lhopitalFriend
Messages: 3
Registered: May 2014
Junior Member
Hi Kai,

Here are the informations that may help you figure out my proposal.
I'm currently using openHAB in my whole house, especially to manage my furnace depending upon many sensors (I posted my scripts on openhab google group). Reference sensor may change depending upon the day time, and are currently based on different binding (onewire, netatmo, oregon over xPL). On my daily usage, to check that everything is working fine, I'm always wondering when was the last time a value have been refreshed. Not due to communication issues at binding layer, but more to script correct/expected execution - reason of the lastUpdate property need.

The card may be expressed as : "as a end user of habDroid, I want to know the age of every displayed value".

To fully use this property, associating it an update frequency, and the related event was quite straitforward. By the way, I think that reacting to an outdated value can not really be handled at binding level - as the notification mean (send an sms or an XMPP message) is only known/accessible at scripting level.

This is also a mean to control bindings correct execution : what guaranties me that the http binding, expected to refresh weather Items every 10mn really does it (silly example, I agree)? If not, I must be warned to investigate and take needed corrective actions as my other scripts rely on this exepected behaviour/refresh rythm of Items.

On a second hand, it's quite common to wonder until when the furnace is ON. For sure, it can be handled in scripts, using local variables or Items, or throught a persistence layer iteration, but this leads configuration files to many overhead evelements (*) that could be natively taken by the underlaying framework. Reason for the lastChange property need. I thought that as an Item helds a State, it's quite logical to associate a timestamp to the state change.

I'm not experimented enough in openHAB to say wether these properties should be located at GenericItem, Item, ItemRegistry level (I made my test fork on GenericItem, but it may not be the better place). I started in Java a month ago, developped some binding, and now starting to dig into core elements...reason why I'm here writing the above post Smile

Thanks to have taken a bit of time on this.
Cheers


(*) : from my current experience of openHAB, I'm currently facing a multiplication of Items, Persistence definitions, scripts and rules in order to handle off-side elements and it's becoming quite diffult to maintain.
Re: Thoughts on extending Item properties [message #1366578 is a reply to message #1343740] Mon, 19 May 2014 11:26 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 12
Registered: December 2013
Junior Member
There are ways of doing what you want in openHAB now. I have configured a bunch of extra items, and some rules, that allow me to keep track of sensor updates. Adding 'last update time' to the item has been discussed, and rejected, previously...

However....

gael lhopital wrote on Fri, 09 May 2014 08:36

(*) : from my current experience of openHAB, I'm currently facing a multiplication of Items, Persistence definitions, scripts and rules in order to handle off-side elements and it's becoming quite diffult to maintain.

This is the killer for me. Yes, it's possible to add more items with the last update time, or the average in the past 24 hours, or the max since midnight or... This is all ok, but it's actually a maintenance nightmare. If I want to have these stats, then I need LOTS more items, and if I want to change something about the main item (eg it's name) then I need to change lots of places, and this (I think) makes a bit of a mess.

So, I would agree there needs to be some sort of extensible way to add 'properties' to an item (and here I talk about this from the user perspective - not how it's implemented). Under the hood, maybe we keep separate items, and they are managed 'collectively' another way (maybe this is grouped into a 'Thing' as per the 'thing' concept?). Under the hood it doesn't matter how these extra 'items' are managed - ultimately they are all separate values that need to be managed - they just need managing collectively by the user, and presented in a managable way in the UI.

I had a feature in HABmin that provided some support for this - you could click a button and the GUI would make a new item, and generate a rule to provide the last update, or the maximum today etc. This is part of the problem, but we still end up with a load of 'unlinked' items. I know we could do something with groups to provide that link, but it's messy and non-standard.

Kai - maybe you can comment if the 'Thing' concept can cover this? I'm afraid I've not quite got my head around it yet Sad If not, then we should consider this further I think.

Cheers
Chris
Re: Thoughts on extending Item properties [message #1376067 is a reply to message #1366578] Fri, 23 May 2014 08:44 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 85
Registered: December 2011
Member
Gael,

I still think you are trying to mix two separate things:
1. The binding operation itself, where you want to know if it works as expected and you need to do exception handling.
2. The modelled item world, which is used in scripts and rules.
Note that these two things are strictly kept independent in the Eclipse SmartHome architecture.

For 1, I agree that we will need some notification mechanisms to let bindings provide information about problems.
For 2, all information about last update, average values over time etc. can be provided through the extension mechanism for items. Just as it already exists with itemName.averageSince() etc. There is imho no need to put this information technically into the items.

@Chris: I think the multiplication of items is a slightly different topic. As long as you only need the information inside rules, you do not need any items for them, local variables will be just fine.
The problem currently starts as soon as you want to display this information in UIs - because then you need to have distinct items for each value to display. For our "generic" UIs that make use of sitemaps, I think this makes sense as it is most flexible in terms of letting the user choose the layout and the information to display. For more specific UIs (like HABmin), i could imagine that we provide additional information through the REST API (possible in the context of https://bugs.eclipse.org/bugs/show_bug.cgi?id=423547), i.e. similar to what the extensions do in the rules.

WRT the "Thing" concept, this will not help here as the Things are only meant to be used for the setup and configuration of the system, but not within rules or (non-admin) UIs.

Best regards,
Kai
Re: Thoughts on extending Item properties [message #1376768 is a reply to message #1376067] Fri, 23 May 2014 15:19 Go to previous messageGo to next message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 12
Registered: December 2013
Junior Member
Kai Kreuzer wrote on Fri, 23 May 2014 04:44

@Chris: I think the multiplication of items is a slightly different topic. As long as you only need the information inside rules, you do not need any items for them, local variables will be just fine.

Hmm - unfortunately though I want to see these values in the GUI - it's the same as you have in the default sitemap which if I remember correctly is generated by rules. ie, I want to know the time of the last rain (so I know when to water the plants) or the maximum/minimum temperature since midnight, or the last update time. These are all things I currently show in HABdroid and I have items for all of them.


Kai Kreuzer wrote on Fri, 23 May 2014 04:44

The problem currently starts as soon as you want to display this information in UIs - because then you need to have distinct items for each value to display. For our "generic" UIs that make use of sitemaps, I think this makes sense as it is most flexible in terms of letting the user choose the layout and the information to display.

Ok, so this means that we have LOTs of items - again I personally think that this is quite a problem but maybe that's just me an is limited to the way I use the system?


Kai Kreuzer wrote on Fri, 23 May 2014 04:44

For more specific UIs (like HABmin), i could imagine that we provide additional information through the REST API (possible in the context of https://bugs.eclipse.org/bugs/show_bug.cgi?id=423547), i.e. similar to what the extensions do in the rules.

Interesting idea - and you're right this would allow 'other' interfaces to use the data, but it seems a bit shortsighted to limited this sort of information to only being available in 'special' interfaces (doesn't it?).

Cheers
Chris
Re: Thoughts on extending Item properties [message #1383946 is a reply to message #1376768] Tue, 27 May 2014 10:59 Go to previous messageGo to next message
Kai Kreuzer is currently offline Kai KreuzerFriend
Messages: 85
Registered: December 2011
Member
Chris Jackson wrote on Fri, 23 May 2014 17:19

Kai Kreuzer wrote on Fri, 23 May 2014 04:44

For more specific UIs (like HABmin), i could imagine that we provide additional information through the REST API

Interesting idea - and you're right this would allow 'other' interfaces to use the data, but it seems a bit shortsighted to limited this sort of information to only being available in 'special' interfaces (doesn't it?).

Well, you could also say that HABDroid or other UIs provide you a way to display this information. My point is that I doubt that it makes sense to always display it for each and every item - it would rather clutter the UI. Then again, you would have to introduce new constructs in the sitemaps in order to define, what should be displayed how for which item.

Regards,
Kai
Re: Thoughts on extending Item properties [message #1383955 is a reply to message #1376067] Tue, 27 May 2014 12:18 Go to previous messageGo to next message
gael lhopital is currently offline gael lhopitalFriend
Messages: 3
Registered: May 2014
Junior Member
Kai Kreuzer wrote on Fri, 23 May 2014 04:44
Gael,

For 2, all information about last update, average values over time etc. can be provided through the extension mechanism for items. Just as it already exists with itemName.averageSince() etc. There is imho no need to put this information technically into the items.



Hello Kai,

this way of handling extension for items is completely fine to me. I'll search how to.
Thanks.
Re: Thoughts on extending Item properties [message #1384173 is a reply to message #1383946] Wed, 28 May 2014 10:11 Go to previous message
Chris Jackson is currently offline Chris JacksonFriend
Messages: 12
Registered: December 2013
Junior Member
Kai Kreuzer wrote on Tue, 27 May 2014 06:59

Well, you could also say that HABDroid or other UIs provide you a way to display this information. My point is that I doubt that it makes sense to always display it for each and every item - it would rather clutter the UI. Then again, you would have to introduce new constructs in the sitemaps in order to define, what should be displayed how for which item.


Yes, for sure - is this a problem?

To me, it seems to be a better approach than creating lots of different items and trying to maintain them. Why (for example) couldn't we have a sitemap construct of item=item_name for the item (as now), with item_name.whatever for the extension such that rules can set item_name.whatever = 123? This could then be applied to the last update time, or the maximum in 24 hours or whatever without having to expose new items for every possible option.

To some degree, this is similar to the approach you've suggested below -:

Quote:

For 2, all information about last update, average values over time etc. can be provided through the extension mechanism for items. Just as it already exists with itemName.averageSince() etc. There is imho no need to put this information technically into the items.


From the user perspective, what I'm suggesting is effectively the same (and as I said in my original post - I'm only looking at this from the user perspective - implementation is another matter). This allows the user to effectively set their own 'item extensions' by defining properties in a rule rather than having to define this as a java extension (which may also be needed/useful in some cases).

Obviously this is just my personal preference, but I think that linking these extensions together in this way, and exposing them to the UI is a nicer approach than having to create lots of individual items.

Another example (although you may consider this a separate issue Smile) is if I wanted to calculate a rule using a constant value - eg if I wanted to know the power consumed in a light with a dimmer, I could set up a rule to multiply the dim value by the maximum power of the bulb. I would like to be able to set two 'item extensions' - one that set the maximum power, and the other that provides the current power. Then, in my rule I just have -:
item.current_power = item.state * item.max_power.

I know I could do something similar at the moment by using separate items, but again, this is a management mess (in my opinion). By making these all related to the item in this way, we can present this information easily to the user - when they update the bulb, they click on the item and can change the wattage - it's all nicely linked.

I also understand that the above could be considered as encroaching into the domain of persistence as we're potentially storing data in the item. Again, my view is from the user perspective at this point - how it's implemented is a different question (and could use the persistence system).

Sorry - I've probably extended the discussion past what was originally Gaels question... However, the stated focus of OH2/ESH is to improve the user experience - in my opinion some thought on the above topics in order to consolidate how items (etc) appear from the user perspective is required.

Cheers
Chris
Previous Topic:OpenHAB2 and SmartHome dependencies and build structure.
Next Topic:RfC: New Thing concept
Goto Forum:
  


Current Time: Thu Dec 18 08:37:56 GMT 2014

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

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