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

Allow normalisation for values sent through RestAPI #3258

Closed
spacemanspiff2007 opened this issue Dec 23, 2022 · 1 comment
Closed

Allow normalisation for values sent through RestAPI #3258

spacemanspiff2007 opened this issue Dec 23, 2022 · 1 comment

Comments

@spacemanspiff2007
Copy link
Contributor

spacemanspiff2007 commented Dec 23, 2022

Since #3247 was either misunderstood or hijacked and is not going to get discussed/in an implementation direction here a follow up issue:

UoM item states can scale based on the commands that get sent to them.
E.g. and item "length" can be either "1 m" but also "3 km".
Small scripts and integrations that use the RestAPI don't implement the UoM and just strip the unit away.
This leads to unexpected behavior.
E.g.
The user implements his script that reads the distance from e.g. work which is reported in km. This works well, however one day the distance gets less and a command with the unit m gets sent.
Since the script strips the unit away it now thinks that the user is 500km away from work when in reality it's just 500m.

To prevent this I suggest we add another parameter that allows normalization for the value that is sent through the RestAPI, SSE Event handler and of course Websockets.

To tackle this I suggest we add another parameter 🙄 that sets the normalization unit and scale.
Until this is figured out using UoM items together with scripts, HABApp and NodeRed can be considered more or less broken.


I still think it would be much more elegant to allow the user to pick the openHAB internal normalization and use this normalized value for persistence, Rest API, etc..
It would make a consistent user experience with no downsides and it would be immediately clear what is going on and how everything will work.

@J-N-K
Copy link
Member

J-N-K commented Dec 29, 2022

Closed, superseded by #3282.

@J-N-K J-N-K closed this as completed Dec 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants