Is there any "built-in" behavior with Refresh command?

Is there value in implementing the Refresh standard capability in your Edge device profile? I put it in originally like some of the examples, and fired it on a timer. After some refactoring I ended up with the true “refresh” being done via a different timer routine, and I left the registered “Refresh” in (without a timer routine) just to see if it was ever called. So far I haven’t seen anything in my logs. I saw a reference in a post about “pulling down to refresh” (common on phone app behavior) but my ST app (I’m on the new app) it doesn’t seem to have a “pull down” behavior and I didn’t see “refresh” in any of the options.

Is is just a convention to implement a standard capability Refresh even though all of the code is unique to the driver, or did I miss something?

Pull down to refresh (at least on android) requires that you pull down in the controls area. If you pull down by the name, it doesn’t work.

I only see the refresh just after device init and on pulldown. Giving up for the night, but wondering if device:refresh() may trigger that commands on LAN devices. I am forcefully injecting it at the moment when my device comes online.

I think it is simply that if you can conceive of ever needing to call your ‘refresh’ code manually, or by an automation, then you might as well call the command refresh and use the refresh capability as it is pretty widely understood that is what it is for.

With tagging capabilities like actuator, sensor and bridge being deprecated, the refresh capability is also a useful ‘does no harm’ capability to have around. Such things are useful when developing device presentations. Also it is a free command for debugging purposes.

refresh is the only control that is still enabled when a device is marked offline. Very useful to have it do something like polling or reconnecting that might bring the device back online.

I got an error when I tried using it, so I don’t think the action is defined for LAN devices. I think for zigbee and z-wave devices it calls all of the refresh commands from the default handlers.

2 Likes

Thanks for the help @blueyetisoftware @philh30 @orangebucket. I confirmed that if I pull down IN THE CONTROLS area of the page it does generate a refresh command, which is useful. This does seem a little counter intuitive to me, since I avoid hitting controls when trying to “pull down refresh” since it is easy to accidentally hit a control and cause it to respond when what you were trying to do was cause a refresh. I always try to use a blank part of the page to do a “pull down”.

Adding to this thread since it is related. I am seeing irregular behavior on device initialization. Most of the time,refresh is automatically called on new devices, but not always. I have been unable to find a pattern. @nayelyz Do you know when the platform decides to send a refresh command to new devices? Other than manually refreshing the devices, this is the only time I ever see the platform do it automatically and it doesn’t always happen.

Hi, @blueyetisoftware. The team mentioned that we shouldn’t expect any automatic refresh, so we should send initial state events explicitly.
You can call device:refresh() which will execute the refresh function defined in the capability defaults.
Also, you can define your own refresh function and call it when you need it.
Thank you for sharing what you experienced, we will be monitoring the behavior to see if we can find out more.

Thanks. I would note that these were LAN devices as well. You can see refresh being called simply be defining the handling and never calling it.

@nayelyz I think I may have just noticed a pattern. I see the automatic refresh on LAN device that are also successfully initialized. If you remember, @rossetyler and I also reported that devices aren’t always initialized after being added. The refresh looks like it only happens when the device was also initialized. I’m not 100% on this pattern, but it seems to be correlated. No init == No automatic refresh