I’m looking to add a widget that shows the power/energy usage during the last hour, based on an item that stores the cumulative all-time energy usage.
The approach that seems sensible, is to access the persistence/history data directly from the widget using an expression, but I suspect that this is not possible. Maybe because widget expressions really are just ran in the browser on a very limited subset of data, while the persistence methods are available in the server only? I’m not quite sure, since there’s quite a few different types of scripting going around…
In any case, here’s what I tried:
(I added the string concat to show that the result is undefined)
One alternative that I considered (and found mentioned in the forum already) is doing this in a rule, so whenever energy_delivered changes, get the delta over the last hour and store that into a new item. However, this seems a bit wasteful and bad separation of concerns, to add and update a new item which is only used for display and does not store any new information by itself. Or is this a common pattern when using OpenHAB and should I just bite this bullet and add more items and rules?
Yes.
As a generality, what you get on the UI is all about Items, the hidden machinery of Things and real devices (and persistence) is all the server’s business.
What rossko57 states is absolutely correct. But I wanted to elaborate just a bit for clarity on some of the things you stated in the OP.
This is very much true.
This isn’t necessarily true. There is a REST API call one can use to query for data in persistence. But it’s basically “give me all the records between these two times” kind of query. But that means it’s theoretically possible to someday support using historic data in the UI directly. It’s just not supported now.
Items in openHAB are the main thing. Everything uses and everything is represented by Items. If you want to consider OH as using a MVC type architecture (it’s not quite but close enough for this discussion), Items are the Controller. In a traditional MVC architecture, you can’t go straight from the View to the Model without first going through the Controller. Rules, Things, and Persistence are all at the Model layer and Widgets are definitely at the View layer. So if you want a piece of information exposed to the View, it has to be represented in the Controller, i.e. as Items.
Now one could argue that the REST API is the real Controller and that’s where the discussion gets messy. But from the perspective of you as an administrator and developer of a home automation on the openHAB platform, what the REST API provides and how is largely irrelevant. From your perspective, the Controller layer are the Items.
All of that is just to say, don’t be afraid of creating new Items. In this case, Items will be how you expose the persisted data to the UI. It’s OK to have Items that only exists to:
test something out or trigger a rule to test it
hold relatively static configuration data or settings for rules
represent abstract information that is not really connected to a device
hold data to share between multiple rules but otherwise does not get displayed or used anywhere else
hold a large chunk of data (e.g. the full JSON from an HTTP call) that will get parsed by a rule and used to update a number of other Items
hold the result of a query from the database or a calculation and whose only reason for being is display
I’m sure there are more indirect uses for Items that I’ve not listed.
Plenty of people could argue whether this is the best architecture but all I can offer is this is how openHAB works now. And in my opinion it works pretty well.
Thanks for your answers, all the additional detail and background helps me to understand how OpenHAB is intended to work. I guess I should indeed be less hesitant to create additional items, then
However, one reason I am hesitant, is that it seems good to not introduce duplicate data into the system (I’m counting data that could be derived from other data as duplicate for the purpose of this discussion). An obvious fix for this would be to have “virtual” items, so you define an item usable by the rest of the system, but rather than storing data for it explicitly, you define how the value can be derived and have the system automatically derive the value as needed.
I guess that the current system of a regular item with a rule to automatically set its value can be seen as such a virtual item, but a significant downside of this approach is that the history of such an item must be explicitly stored. Ideally, such a virtual item would store no data at all, and its data would be derived dynamically when needed (needing less storage, and making it super-easy to add a derived item later, without needing manual work to generate its values in the past). I guess something like this is quite non-trivial to implement (especially if it needs to be portable across persistence layers, i.e. if the definition of such a virtual item could be e.g. InfluxDB-specific using InfluxDB queries, things might be more feasible), but it sounds like a nice idea…
In any case, I’ll just go ahead and implement this with a separate item and a rule to populate that item with data, thanks again for your quick responses!
I suppose one thing to realize and remind yourself of over and over is that “HAB” in openHAB stands for “Home Automation Bus”. It’s not a data analysis platform. It’s not an industrial control platform. If there is a conflict between something that runs a few hundred msec faster and something that is easier for most users to understand, the latter is always going to win. If there is a conflict between adding a cool feature that only really advanced users can use and keeping the interface consistent and uniform the latter will usually win out.
So in this case, the fact that you will have to store a few MB per year to keep the history of a calculation is probably acceptable compared to creating a whole new interface and way of using and presenting information from OH.
But, as with anything in an open source project, code speaks louder than a forum post. But as someone who’s primary contributions to this project involves helping users with problems, I clearly see how maintaining a consistent interface is huge in terms of usability.
