-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[items] ItemHistory: Adjust to breaking changes & Add new methods for future states #331
Conversation
TBD after merge:
|
Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
- Make variance, deviation, average, sum & delta return the state (including unit) as string instead of a number. - Add Until methods for all existing queries. - Add nextState and nextUpdate methods. - Rename historicState method to persistedState. - Remove latestState method. - Remove deprecated evolutionRate method. - Add removeAllStates... Since, Until & Between methods. Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
For consistency, does it make sense to offer |
Would it make sense to return a |
I wanted to ask this question for some hours, but didn't find time until now, and just after posting I saw @rkoshak's similar question. 😄 |
I don't think we'd want to always return a Quantity. If the Item is a plain Number Item there is no unit so a Quantity wouldn't be appropriate in that case. Returning a String by default with options for numeric and quantity maps to other places in the library where a state of an Item is accessed (from the Item or from a HisotricState). |
My proposal is to create a class WDYT? |
Works for me. |
Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
Implemented and tested 👍 |
This adjusts the persistence blocks for the **breaking** changes of `org.openhab.core.persistence.extensions.PersistenceExtensions`. For NashornJS, see openhab/openhab-core#3736 for the changes. For GraalJS, see https://next.openhab.org/addons/automation/jsscripting/#itempersistence for the current API docs and openhab/openhab-js#331 for the changes. --------- Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
The member was renamed from `history` to `persistence` in #331. Signed-off-by: Jacob Laursen <jacob-github@vindvejr.dk>
Refs openhab/openhab-core#3736.
Item::history
toItem::persistence
.HistoricItem
toPersistedItem
and introducePersistedState
for state as string, Quantity & number.PersistedState
instead of number.**Until
methods for all existing queries.nextState
andnextUpdate
methods.historicState
method topersistedState
.latestState
method.evolutionRate
method.removeAllStatesSince
,removeAllStatesUntil
&removeAllStatesBetween
methods.With this PR, support for accessing persistence on openHAB 4.1.x or older will be dropped with the next openhab-js release.
Users should either upgrade openHAB to 4.2.x or stay with the current 4.x.x series of openhab-js.
Since there are no known issues in openhab-js, staying on 4.x.x should be fine.