Skip to content
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

Merged
merged 10 commits into from May 5, 2024

Conversation

florian-h05
Copy link
Contributor

@florian-h05 florian-h05 commented May 1, 2024

Refs openhab/openhab-core#3736.

  • Rename Item::history to Item::persistence.
  • Rename HistoricItem to PersistedItem and introduce PersistedState for state as string, Quantity & number.
  • Make variance, deviation, average, sum & delta return the state as PersistedState instead of 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 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.

@florian-h05 florian-h05 added enhancement New feature or request breaking change API breaking changes labels May 1, 2024
@florian-h05 florian-h05 added this to the to be released milestone May 1, 2024
@florian-h05 florian-h05 requested a review from a team as a code owner May 1, 2024 22:55
@florian-h05 florian-h05 changed the title [items] ItemHistory: Adjust to breaking core changes & Add new methods for future states [items] ItemHistory: Adjust to breaking changes & Add new methods for future states May 1, 2024
@florian-h05
Copy link
Contributor Author

TBD after merge:

  • Update Blockly code generation.
  • Update openhab-js tern defs.

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>
@rkoshak
Copy link
Contributor

rkoshak commented May 2, 2024

Make variance, deviation, average, sum & delta return the state (including unit) as string instead of a number.

For consistency, does it make sense to offer numberAverage and quantityAverage (et. al.) same as we have in Item for accessing the state? HistoricState already has those options too so it feels reasonable to expect there to be options for these persistence queries too.

@jlaur
Copy link

jlaur commented May 2, 2024

  • Make variance, deviation, average, sum & delta return the state (including unit) as string instead of a number.

Would it make sense to return a Quantity instead of a number? I guess in most cases the returned string would be used for creating a Quantity?

@jlaur
Copy link

jlaur commented May 2, 2024

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. 😄

@rkoshak
Copy link
Contributor

rkoshak commented May 2, 2024

Would it make sense to return a Quantity instead of a number?

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).

@florian-h05
Copy link
Contributor Author

florian-h05 commented May 2, 2024

My proposal is to create a class PersistedState or HistoricState inside the helper library, which has the same properties as https://openhab.github.io/openhab-js/items.HistoricItem.html but obviously without timestamp, and have the current HistoricItem just extend this class.
This way it is easily possible to get the state in different formats.

WDYT?

@rkoshak
Copy link
Contributor

rkoshak commented May 3, 2024

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>
Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
@florian-h05
Copy link
Contributor Author

Implemented and tested 👍

@florian-h05 florian-h05 merged commit cd3fc4e into openhab:main May 5, 2024
4 checks passed
@florian-h05 florian-h05 deleted the persistence branch May 5, 2024 19:50
florian-h05 added a commit to openhab/openhab-webui that referenced this pull request May 7, 2024
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change API breaking changes enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants