I think the issue is simply the result of slight timing changes in the TCP stream, at both the server (hub) and the client (browser).
I'm a little out of my realm, but I believe that the document type is appropriate if you are retrieving a fixed size item where the response length can be advertised in the header. For a complex build on the fly response of unknown length, I believe stream is the appropriate choice. The Z-Wave details page is clearly built on the fly.
Again, I'm out of my realm here so take my analysis with a grain of salt.
Ok, understood. I tried making your suggested simple change in the app code's getZWaveList() function, line 414, and it's working 100% of the time for me now.
@dennypage@672southmain@thebearmay Thank you all for your patience and help in tracking this down. Unfortunately I don't have an iPad so it is a little challenging from my side. I will work on this and review the PR and try to get an update out for testing in the next week or so.
Just started using this. After seeing it, the zwave page included in the hub seems useless to me. Whether a "consequence of the way zwave works" or if it is a problem with Hubitat itself, the hub gives us no tools to really see what's going on with our mesh. This makes things so much easier than an unruly grid. It actually tries to apply some UX design and say 'why would a user be on the zwave details page, what are they using it for?" and make it better.
Two suggestions, one easy and one hard:
Hubitat recently added the Device Class column. It'd be nice to be able to see that data and even filter by it (both the type and the manufacturer?) If I get bored I'll probably implement this
Something to make the zwave logging better. The fact that there is no way to bring up old zwave logs sucks. Generally speaking, you look at logs AFTER you've had a problem. So a tool like Hubitat that says "sorry, we delete the logs unless you leave the page open" makes it really tricky. I've been toying with the idea of setting up something to listen on the zwave log web socket and writing them to a file so they can be pulled up later. That'd be much easier if they provided a way to write to File Manager via an API instead of just RM, but not holding my breath on that one.
I highly recommend this app to anyone who has Zwave issues. This really should be built in!
Obviously I'm the only dense person in this thread, but how do you access this once its installed? I installed it via the apps code like usual but nothing new shows up in the apps. What am I missing?
I installed this app to try and troubleshoot a problem with sensors. Below is a screen shot of the results. Could someone clarify for me what I am seeing. The first four items and the last item are sensors. The other 2, 16 and 17 are relay units located right next to each other. The relays are the closest to the hub. Sensors are futher away. The ones we are having the most trouble with are 0A, 0C, and 0D. Just trying to understand what I am seeing here. Thanks for the help.
I submitted a PR for this to @tony.fleisher so hopefully it will get integrated, but if anyone is interested, I have a fork that adds the device type and brand columns that are now displayed on the zwave info page on newer firmware versions:
Please also add @dennypage’s bugfix on line 414 (type document should be stream). See upthread for details. Otherwise, the mesh table is blank for me a good percentage of the time.
I am not sure why this resolves the problems that some people are having, but it doesn't seem to be correct from the documentation of that option, so I think there is something else going on that needs to be found and fixed.
If we can't find the actual issue, I might provide an advanced option for this hack, but don't want to adopt it for everyone and risk other issues down the line. (If someone can provide a clear explanation of why this is a correct change, I am open to learning something new. )
Odd. It doesn’t generate any error for me, not on save and not at runtime. @dennypage’s explanation sounded reasonable to me, and it has fixed he issue. I’ve never seen an error since I made that change.
It must be something subtle because it’s not a 100% failure, just most of the time without this change.
It might be a timing thing because I don’t have as many devices as many of you do. Denny was finally able to reproduce it, though. I believe it started upon the 2.2.9 release with its concurrent Z-Wave radio update. No new devices here.
I’m willing to try any debugging to see if something else is going on. All I can say is that, upon making that simple change, the app started working again.
I detailed all the configuration stuff above to try to help Tony and Denny figure out what the issue was.
Ok, I don’t use chrome; use Safari except in testing this issue.
I never saw the failure on iMac using Safari, Chrome, or Firefox. I did see the failure on iPhone and iOS using Safari, Chrome, and Firefox, but that’s to be expected since Chrome and Firefox on iOS and iPad OS are just a skin on top of Apple’s WebKit, just like Safari.
