Home » Archived » Eclipse SmartHome » Thoughts on extending Item properties
| |
| Re: Thoughts on extending Item properties [message #1343740 is a reply to message #1342103] |
Fri, 09 May 2014 12:36   |
 gael lhopital
Messages: 6
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 
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 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior 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  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 |
Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior 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 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior 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 #1384173 is a reply to message #1383946] |
Wed, 28 May 2014 10:11 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior 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 ) 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
|
|
|
Goto Forum:
Current Time: Tue Apr 23 17:29:44 GMT 2024
Powered by FUDForum. Page generated in 0.03636 seconds |
] 
Search
Help
Register
Login
Home
