It's unfortunate that the third reality devices patently ignore configuration reporting and binding changes.
The correct way to resolve unnessicary attribute reporting is to unbind the cluster of interest or change the reporting configuration for the attribute of interest as suggested by @kkossev
The attributes being reported on cluster FFF1 aren't used in this driver, and it would seem to be causing some traffic issues which appear to be dependent on a given hubs network configuration/device combination.
I can't think of a way of resolving this with any driver or hub code updates.
5 Likes
It's been a long while but I had an issue with a device and they seemed interested in addressing the cause. Not sure how open they are to making changes these days. They do mention Hubitat compatibility, partial or full, for their devices on the Amazon pages. So you'd think they would want to at least know of issues.
2 Likes
Thank you for looking into it. I have a work around. I put the sensor in HA and bringing it back in via the HADB. Works as intended this way.
Maybe someday it will get changed around. Again. Thank you for your time.
I publish on average several firmware update files a month from them that they send to me.
55 is latest available, but as I think others have already confirmed here, this crazy-high message count issue is still present on 55 too.
The 55 release notes seem to come tantalizingly within the neighborhood of this issue (some of that language seems to line up with the chatty cluster Krassimr mentioned), but we'd all obviously like to see this issue addressed when the device is in Active state too.
Perhaps @ThirdReality would be willing to weigh in here at some point.
@mike.maxwell @mike.maxwell @ThirdReality I can confirm I experience the same issue on firmware level 55. I updated the device to this level and had the same experience.
Right, I see them on the product I use. My point is that if there are issues with their sensors and how they work on Hubitat they'd probably want to know.
