I have a LAN edge driver that shows devices as online in the dashboard screens and functions properly. When I go into the detailed view the components work fine. If I then pull to refresh, each of the components shows itself as offline. Leaving the detail view and coming back in properly populates everything. I verified in the logs that the device is actually still online and never goes offline. I think this may just be an issue with the Android app, but not sure since I am only seeing it with my edge devices.
This issue is already reported:
It should be solved if you support the Refresh capability and its corresponding handler where you retrieve a value for each capability. The issue is with the auto-refresh.
Ok, no problem. As this is already reported, the team will work on it, for now, this means the “pull down” refresh is not available.
This issue is happening for all device types in the SmartThings platform. So, it is not related to the update of the third-party app.
Appreciate that Nayalez, i was simply highlighting a coincide.
No problem, I just wanted to clarify that so you don’t have to contact them to resolve this issue with SmartThings.
If you couldn’t control the device, it’s highly possible the issue would be on their side, but it’s useful to check with us first, we would let you know if that’s the case.
This may be the issue then. I have a refresh implemented, but it doesn’t grab EVERY attribute in the detail view. Thanks.
I’m glad to see this conversation. I’ve been playing around with the refresh capability lately and it’s behavior is a bit baffling to me. (I’m on iOS).
I guess I’m seeing the same issues as have been reported: As you also said, I have the refresh capability implemented, but if there is ANYTHING that isn’t updated with an emit_event, then I get the cloud for that field - even switches and buttons! Same thing too, that I can exit from the Controls screen, then come back in and everything is displayed OK again.
So this is a question to @nayelyz: when this issue does get fixed, what are the refresh requirements in regards to capabilities like a switch or momentary? A switch I suppose could be re-emitted (although that seems kind of dumb), but you can’t really re-push a momentary button (wouldn’t that cause problems with routines?!). There are probably other similar situations with capabilities that wouldn’t necessarily make sense to ‘refresh’.
I think this the issue, discussed here
Just to recap, the requirement to re-emit events for each capability doesn’t seem the best way to handle refresh. Please let me elaborate why.
- Refresh normally sends read attribute request to the device and updates the capability when response is received.
a. Some devices (especially Tuya) do not support that for all capabilities
b. Some devices might not response fast enough
c. Sleepy devices will not respond in most cases
- For virtual devices this would mean sending a lot of unnecessary messages
- As @TAustin mentioned, re-emitting events might unnecessary trigger routines
Please take those points into consideration.
One other curious thing I’ve observed about the refresh lifecycles, it appears that it is invoked just before the driver is reinstalled (following the equally curious/mysterious info_changed lifecycle calls). This is a pretty strange thing, particularly when the driver is about to be reinstalled and refresh is invoked again after the initialization lifecycle.
This makes me wonder about the effect on attributes like
An explanation is needed fast because this situation is beyond ridiculous. I for one can’t continue with SmartThings under such circumstances.
This suggestion is a temporary/possile workaround while this gets fixed. It’s not mandatory because the other (simpler) solutions are:
- Go back to the main page (dashboard) and enter the details again
- Restart the app
- Mainly, avoid the pull-down in the detail view and wait for the reports from the device.
I understand we shouldn’t have to update every capability for it to be displayed. I shared the comments of @ygerlovin that is not possible to update all capabilities in the report I created.
It seems supportedValues are broken only for custom capabilities.
button is a standard capability, so it should not be affected.
It seems, the behavior of
supportedButtonValues is special, we’ve seen sometimes it stops working and for others works correctly, it’s strange (we already reported that).
I tested the supported values with
What I was getting at was that if
refresh is really expected to updated all attributes as is claimed (and I don’t dispute that, I just haven’t really noticed it), would an attribute such as
supportedButtonValues also be required to be updated? It is after all as much as an attribute as e.g.
button. Or is this purely the app playing silly beggars with displayed attributes?
I don’t have any insider info, I have only my guesses, based on observed behavior, so please take it with a grain of salt.
It seems to me that for some reason the APP now expects that all visible fields in the detailed view to be updated within some (very short) time period after refresh event has been issued.
I have custom capabilities with multiple attributes and it looks like that attributes that are not participating in presentation are not affected (i.e. the app does not draw a broken cloud if the driver does not updates such attributes).
Only visible attributes needs to be updated.
So, I think, refresh currently needs to update only visible attributes. supportedValues are now ignored by the application for custom capabilities and all values are shown, but it looks like it is not required to update them
It is difficult to comprehend how the app can seemingly reinvent a capability, and indeed the architecture of SmartThings, if not the internet and the laws of Physics.
An explanation is needed fast, otherwise what is the point of continuing knowing that absolutely anything can be broken at any time?
If I’m not mistaken, it sounds like a fix is planned. I’m content not manually refreshing for the time being as long as a fix is on the way.