I noticed I was running deCONZ firmware version 5.1 so updated to 5.3.
The release notes didnāt specify a fix of any kind and it worked fine under v0.105x, but now one of the three sensors shows the attribute. So perhaps a reset fixed it and it seems no HA version issue.
For the record, I did a HA restart and a system reboot before posting.
Worth keeping in mind, itās not like Safari is a known bad browser. It optimizes for energy consumption vs. performance, while Chrome optimizes for performance vs. energy. And Chrome is more aggressive at adopting new standards. But Safari is still widely regarded as a great browser, with good performance characteristics in spite of optimizing for energy efficiency.
So, letās say it is a problem only on Safari. Itās probably not a good idea to dismiss it as Safariās fault, just because it does work on Chrome. Not unless weāre going back to the days of IE vs. Netscape.
Itās worth investigating, what is the problem? Is there a genuine issue with Safari? Maybe. Or is the HTML and JavaScript so inefficient that itās the cause? Maybe. Some of these JavaScript front-end frameworks areā¦not efficient. Or can be inefficient when used sub-optimally.
Might be, itāll be something hard to fix, and the developers move on to other things, and recommend folks use Chrome. But, might be something easy to fix, and in that case, I bet Home Assistant performs better no matter what browser youāre using.
(Iāve been getting Safariās āThis webpage is using significant memory. Closing it may improve the responsiveness of your Mac.ā error message, starting with my first install at .104. Itās been driving me nuts. Chrome, as evidenced by the amount of memory itās using for far fewer tabs, is unconcerned about memory usage. That doesnāt mean Home Assistant pages memory usage isnāt excessive, just that Chrome has gone honeybadger-donāt-care on us.)
ZHA native support for Texas Instruments CC based Zigbee sticks is what Iām personally most excited about!
I personally think that the 0.106 release notes should also have high-lighted/promoted the newly added ZHA support for Texas Instruments CC series based Zigbee coordinator sticks because of their very inexpensive price has the potential of making it a disruptive technology in a positive way for the Home Assistant community.
Pull request #31621 by @sanyatuning adds native support for the same cheap CC2531 Zigbee sticks to Home Assistant, the same Zigbee sticks that the Zigbee2mqtt project has made popular among the community.
Right now the short comment about Texas Instruments CC support was hidden in the list of all changes in the 0.106 Beta release notes, and again I personally think that it was as such was not very informative about the impact that native support for inexpensive Texas Instruments CC based Zigbee coordinator sticks could potentially have.
Maybe it could be mentioned in a community highlight?
+1
even bought a new MBpro16 for this with 32gb memoryā¦ the Safari popups are by the minute. Well, maybe not the minute. But very abundant.
And yes, Iāve deselected the blockers on the website.
It would be very nice if this were to be investigated more thoroughly. Volunteer to assist in the testing.
Then again I do have a larger config by @KennethLavrsen 's definition so do fear upgrading to 106 somewhat.
Since upgrading to HA 106.0 My aqara contact sensors (doors/ windows) are showing as unavailable. Have tried rebooting/ powering off and on again but no joy. All other sensors seem to be working fine i.e magic cube and motion sensors (both aqara).
Contact sensors were working fine with HA 105.5, HassOS 3.11, and deconz 5.2.
It seems to show the battery status though. Just not the binary sensor part.
@CSP170 I have the same issue with aqara doors/windows sensors and aqara body sensors. Updated deconz to 5.3 but with no resolutionsā¦stil unavailable