Forgot about that: they don’t work (yet) with the proxies, because they require an active connection. So for now only used using the BT hardware built in or an adapter.
Active is on the way though, believe next esphome update will support that on the proxies
I did not see anything in the repair notice. but I run a core only install. so perhaps that is why.
I do all my upgrades via automation. so a version bump is accounted for and automated. a complete re-name, URL’s gone. etc. breaks that process. just saying would have been nice to see that in the BC section. I see someone posted a PSA 2 weeks ago in the forum but I missed that post.
THANK YOU for subviews! I have been waiting for something like this for a long time. My use case is 15 smart RGB wafer lights. I currently have a button that controls them all together but have always wanted an easy way to jump to a subview to control them separately.
@CentralCommand is one person who gives heaps of help.
I looked at your issues. I don’t have this problem. I have a supervised install on debian 11 per the supervised rules. Appdaemon runs fine via the addon.
The docs for the addon say
Please note, the add-on is pre-configured to connect with Home Assistant. There is no need to create access tokens or to set your Home Assistant URL in the AppDaemon configuration.
This automatic handling of the URL and token conflicts with the AppDaemon official documentation. The official documentation will state
ha_urlandtokenoptions are required. For the add-on, however, this isn’t needed.
Given that your github issue specifies that you have configured some stuff that might conflict with those docs, but is hard to say as you don’t properly post your yaml.
This line looks wrong. Why would you set the url to an internet address? dash_url: http://182.100.0.15:5050
True but seeing that zwave is a major integration and a lot of people use zwavejs2mqtt I wouldn’t think it would be that out of the question to simply give everyone a heads up.
Hi to everyone,
yesterday I have updated the Core to the last version 2022.10, all works on my intergarions, exept Tuya.
I tried to reboot, to restart the service, to unistal and re-install the Tuya integration, but none of my wifi curtain switches or bulbs/lamps can be controlled anymore. In the integradion says taht all this device are disabled… I do not know how to solve… can someone help me?
Hi
I´am tracking my phone and MiBand 4 with ESPresense and would like to switch to Bluetooth proxy but it only shows the UUID from my phone and ignores the MiBand.
Did the MAC adresses just show up in your list or did you do something in your config to show UUID AND Mac?
I have bluetooth low energy monitor in integrations running with discovery on in the config for that integration. It’s currently picked up 13 devices from outside my house.
.1 already out, I see, but no release notes?
I don´t have Bluetooth on homeassistant itself, I only use ESPs.
Then your device list wasn’t from the new ibeacon integration, I misinterpreted that.
I think at the moment the ibeacon integration can’t replace ESPresense
Yes release notes https://www.home-assistant.io/blog/2022/10/05/release-202210/#release-2022101---october-6
Thanks for that. Indeed it was just a cache issue.
it reminds me shelly integration, where it’s not possible to disable either shelly integration or recognizing new devices (I’m using mqtt for shelies so I don’t care about the core integration).
very user friendly to dismiss about 100 devices one by one
I didn’t know there was a v2 
looks the same as v1 though…
Have you tried to flash it with custom firmware? like ATC?
yeah but we needed this ESPHome 2022.9.0 - 21st September 2022 — ESPHome
just released , and now updated, so fingers crossed this will work
If my memory serves correctly, you couldn’t flash the v2’s. Regardless of that, the battery life is not good on the v2s. That alone makes them much worse.
The design of thread(and by extention matter) is that the “hubs” act as border routers to the Thread mesh network, Petro’s comments where speculation based on a different radio tech used in Alexa and google Homes(zigbee).
A much better example of existing thread support to draw from is the Apple Home Pods, i dont have one for full details, but given how the thread spec specifies how the hubs should work and apples implementation, you should only need one hub as any hubs on the network will bridge the Thread Network onto your Ethernet/WiFi based networks.
also with matter they have to bridge to allow the Bluetooth and WiFi devices to work with the thread devices which support matter, so google and amazon shouldnt pull BS
Thread hubs provide 3 features, they translate the 6LoWPAN address to a normal IPv6 address on your network1 so that they can be controlled by client devices, in Apples implementation that was through homekit. They also provide some translation services to allow the thread devices to connect to the internet for updates if your home network does not have IPv6(NAT64/DNS64). and in some cases they provide always on control.
1A few extra details If you dont have a router that provides IPv6(Either from you ISP or a Local ULA(Unique Local Address)) they will advertise their own ULA and route for that so that other devices like you homeassistant instance can communicate to, if IPv6 support is turned on(it should be but some distros blacklist the kernel module for bad reasons)
