-
-
Notifications
You must be signed in to change notification settings - Fork 243
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
Settings -> Items keeps refreshing when items are added by rules, making it impossible to use. #2819
Comments
For starters this is probably an anti-pattern. It's defnintely not an expected way to use Items. Alternatives include Item metadata, the shared chache, and a generic storage registry that can be accessed from rules (I've done it once but can't remember how I did it and would have to look through my git history to find it, assuming I ever checked it in). Item metadata and the registry are permament and the cache is ephemeral (i.e. it gets cleared on an OH restart). I'm not saying that there are not improvements that may be needed for the Items page. It should handle new Items being created better than this. But your specific use case I am certain is far beyond anything that the Items settings page was designed to handle. In architectural terms, Items are expected to be reltaviely static and permament. You are not adding and removing devices once per second in a typical home environment. But I am saying that the Items settings page may not be the only place you run into problems with Items changing like this this fast. |
I know Items are not ideal for this. The only reason I am doing this is as a work around because the shared cache is broken too (see openhab/openhab-core#4413). Using Items appears to allow me to avoid triggering concurrency issues in JavaScript when multiple rules in multiple threads are trying to communicate.
Bugs are always found in edge cases or they would not end up being shipped in release :).
The repro steps make the problem as easy to reproduce as quickly as possible. If you do this every few minutes or so, you will still encounter the issue, just less often. I highly doubt anyone else that experiences it will understand what is going on and report it: it's likely to happen only very occasionally at random times and does not have a clear cause or error report to help understand what happened.
I do hope that the code is reliable and doesn't break in unexpected ways if I do anything slightly different than most users. I've tried many other home automation platforms before openHAB and moved away from each because they were unreliable and didn't provide any useful feedback when things didn't work. |
This is a limitation of GraalVM JS. It simply does not support multithreaded operations, full stop. However, JS Scripting is the only rules language with this limitation. Rules DSL, Groovy, jRuby, and even Jython are alternatives that do not have this limitation. You can avoid this problem now by using a different rules langauge. Note that Blockly "compiles" to JS Scripting.
We do our best but if that's not good enough for you 🤷♂️ . It's an all volunteer effort and we do not begrudge anyone choosing another solution if that works better for them. |
Thanks, I'll have a look. I may try to create a stub or wrapper to access things from JavaScript through one of these languages. I'm hoping to work around this issue without having to learn a new programming language and porting all my scripts.
I did not mean to offend. I was simply surprised at your suggestion that openHAB is not reliable. I've found openHAB to be much more reliable than other options I've tried and the few issues I did find so far were reasonably straight forward to root-cause and reproduce, and understandable oversights from a programmer's point of view. Nothing so far suggested that I would run into problems if I used its features slightly differently than the average user. I'm hoping this is an exception :) |
That’s not really how it is supposed to be used … but I understand why you do.
It is just reloading the list if a Item was added, updated or removed. While loading, the loading skeleton is shown. As long as people don’t add and remove Items dynamically, I haven’t heard somebody complaining about this before. That being said this doesn’t mean there is no room for improvement.
That shouldn’t happen and needs to be fixed.
Expected behaviour, but of course not good. |
I did not suggest OH is unreliable. But it definitely has a specific context in mind in how it's designed and built. If you go outside of that intended use YMMV. It may work great, iut may completely blow up.
This isn't something that most people do that much. Usually when they do it's at load time of the rule(s) and not periodically after the rule has loaded and it usually "create this Item if it doesn't exist", not create this Item and destory this other Item kind of thing. So this behavior in the UI wouldn't be noticed. I agree there is room for improvement here in MainUI but I also think that using Items in this way should not be encouraged. We have lot of other options for storing ephemeral data like this which should be less disruptive overall compared to dynamically creating and destroying Items all the time and if any of those are not working as they should, we should address that use case there. Maybe I do need to go back and see how to access and use the generaic data registry and add using that to the docs somehow. I'm assuming registry access is already thread safe so JS shouldn't have any problem with that like it currently does with the cache. |
The refresh button is there to allow a manual refresh for updating the Item states. As Items are not supposed to be added and removed dynamically from scripts, the automatic refresh is no problem normally. I won't change that behavior therefore.
Just looking into this issue, and I cannot reproduce it at all, i.e.
this is working exactly like that for me.
As the search has to be re-initialised on refresh to properly work, this cannot be fixed. TLDR; This is a won't fix, as this is only occurring when Items are used in "unsupported" ways. Let us rather focus on solving the root problem to avoid Item use in unintended ways. |
If the list is not expected to change, why is it even auto-updating at all? It seems like removing the auto-update feature would fix my issue and not affect anyone, since nobody is supposed to be doing this.
That is weird. Why could this work for you but not for me? I don't think a bug should be closed because it cannot quickly be reproduced be a single developer. But this is not an issue I care about enough to argue about too much.
It sounds like the "seach" input element is part of the refresh, when there is no reason for that. Only the list needs to be refreshed: the search input element can remain in place and allow the user to continue entering chars while the list is being updated. Once the updated list is retrieved from the server, the current value of the input field should be applied. But this is also not an issue I care about enough to argue about too much. |
All lists are auto-updating, this has been that way when I joined the UI development - so I cannot say why it was decided to be that case. I think I can offer a compromise here: If the list changes, show a toast at the bottom of the screen asking if you want to reload.
Which openHAB version do you use?
I am currently working on that ... I cannot fix this, as we have to re-render the searchbar which is an external library component. |
Well, I would mark these as low priority bugs personally, assuming I am the only person running into this. The thread synchronization issues are a much bigger problem for me; my work-around does not remove the issue, it just seems to make it less likely to happen. I've already added a switch that stops the rules creating new Items when it's OFF. This kind of breaks things when it's OFF but I expect to only use is sparingly when I absolutely need to access the Items page. |
If you don't mind me asking: I had planned to create a system to report errors/warnings/notes to the user by creating new Items that contain relevant information and adding them to special groups. I wanted to create a pages that shows all Items in these groups, and optionally allows users to dismiss them, or detect when an error is resolved. Once dismissed/resolved, the Item would be removed from the group and deleted. I assumed this is a perfectly normal use case for Items and Groups. From the above I gather this is not what one would normally do. Any suggestions on an alternative form Items to design/implement something like this? |
The problem with this "use case" is that it is not intended to dynamically create, update and remove Items. These are stored on disk (and not in memory in contrast to Item states, which are dynamic) and we had some discussion some time ago about metadata, where it was also said that metadata are not meant to store dynamic data as well.
|
I'll add that the oh-repeater widget in MainUI can parse that JSON stored in a String Item and render a card with list item widgets based on the contents of the JSON to give you a place to start looking. |
Thanks for the suggestions! |
#2837 fixes the flickering of the Items page on change, so it should be well usable now even with your case of dynamically adding & removing Items. Only the searchbar will flicker from now on, I haven't found a way to avoid (yet?). |
The problem
I've recently added a rule that runs frequently and creates and destroys new String items to track various things. I've found that the main Items UI (Settings -> Items) appears to automatically refresh every time this happens. The UI is not providing any information when it is being refreshed, as it is showing what I would describe as a loading placeholder instead of the Items.
After each such fresh, any "Search" value I've entered is ignore if there are any items matching it. The value is still there in the input field but if any Items match, all Items are listed instead of only the Items that match value I have entered. If no items matches, "Nothing found" will be displayed as expected.
If you happen to by typing in the "Search" field during a refresh, some characters you type may disappear. It looks like the value is set after the refresh completes to the value it had before the refresh started.
Expected behavior
Steps to reproduce
Your environment
The requested information contains a lot of irrelevant data that I do not wish to share. If you need anything specific, please do let me know and I will provide it.
Browser console
No relevant messages or errors
Browser network traffic
Each refresh results in one or more requests for
/rest/items?metadata=semantics
.Additional information
The text was updated successfully, but these errors were encountered: