openhab / openhab-webui

Web UIs of openHAB
Eclipse Public License 2.0
212 stars 232 forks source link

Milestone 4.2.0.M2: Warnings "Attempting to send a state update of an item which doesn't exist" when opening location tab #2530

Closed michaeljoos72 closed 3 weeks ago

michaeljoos72 commented 1 month ago

The problem

Not sure if this is the correct category (webui). I updated from 4.2.0.M1 to 4.2.0.M2 and see now these warnings every time I open a location card:

10:17:39.369 | WARN | e.internal.SseItemStatesEventBuilder | Attempting to send a state update of an item which doesn't exist: __v_isRef
10:17:39.368 | WARN | e.internal.SseItemStatesEventBuilder | Attempting to send a state update of an item which doesn't exist: __ob__

This is happening in Browser and in Android-App. This warnings I have never seen in 4.2.0.M1. Also other user did confirm in Forum: https://community.openhab.org/t/openhab-4-2-milestone-discussion/154316/91?u=michaeljoos

Expected behavior

No warnings in logs when I access location cards

Steps to reproduce

  1. Open location card in MainUI
  2. Check openhab.log for above errors

Your environment

Raspi4 and openHAB 4.2.0.M2 (openhabian)

JustinGeorgi commented 1 month ago

see now these warnings every time I open a location card

This is not widespread, so there's something in your system that is triggering this problem. I just opened every single location card in my model and did not get any such errors.

Without most people being able to replicate this, tracking it down is going to be difficult.

1) does it happen with every one of your location cards, or just some of them? 2) do you use any custom default list item widgets? 3) does it also happen with any of the other model cards (equipment or properties)?

rkoshak commented 1 month ago

I think this got fixed but it used to be the case that if you had an orphaned link the Item will still appear to exist in some parts of OH. The warning happens when a UI widget references an Item that doesn't exist.

Open http://<hostname or IP of openHAB>:8080/rest/links/orphans and if it says "Sorry, Requested content not found" that means there are no orphans. If it lists some stuff that means you have some orphans which might be a cause.

You can remove the orphans by posting to http://<hostname or IP of openHAB>:8080/rest/links/purge.

You can also do this through the karaf console:

openhab:links orphan list
openhab:links orphan purge
michaeljoos72 commented 1 month ago

OK, I have analyzed a bit more and I was wrong with "...every time I open a location card". I get this errors when opening the location tab itself. The Problem seems to be with the badges! As soon as I disable all the batches I don't see any warnings:

image

It doesn't matter what batch I enable. Temperature, Humidity, Open Windows, CO2, Blinds, Presence. As soon as one of them is enabled I see these errors. I have tried this with only one single room. This definitively is new in 4.2.0.M2.

openhab:links orphan list does not give any results. So this looks good :)

rkoshak commented 1 month ago

Somehow and somewhere it's getting two Item names, names which frankly make no sense: __v_isRef, and __ob__. These look a whole lot like internal variables of some sort. Maybe searching for those Strings in the relevant code can shed some light on the situation. Somehow those are finding their way into an Item reference in the UI code.

JustinGeorgi commented 1 month ago

The Problem seems to be with the badges!

If it's the badges that are causing the issue then, metadata might be a more likely candidate than links. Badges use the semantic metadata to identify the items that trigger the badge display. If you have an improperly configured item in your model, or perhaps some left over metadata that points to an item that no longer exists, that would probably give you this error.

Do you use UI or file based item config?

michaeljoos72 commented 1 month ago

Do you use UI or file based item config? Everything UI based.

I have checked json files in /var/lib/openhab/jsondb and also compared with the ones in backup folder, but I couldn't find anything wrong. Then I have downgraded to 4.2.0.M1 and errors are gone. Back on M2 with exactly same configuration and errors are there again.

So, there was definitively a change between M1 and M2. This is really weird and not sure if I have somehow a "special setup" or combination. Also other user did confirm this error (see above link). So, I'm not alone with this errors but I'm out of ideas what could be the root cause.

JustinGeorgi commented 1 month ago

So, there was definitively a change between M1 and M2.

Quickly skimming through the M2 -> M1 comparison, I don't see any obvious candidates.

I wonder if this is instead a change in the core. The error, after all, is a core error and the SSE did get the numericState change for 4.2

https://github.com/openhab/openhab-core/blob/main/bundles/org.openhab.core.io.rest.sse/src/main/java/org/openhab/core/io/rest/sse/internal/SseItemStatesEventBuilder.java#L91-L97

If you have an old numeric item that has not been properly updated with the correct units, then a failure of the getUnit() call would throw an error. That was not a kind of error the catch statement was made to handle, so you're being thrown off by an incorrect error description (this would also explain the unusual item 'names' because that is not the kind of error that catch is expecting).

Maybe @jimtng can take a quick look and confirm or shoot down my hypothesis.

JustinGeorgi commented 4 weeks ago

An interesting development: I just updated (for unrelated reasons) to snapshot build 4038 and I now see the same warning when I open the locations tab.

This may be more general than your configuration. I still suspect it's related to the change in the Sse Item States, but I don't any proof.

michaeljoos72 commented 4 weeks ago

OK, at least good to know that it is not only in my setup. 2 days ago I tried to reduce to a minimum:

The warnings were still there. The only way for me to get rid of this was to completely disable the badges.

florian-h05 commented 3 weeks ago

Hmm, this issue occurs exactly after #2489. I don't know the root cause, but I think I found a suitable solution/migitation for the issue: #2540.