A full restart fixed for me
Just set the service up in the UI and the device id is filled in automatically. Otherwise you should be using the service with the entity instead
Yeah, it is a breaking change as noted by Frenck in the issue I linked although he seems to infer it may affect custom components only, when the reality is bluetooth_tracker is core.
I also note that in this link bdraco knew about it and commented on it on March 24th as waiting for pybluez to be updated to work with Python 3.11.x.
So, as this is a deliberate breaking change, why does it appear to have been hidden when it should have been highlighted, especially when, as reported, it causes long restart times if bluetooth_tracker is configured?
On a positive note, when bluetooth was, again, deliberately broken just under a year ago ( I am not certain but I suspect it was because of Python), it suddenly started to work about 5 months later without any acknowledgement in the release notes (unless I missed it). I hope this will be solved again with a pybluez update but this time with some form of notification!
This is a show stopper for me, as it was last year, so no update for my production system until we have a working bluetooth_tracker core integration!
Does this update support matter thermostats (like the nest thermostat 2020)? I saw in a reddit thread that itād be ready in time for this release, but I donāt see anything about it in the release notes.
MQTT is dead after this update.
After the update it states āRestart(s) requiredā under Repairs.
Once you click Submit, MQTT is dead.
I had to restore from backup to fix it. It bricked my entire install.
The issue would be multiple notifications, we really need a way to get them to automatically +1 on the entity so when multiple notifications go off, they can all be easily referenced. Difficult to do that cleanly with everything having custom Ids
Hereās how I do the persistent notifications via once the event thatās holding them up has ended. alias: "Notification: Persistent Notification Alerts"description: Alerts me if - Pastebin.com
Anyway, registered an issue for a weird yaml structure for command_line:
Thank you for the update.
It would be nice if new layouts like devices & entites were optional.
I find the new layout to be quite unfortunate on mobile android devices (i.e. in companion app).
Came here to say that mounting a network share was relatively easy, thanks to this new feature in the 2023.6.0 release. Iāve been rather impatiently waiting a LONG TIME for this! THANK YOU!!!
One comment: Can the front-end/GUI developers please consider adding cache control to the GUI web pages? My Settings / System / Storage page wasnāt showing any of the new features until I manually forced a page refresh with CTRL-R.
Hopefully someone who works on the HA companion app / UI team is in this thread:
The new favorite colors in the pop-up are super weird on the Home Assistant Android appā¦
You have to hold it down for like a good 10 seconds to activate drag and drop and then the delete button wonāt even work for me. In fact I canāt even move around the colours with drag and drop. Weird https://photos.app.goo.gl/9hg1qehquAUfvT118
Likewise, although I deleted the integration and started again.
I didnt spend a lot of time troubleshooting why, but it is back running. Quite sluggish to button presses though.
Somewhere in your config.yaml you use probably āplatform: command_lineā which you need to take out because itās not supported anymore. Comment it out with # and see what happens after a restart. Maybe nothing maybe you need to resolve something.
I use the Nordtek HUSBZB-1 stick with Aqara devices just fine on Zigbee2MQTT tho, is there a requirement in your setup to use ZHA?
lost some automations after updating, they are gone from settings/automations but they are still present in automation.yaml. Any idea why? im using HAOS on a NUC.
here is a example of one
Other than not wanting to spend time migrating 45 devices and dealing with whatever weird things come up from doing that (and the fact that ZHA works perfectly up until 2023.05), no requirement.
Iāve seen very mixed reviews (and conflicting info on whether HUSBZB-1 is supported), and just havenāt ever felt the need to switch.
I do understand the pros of Z2M (separate service, survives reboots, etc) but HA reboots in 30 seconds and Iāve never had any issues because of that. ZHA and all of my Aqara sensors have just worked perfectly for years at this point (until it broke in 2023.05 with very little acknowledgement).
That said, I did switch to zwaveJS (although that one was forced since they dropped the old way) and I do like it. Had to make a day of switching everything over, but itās been solid for the last year or however long ago that was.
Thanks for confirming that HUSBZB-1 does work with it. Did you have to update firmware on it or anything? Iāve had it for nearly 4 years and itās on whatever firmware came with it (5.4.1.0 build 962).
Yeah I did update it. Thatās the only step that requires some gymnastics for Zigbee2MQTT (Z2M).
I found that there is better support for Aqara devices in Z2M than ZHA could provide for quite a few years now.
This link might help with the ZigBee chip firmware update..
Known working firmware details:
Coordinator type: EZSP v8
Coordinator revision: 6.7.10.0 build 423
Configuration required in Z2M - important:
serial:
adapter: ezsp
baudrate: 57600
As for ZWave - Have not touched the ZWave chip firmware since I got the stick, works perfectly fine in tandem with Z2M & Z-Wave JS.
.1 has dropped. That was quick
Just to confirm, on that page it says:
Nortek GoControl QuickStick Combo Model HUSBZB-1
Recommended Firmware: ncp-uart-sw-6.7.8.ebl
Yours says ā6.7.10.0ā and I donāt see anything newer than 6.7.8 in this repo.
Is āncp-uart-sw-6.7.8.eblā the one you installed?
Thanks!
I think anything later than the version I have should be fine. I just have not updated it in years.