Both. I noticed that on e existing, and I created a couple of new ones, and it is the same thing.
Now on only one it looks ok, as probably i have used actual button to reset. All other are reset through automation
Btw long time ago I have asked if you could add just one decimal point. If you are making any updates if that could be added
You were right, i just used automation to reset them all and cloud is replaced with the button
I’ve pushed out a driver update to address the dreaded broken cloud issue that has resulted from a recent Andriod app update, and as report by @milandjurovic71.
If you continue to see a broken cloud on your existing device, create a new device with this latest driver update and you shouldn’t see it anymore.
This update also adds another decimal of precision to the last energy total shown when the reset button is pressed.
The driver will be automatically updated to your hub, but you can confirm you have it by checking the driver version, which should now be 2022-06-18T21:09:23.568568517.
Hi @TAustin ,
Could you please elaborate about this issue?
What exactly causes this?
I noticed refreshes stoped working and showing cloud for capabilities that were previously set. I wonder whether refresh now clears the state of the capability and expects it to be set again
It appears to happen for any field (capability) that has not been explicitly set with a value. So it’s been seen most often in newly created devices, or devices with fields that have not been initialized or set with any value.
The above is what I’ve observed so far and happens typically with simple text output fields or even buttons with selection lists.
Let me know if you still see an issue with this latest driver update. I don’t think this field initialization issue should actually stop refreshes from working, so that concerns me.
EDIT: Editing that last paragraph. Refresh only updates capability attributes, so as long as there is a value it should be working OK, but I will confirm this in the code.
Thank you for a quick response.
The issue I’m seeing is that after refresh I’m seeing clouds on capabilities that were completely fine before.
That is for Android 220.127.116.11 (and I also have seen it with the previous app version).
This is especially frustrating for virtual devices as I’m setting only some (and not all) capabilities on refresh. For physical devices it is probably a lesser problem as refresh could just be modified to read all registered attributes. Still, sleepy devices might not respond to read attributes requests and are showing clouds after refresh.
If I exit the detailed view and enter it again, everything looks normal, so this suggests that the state is preserved for device.
It looks like the app expects updates from the hub after the refresh
Which specific fields are you getting the broken clouds for? The only thing I can think of right now is if cached state values are unexpectedly coming back nil and used in the total power computation.
I may need to get you to run some logs for me, so I can see what’s going on. Could you do that? Some screen shots might be helpful too.
It is suspicious, though, that you can exit the detailed view and it is normal when you return. That would be an app issue.
@milandjurovic71 - how are things working for you with the latest driver update?
I’m sorry for not being clear.
I noticed the issue for other drivers, not for Virtual Energy/Power Meter.
I thought if you managed to solve the problem, then you perhaps could share your findings.
Not initialized capabilities were showing broken clouds also before 85 and 86 versions of Android app.
However, I have not seen broken clouds after refresh.
I suspect the recent Android app expects update events for each capability after refresh. If none else seeing this problem, then may be I need to try to delete the cache.
I’m not understanding when you say ‘refresh’, what are you referring to then? Is this for devices that have implemented a refresh capability?
Yes, I’m referring to sliding down the detailed view in the app for devices with refresh capability
I understand now. Sorry for the confusion!
That action is purely a mobile app action - it doesn’t result in any requests back to the driver.
If the profile and the VID have the refresh capability, then device:refresh() is executed in the driver and the capabilities attributes are read.
If it is a virtual device, a status refresh function must be implemented or it will do nothing.
Upon user triggered refresh the app sends event to driver.
The default refresh handler in the stock library sends read attribute request for each registered attribute.
The device responds with attribute value and attribute handler processes the response by emitting event to capability.
This sends the update to the app through the cloud.
I suspect the app now expects this update event for each capability and shows broken cloud if it is not received within some period.
Ah ok but you probably need to be including the refresh capability in the device profile, yes? I don’t use it in any of my devices, so that’s probably why my drivers never receive any events.
Yea, I’ve never used it in any of my devices.