Version 1.7.91.24
Android tested on Samsung phone and Samsung tablet
Downloaded the latest app and it has made every device unreachable. All of them lost their state in the dashboard views and clicking on any of them produces a message of:
“Can’t connect to device. Check device and try again.”
This is with all devices (Edge, DTH).
I verified this by taking a working tablet, upgrading to this version, and seeing the devices immediately all go blank. The automations and scenes still work.
I narrowed this down to the use of the Sensative Strip Edge Driver in this thread:
I can switch the device using it to a different driver, and app immediately populates. I can then switch it back and the app goes blank. I have cleared data, uninstalled, etc. and can reproduce this every time. If I use that driver, it will crash the app and cause the data to become inaccessible.
I’m curious to know which hub you both are using. There have been problems reported on other platforms with Series 700 devices and the hub locking up because the timing is handled somewhat differently and the hub can get stuck in a situation where it is waiting for the network to be clear but it’s too noisy and things lock up. This appears to be particularly true for networks with a lot of multi sensors of different brands so it may even be related to endpoint support.
I believe The current smartthings hubs do not support series 700 except through the usual backwards compatibility, but that doesn’t mean there couldn’t be a model difference in how some issues are handled.
Might not be relevant, but I just thought I’d ask.
I think he said Routines and Automations are still working so the hub and devices are fine and I’m pretty sure this is just a UI glitch in the latest version of the Android app.
It’s possible that one of the custom attributes isn’t getting populated when the driver is switched and rather than displaying a message for that tile it’s completely crashing the UI…
Probably completely un related but version 1.7.91.24 of the Android app does lock up for me on an S10
Usually when a device control page is open and i minimise the app to use the phone for another purpose, maximising the minimised ST page previously open just results in a blank black screen, trying to go back using the back button has no affect and i have to force close the ST app
Thanks for looking at this @krlaframboise. I tested this on an Aeotec V3. Here is the full sequence:
Excluded a 700 Drip strip that was on the DTH
Rejoined it using the Edge driver. During device setup it asked me to place it in a room.
Device wouldn’t populate on the dashboard and gave me an error when clicking on it. Suspecting an app caching issue, I cleared the app data after 30 min or so.
Upon re-starting the app, all devices were inaccessible and blank.
I tried clearing and data and restarting a few times like this with the same result.
Switched to a spare Samsung tablet and verified that the devices were working in there, including the 700 Drip strip
Upgraded the tablet to the latest app and it all went blank again.
At that point, I switched the device to the generic Zwave Sensor driver suspecting it may have been the driver itself. It went to non-provisioned state and everything in the app started up.
I experimented with various sequences of clearing data, restarting apps, and switching drivers. In all cases, the use of the latest app with the 700 driver resulted in the same issue. Switching either one back brought it to a working state.
Let me know if you want any logs or anything offline. I can also try a few more scenarios if you have anything in mind. I haven’t removed the device yet, in case you wanted to capture anything in its broken state.
Along this line of investigation, I did notice that the “calibrated” text that shows for the moisture calibration was in all lower case. I’m guessing you probably have a translation file with an uppercase version of that string. Is the lowercase version falling back to the actual enum value? Did you possibly change the definition of a capability or translations after it was created? Maybe the new UI is struggling with something like that.
Annoying thing is i cant exactly remember the sequence that creates the blanc screen with no control
I tried earlier to open a devices driver page and then minimise and return after a duration but it worked fine
There is a possibility it was a device memory issue but today i recieved a small O/s security update, Smartthings was one of the listed apps that was included in the update but whether that has any corralation to the issue i cant say
Best i got is i have seen a locked up app with a blank screen and it has happened several times in the recent past
This happens as you say, you open the detail view or routines of a device and go to another app. After a while you return to the smartthings app and the screen is blank and blocked, then you have to close and reopen app
I did some more testing this morning and am seeing slightly different results. When I switch back and forth to the 700 series driver, the app no longer blanks out. Instead the app crashes when I switch to the 700 driver. Restarting the app, other devices all appear fine. The drip strip is still inaccessible. Switching back to the non-provisioned ST driver makes the device accessible, although non functional.
I just realized my device was using the version from my dev channel and not the official channel and when I switched it to the official one I’m seeing the latest behavior you are with the Drips 700 and Comfort 700.
I haven’t released a new version of mine so I have no clue why mine is working and theirs isn’t, unless this issue only applies to recently joined devices. If it only happens when switching to the driver or joining a new device then that would explain why no one else is reporting the problem.
I’m curious to see if it starts working again once I switch it back tot the one from my channel, but how are you changing the driver without opening the device?
Did either of your custom capabilities for the Drip strip change prior to the official driver going out? You could try rebuilding your dev channel. It should match the official in theory. Very odd indeed.
The version on my dev channel is from 5/6 and the one on the prod channel is 5/17.
I also ran the devices:presentation command for the device while using each driver and the results are identical and so are their attribute lists. The logging results when switching drivers are also basically the same.
The only difference I can think of is that the dev driver was installed from the CLI and the prod driver was installed with the invitation link…
I just updated the translations for all the custom capabilities since I hadn’t previously done that for some of them, added the label token to their presentations, refreshed all those device-configs which generated new vids, changed the vids in the profiles, and published the new version of the driver to my dev channel.
The Comfort 700 and Drips 700 appeared to function fine, but they were no longer accessible in Routines and clearing the cache didn’t help.
I then installed a completely different device and the device was accessible in routines, but it wasn’t listed on the “all devices” screen and clearing the cache didn’t make a difference.
I was able to get that device to show up by restarting my phone, but the Strips 700 devices are no longer working.
I removed the vid lines from the profiles, published the new version, and that still didn’t solve the problem.
The Comfort starting working as soon as I removed the Drips and it continued working after I added the vid back to that profile so you’re right about the issue being specific to the Drips.
I added the Drips back and everything is working again so I’m thinking the issue probably has something to do with the Drips device-config and since the default presentation works OK for this device I sent Sensative a new version that doesn’t use a custom presentation for it.
All that being said, it wouldn’t surprise me if this is a temporary issue that goes away on its own within a couple of days because of all the other weird issues I ran into while troubleshooting this…
