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
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.
@TAustin
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 1.7.86.1 (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.
@TAustin ,
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.
Hi @TAustin,
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.
Not exactly.
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.
