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.
Hi!
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.
1 Like
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.
1 Like
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.
1 Like
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â.
Hi @nayelyz
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.
Thanks
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 supportedButtonValues.
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.
1 Like
It seems supportedValues are broken only for custom capabilities.
button is a standard capability, so it should not be affected.
Cheers
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 thermostatMode.
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.