ST recently made a change to the new mobile app that broke the settings screen even worse than it was before. Until they release the documentation for the new mobile app that’s probably going to keep happening so at this point, I’m not wasting time troubleshooting any issues in the new mobile app.
Once they release the new documentation I’ll make the necessary changes to get everything to work, but until then you need to use the classic mobile app to change the settings.
Zooz mentioned that there was an issue with the status in the new mobile app so while using the new app did you happen to notice any other issues, like it not changing the motion state or reporting as offline?
I hardly have any devices connected to ST anymore so I can’t easily check these types of things…
I’m having a similar problem to one mentioned by @162884 above. At times, the sensor will become active and never reset to inactive. As far as I can tell, this happens when the sensor is almost out of range of my hub and perhaps the inactive signal is not received. And even though subsequent communications are received, the activity status doesn’t get updated. See attached history. Sensor never shows inactive, even though subsequent lux measurements are reported.
@NYZack… my issue was also a signal issue more than likely. I added another Z-Wave device that was between the ST hub and the motion sensor. Once that was done, I went to the ST IDE web page and went to My Hub page and ran the Repair Z-Wave Network utility. Never had the issue again.
@162884 Well, that brings up a separate issue. I’ve tried Repair Z-Wave Network on numerous occasions, and the sensor always links directly to the hub, even though I’m sure there are better routes available. Are you sure that repairing the network created a route that did not go directly to your hub?
@NYZack… I’m not sure since I really don’t have a tool that maps Z-Wave network devices and mesh hops. I was having this issue almost every other day for the few weeks after I installed it. Once I did what I mentioned above, it hasn’t happened at all since then.
Doing a z-wave repair only impacts repeaters because devices that sleep won’t know that a z-wave repair was performed. I’ve seen some posts that say waking up the device during the z-wave repair will make it update its routes, but I’ve tried that with other devices while watching the traffic with a z-wave sniffer and it didn’t.
I believe sleeping z-wave plus devices will continue using the same route when sending unsolicited messages to the hub until that route fails. Once it fails it will try a different route and if that’s successful it will keep using it.
I’m basing that off of random posts I’ve read in the past so I’m tagging @JDRoberts because he’s extremely knowledgeable and will probably be able to correct me if anything I said is wrong.
That is not my experience from standard Z wave, I don’t know if there’s something different about the SmartThings platform since it has a cloud component.
But normally, any battery powered Z wave device which is awake will participate in the repair. This is the standard way of picking up a new repeater when you’ve added one to the network.
The one thing I do know which is different about smartthings is that the routing shown in the IDE may take 24 hours to update. That’s just a cloud artifact, it did update during the repair on the hub and the devices will actually be using the new routing, but you won’t be able to see it in the report for a while.
Except for sirens and locks, battery devices usually only wake up about once every 4 hours and are often awake for less than 1 second which means you’d manually have to wake up all your z-wave devices during a z-wave repair.
I’ve tried this multiple times with SmartThings/Hubitat while Zniffer was running and the only messages it’s captured for the device being manually woken up during the repair is the Wake Up Notification message it sends to the Hub and the Wake Up No More Information message the Hub sends back to the device…
If it was participating, shouldn’t I be seeing a lot more messages between it and the hub and/or it and the other devices?
We should take this conversation to another thread as we’re getting pretty far off topic for this one, but I don’t understand the comment above. If that were true, humidity and temperature sensors would only report every four hours.
There are tons of conversations about Battery operated devices in zwave repairs on boards for other controllers, such as vera and Fibaro.
And you can see the battery operated devices listed with or without error messages in the repair reports from, for example, zwave toolbox.
Again, I don’t know if there’s something unusual in the smartthings Zwave implementation in this regard.
Devices aren’t awake to receive messages when they send reports. If that were the case then when the DTH receives a humidity report it would be able to send back a request for the temperature report, but if you try doing that those messages will fail because the device isn’t actually awake.
It’s possible that when those other platforms receive a wakeup notification from a device during a repair the hub sends the command to make it participate, but I haven’t seen that with ST.
The part of my original post I couldn’t test and was unsure about was how the healing aspect of z-wave plus devices work, like do they keep using the last successful route of any message or just their unsolicited messages…
I am curious about some other things related to repairs, but I’ll PM you because I agree that we’re getting way off topic. Although this is my topic so I can hijack it if I want to, lol…