All,
I updated to version 5.2 and now the search bar under the things menu shows off and on in a 2 sec rhythms. The same bar in items is stable. I am using firefox as browser and updated last week to the new version of openhab and firefox. I deleted the cache and did all the usually things but it does not show a stable search bar.
Any idea what I make wrong ?
Cheers
Franz
I just tested using Firefox, and my search bar is stable (only the cursor is blinking).
Are there any errors or warnings in the browser console (in the browser dev panel)?
I’ve had this issue in the past as well. The issue I had was using a binding (one of them I wrote) which frequently updated the Thing definition. If that happens, it will refresh the things-list display causing what you are seeing. The 2 binding which I knew to update the things regularly were senseenergy (which was fixed with #20482) and fineoffsetweatherstation (which was fixed with #20942) - so those fixes got into 5.2.
The only think I can suggest is to disable binding by binding to see if you can light switch the issue.
James, your suggestion was correct it cost me some time to find out which is the reason and it is:
org.openhab.binding.zwavejs this binding I can not switch off I have a lot of them but with the version before it was stable.
I test it with:
347 │ Active │ 80 │ 5.2.0 │ org.openhab.binding.zwavejs
bundle:stop 347
blinking goes off
bundle:start 347
it starts again.
Cheers
Franz
I don’t see any recent changes to the zwavejs binding that went into 5.2, so that either means that there is some change in your setup which is causing the binding to frequently update the thing (debug log for zwavejs might help) OR the binding has always done this and the main UI changed to watch for thing updates and refresh.
Either way, I wouldn’t think it is a good practice for bindings to continually update the thing definition - so I’d recommend filing an issue in openhab-addons. For the 2 bindings I mentioned above, the fix was to only update the thing definition when/if things actually changed - which was not very often.
That’s definitely a bad practice/bug. It has all kind of consequences, triggering processing, SD card write etc. When you have a, largely, event driven system, care must be taken to not generate “BS events”.
I do not know how I can debug the issue. What I know is it started immediately after the update to 5.2. I have not more nodes since them and the config did not change as well. I used updated what I noticed is that the zwave and the deconz especillay the deconz need much longer before they came online but a couple of minutes not much. So I did not care on the delay of the online. The zwave is the newes version I always update the zwavejs docker to the newes version. I looked at the zwave js log and there is nothing special it it always the same it reports plenty of power changes of the nodes not more. the same as before.
regards
Franz
I think that the update of the Things page has been added or fixed in 5.2.0, so it has probably revealed a problem with ZWave-JS binding that has been there all along. So, the remedy is probably a bug report to the ZWave-JS binding.
I have seen this before, still do to an extent. I eventually narrowed it down to either Bluetooth binding or ZwaveJS binding. Summarizing the log I found this:
ThingUpdatedEvent | openhab/things/zwavejs:node:3501507428:node54/updated 97
So something about that node was firing a ThingUpdatedEvent (97 times in a short period), which I think was causing a page reload. That node was an electric plug that was sending meter information very quickly. Never could figure out why it was causing the page to reload, and it’s above my head anyway. If you are handy in F12 console you can see all the activity. I ended up just deleting the plug/meter Thing as it wasn’t that important.
The point is that the binding should make sure that a change isn’t forwarded unless there was an actual change. If the device reports rapidly, the binding should check if any value actually changed, or just ignore it.
Also, it’s not clear to me why a sensor reading would cause the Thing itself to need an update. Wouldn’t that be a channel event instead?
Here is a shot from console during search bar flash. I’m out of my league here, but somewhere I read that one or more of those endpoints could force a page reload.
| events?topics=openhab/things/*/added,openhab/thing…tus,openhab/inbox/*/added,openhab/inbox/*/removed | 200 | eventsource | Other | 2.0 MB | 4.5 min | |
|---|---|---|---|---|---|---|
| things?summary=true | 200 | xhr | framework7-vue-CsgUUwCm.js:1351 | 3.5 kB | 373 ms | |
| inbox?includeIgnored=false | 200 | xhr | framework7-vue-CsgUUwCm.js:1351 | 245 B | 2 ms | |
| things?summary=true | 200 | xhr | framework7-vue-CsgUUwCm.js:1351 | 3.5 kB | 423 ms | |
| inbox?includeIgnored=false | 200 | xhr | framework7-vue-CsgUUwCm.js:1351 | 245 B | 2 ms | |
| things?summary=true | 200 | xhr | framework7-vue-CsgUUwCm.js:1351 | 3.5 kB | 394 ms | |
| inbox?includeIgnored=false | 200 | xhr | framework7-vue-CsgUUwCm.js:1351 | 245 B | 2 ms | |
| things?summary=true | 200 | xhr | framework7-vue-CsgUUwCm.js:1351 | 3.5 kB | 363 ms | |
| inbox?includeIgnored=false | 200 | xhr | framework7-vue-CsgUUwCm.js:1351 | 245 B | 2 ms | |
| things?summary=true | 200 | xhr | framework7-vue-CsgUUwCm.js:1351 | 3.5 kB | 339 ms | |
| inbox?includeIgnored=false | 200 | xhr | framework7-vue-CsgUUwCm.js:1351 | 245 B | 2 ms |
This probably causes the page to reload/refresh, but it’s probably a symptom, not the cause. The very first entry, events?topics=openhab/things/*/added,openhab/thing…tus,openhab/inbox/*/added,openhab/inbox/*/removed, is the connection that listens to events. When the UI gets an event that tells it that a Thing has changed, it will request a new summary and refresh the page.
The “problem” that sets all this in motion is the event that tells the UI that something has changed, not what happens in response to the event. The binding is most likely responsible for sending out this constant stream of “changed events”, probably in response to some device that is very “chatty”.
I found a chatty node and KJ information about the electric plug is right I have one a QNSW-002P16EU and there is a sleeping device connected which has a electric consumption of less than 1W so the shelly reports quite often the meter information I switch this off Power Change Report Threshold disable and the blinking search bar got much more stable.
I guess there is a problem in the binding that it thinks a configuration update happens which is not the case.
Hi,
can I help to solve this or was it not a problem of the binding ?
regards
Franz
I can’t really answer that. It sounds to me like there’s a problem with the ZWave-JS binding, but there’s no way to be sure without the hardware to test it. Somebody should probably create a GitHub issue in the openhab-addons repo about it, to get the binding devs to look at it.
Thanks I did I pushed a message to git openhab addons