Expressions Items not accessible

with the expression tester I cannot show as much options. so I tried the best with a page card


the orange card on the left shows the evaluated values which are all … unavailable or “-”

What options are you trying to show? It’s an expression tester. It tests the expressions. It shows what an expression returns. That’s what we want, right?

That’s exactly what we want to see with your “Otter_Absence” Item. Also note that the preview of a page while you are editing it does not update as the Items change state. Sometimes they don’t even show the current state when you first add them to the Page or as you make changes in then Custom Widget creator. You need to manually refresh to see updates and such. That’s why the Developer Sidebar is better for this sort of thing. As it is I can’t tell if it’s not working because it’s not working or because you haven’t refreshed.

see, that’s what I wanna show BUT
OH-ItemExpression

It’s the very same when using the dictionary syntax =items[“Otter_Absence”]

to clarify: I refreshed, I restarted openhab service, I changed browser - nothing:
the red scribbles the state of Otter_Absence:
OH-Page-Web

Meanwhile / on my android app:


so I looked in my firefox on mobile with the same result as the app… it presents the good result (as the Item state is 2 in the morning / believe me)

I restarted openhab, flushed browsers cache on my windows client and it still does not know about the state. now I do not feel dumb any more - but the error is somewhere out there. I have nothing in my openhab logs - where can I have a look to investigate further?

But that’s also the same result one gets if the Item exists but it’s state is NULL or UNDEF. So that’s not necessarily a good test for whether or not the Item exists. But it is informative.

If it’s showing in some browser/app but not other’s then the problem lies somewhere in the UI or the browser itself (perhaps an extension is blocking the SSE feed for example). At this point the best I can offer is to file an issue on the openhab-webui and gather logs from the browser.

On chrome, if I come back to a OH page I’ve left open for a while, I often find that I have lost the SSE feed. A page refresh is usually sufficient, though that doesn’t seem to be the case here.

What do you see if you click on the second button on the developer siderbar (the ~ image) and then press the Stream Events button?

What do you see in the sessions list if you click on the profile link in the bottom of the left panel?

I always asked myself what these Events are about and when do they appear bc I never get any. I clicked as you described and followed some links in the UI afterwards but not any event showed up. It is completly empty / what does this mean?

thats a good point! I used Firefox with a bunch of extensions and restrictions and MS Edge (chrome based) with default settings on . finally I installed chrome itself / all with the same result: missing state information of my items.
Maybe it’s some kind of firewall or so. to clarify: I use the same local adress from mobile phone (which works) and from windows client (which does not work). I’ve lost my SSL certificate so I will regenerate it and will try the remote address to check for differences

That’s crazy! on the windows machine it works in any browser when I use https (which I do mostly - but I was too lazy to repair the ssls).
OH-ItemSuccess

So I can close this issue and warn everybody to use the http port / even for testing!

Thank you for this very useful workaround when .displayState is unavailable for whichever reason.

One thing I don’t quite understand is the following:
.displayState becomes unavailable when .displayState would return the same result as .state.

See the following example:

Windboe1
Windboe2

with “%.0f %unit%” applied as stateDescription

How come .displayState does not return anything? Is this a bug?

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.

1 Like

@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?