Expressions Items not accessible

I couldn’t say. My understanding is if the pattern is defined there should be a displayState.

@ysc ,

have you come this behaviour?
Is this working as designed?

Thank you.

Yes it’s intended. The displayState is only defined when there’s a transform to perform on the state (either a pattern or an addon-provided function) to save some data on the SSE event stream.
You can use the items.Item1.displayState || items.Item1.state syntax if you’re not sure displayState will be defined.

@ysc just to confirm, displayState should only be defined when

  1. There is some sort of state description or transform defined
  2. The result of executing that transform produces a different string value than what is contained in state?

If so that makes more sense. Thanks for any insight you can offer.

I’d be curious about that too.
It’s not Schrodinger’s displayState, both exist and doesn’t exist depending not on the state , nor the the format/transform applied, but on the output of the format/transform happening to match the raw state string version.

Say we have a simple format .0f on a number

state   displayState
3.14     3   hurrah
3.0      3
3        null      huh?

Yes, or state options:

Yes:

This causes quite some confusion, I think this is somewhat unexpected behavior.
Wouldn‘t it be better to always include displayState? This shouldn’t require too much extra processing, should it?

Maybe, it was omitted if it was redundant to minimize the data going through the SSE stream, but your point is equally valid.

Thanks for the confirmation and source code references, that makes everything make a lot more sense.

My general impression is this simply ends up putting more burden on the UI templates and expressions since every place we want to “pretty print” a state value we now need to use item.displayState || item.state.

It’s not that hard to do (especially using best practices such as decomposing things into widgets) but in the pages I’ve built so far my impression is it adds a lot of clutter to yaml files.

Comment; it makes sense not to transmit displayState when there is simply no format or transform being applied to raw state.
It doesn’t seem to save much to transmit it for 95% of the time and drop it when displayState happens to match raw state.

The decision to transmit or not (in core) really needs to look elsewhere, is there a format/transform actually being applied?
I suppose a Quantity units “auto conversion” counts here, where we might have a unit in say W and display kW

Might also need to take into account what should happen if a format/transform fails, what should GUI get for an error condition?

Maybe in the real world, most Items end up with active ‘pattern’ anyway so there isn’t much to be gained here after all?