Device status is not updating in web UI only

Hi, I have device status updates not showing immediately in web UI. I have to do browser page reload to see new status. This seems to be restricted to web UI only, I do have near-instant updates in android dashboard via Maker API endpoint and rules/automations seem to be ok and fast as well. Just not web UI, which is slightly annoying when adding new devices or testing alternative drivers.

Any hints?

C7 2.2.8.156

You may need to be a little more specific about what you mean by status updates. Are you referring to Current States (attributes) that typically appear on the right hand side of the Device Edit Page, or are you referring to State Variables, typically displayed below the Commands? Or are you referring to other information at the bottom of the Device Edit page?

You may also want to look in the logs to see if you can observe any delay in updates being processed. You may need to turn on some logging options for the device to see these come through.

Current States do not update until manual page reload.
Logs don't auto-update either but if I do Past Logs and do manual reload the timestamps seem to be in line with actual events.
Popups like in zwave repair do update asynchronously to reflect the state of the operation, but not logs/device pages.

Which browser and OS are you using?

Could this be a known issue that was fixed recently....?

Reading over this, if the OP is looking at the device page, then current states and events not updating until a page refresh would be a case of "working as designed". Same with the Past Logs page.

Current States (attributes) I believe are a "live" part of the page... Both in terms of what I have read and experienced..

Ooops, you are correct, I was thinking of the State Variables portion.

Do you have any special setup in your web browser, like disable Javascript or an overly aggressive ad blocker that might be doing the same?

So... it started working again after about a third reboot of the hub. No changes to OS/browser/ad blocker/etc. The only difference I could find is that I was able to remove a ghost zwave device which was 'stuck' before and I was getting error 500 on force remove and zwave 'busy' in logs. But as I mentioned, z-wave devices were working responsive/fast based on visible results of automation. No idea how a z-wave subsystem could affect async js on web UI though, so it is probably not related.

Yes, looks very similar.

1 Like