Add numericState and unit to StateDTO

[jimtng]

This would avoid having to use parseFloat for item state by making the numericState readily available.

[jimtng]

@rkoshak

[spacemanspiff2007]

What if it's an integer? Will this still return a float? If so could you make it an integer?
What about websockets? Do you think we should add it there, too?
Just do double check - will this affect the ItemStateChangedEvent, too?

[jimtng]

What if it's an integer? Will this still return a float? If so could you make it an integer?

There seems to be no distinction in json
https://json-schema.org/understanding-json-schema/reference/numeric

What about websockets? Do you think we should add it there, too?

Where is this used?

[jimtng]

Just do double check - will this affect the ItemStateChangedEvent, too?

This is purely for the MainUI SSE.

[spacemanspiff2007]

My concern is not the json schema description but rather the returned value.
But wouldn't decimalState.floatValue(); always return a float value even if it's an integer?
E.g. openHAB state 1 would be 1.0 in the event.
Because even though the schema concerns it as an integer the json parser still returns a float.

This is purely for the MainUI SSE.

Is this different from the sse subscription HABApp uses?

Where is this used?

It's still on my never ending todo list to switch from SSE to websockets.
It just requires a huge refactor in how HABApp handles all connections and events so it takes way longer than anticipated.

[jimtng]

decimalstate is never really just an integer. It is stored as BigDecimal.

I tested this with a Battery level, and I got 100 (without decimal points) in the UI.

Is this different from the sse subscription HABApp uses?

I'm not sure what HabApp uses. This is alongside the existing items[xxx].displayState, whereever that may be used. It is not in the standard ItemStateChangedEvent etc.

@ghys and @florian-h05 understand this better than I.

It's still on my never ending todo list to switch from SSE to websockets.

I've seen somewhere that MainUI is also going to switch to websockets, eventually

[spacemanspiff2007]

HABApp subscribes to /rest/events so I guess it should be similar but I am not sure

This is the event how I get it at the moment

{
    "topic": "openhab/items/Length_event_test/stateupdated",
    "payload": {
        "type": "Quantity",
        "value": "222 m"
    },
    "type": "ItemStateUpdatedEvent"
}

As you can see currently an integer is returned (222) and not a floating point number (222.0).
So I would expect the numericState field to behave similarly.

Now that I look at the events the names are different (values vs state) so it seems that these are indeed different events and ways how they are emitted.

It would be very helpful nonetheless if it would be like this so I'd love to see a PR that changes these events, too.

{
    "topic": "openhab/items/Length_event_test/stateupdated",
    "payload": {
        "type": "Quantity",
        "value": "222 m"
        "numericValue": "222",
        "unit": "m",
    },
    "type": "ItemStateUpdatedEvent"
}

Because currently I have to transform 222 m into 222 programmatically.

[florian-h05]

This PR only changes the Item States SSE stream, which is located at /rest/events/states and is used by the UI to keep track of the Item states.

/rest/events is the generic event stream that provides read access to the event bus, this is also used by the UI, e.g. on the rule edit page to track the rule status.
If the Item events /rest/events should provide additional information, the ItemEventPayloadBean and probably other ItemEvent***Beans as well as the ItemEventFactory need to be updated. But IMO this is something for another PR.

[spacemanspiff2007]

Thank you for the clarification!

[florian-h05]

LGTM, thanks!

After this PR has been merged, please update the docs accordingly: https://next.openhab.org/docs/ui/widget-expressions-variables.html#expressions-overview.

[rkoshak]

I'm not sure if I have anything to add here. It seems like a good idea to me and will make expressions in widgets at least a bit shorter if not easier to manage.

[jimtng]

I'm not sure if I have anything to add here. It seems like a good idea to me and will make expressions in widgets at least a bit shorter if not easier to manage.

Your approval means a great deal!

[J-N-K]

LGTM, thanks!

[lolodomo]

Is it backward compatible? Only new fields added ?
If I am not wrong, the remote openhab binding relies on this API.

Edit: looking at the code change, I have my answer.

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/floor-map-iconrotation-from-item-state-does-not-work/155240/5