[Discovery]how to force Home Assistant to re discover entities

局域网自动发现协议有很多，比如

  

     mDNS

    1. DNS-SD(DNS Service Discovery)：基于DNS协议的服务发现

    2. SSDP(Simple Service Discovery Protocol)：简答服务发现协议

    3. NBNS(NetBIOS name service)：NetBIOS名称服务(已过时)

主要的UDP组播应用协议有：

mDNS
SSDP/uPnP
Apple AirPlay
DLNA，各类媒体播放器

[Discovery]how to force Home Assistant to re discover entities

how to force Home Assistant to re discover entities


Homekiter Controller delete .storage/homekit_controller-entity-map

So you have a working Aqara Hub (with other accessories). This was already paired with Home Assistant and works fine?

At a later date you have added the switch to your Aqara Hub, but Home Assistant doesn't see it?

Can you backup and then delete .storage/homekit_controller-entity-map. (This will be in the same folder as your configuration yaml). Then restart Home Assistant. This will force Home Assistant to re-probe the hub to discover entities. Normally this is automatic, but it might not have worked for you.

homekit_controller

https://www.home-assistant.io/integrations/homekit_controller

If your device is not on this list then you may still be able to pair it, and it will be visible in the Device Registry. But Home Assistant may not create entities for it.

HomeKit IP accessories for these device types may work with some caveats:

If the device is Wi-Fi based and has no physical controls or screen then you may need an Apple HomeKit device like an iPhone or iPad to get the accessory onto your Wi-Fi network. For example, for a Koogeek LS1 you must add the accessory to HomeKit on your iOS device, then remove it from the iOS device. This leaves the LS1 in an unpaired state but still on your Wi-Fi. Home Assistant can then find it and pair with it.
You need to know the HomeKit PIN. There is no way to recover this if you do not have it. In this case, you will need to contact the manufacturer to see what options you have.
HomeKit controller will poll your devices, but it will also automatically enable push updates for accessories that support it.

how to force Home Assistant Homekit Controller integration to rediscover entities
https://blog.matterxiaomi.com/blog/force-home-assistant-rediscover-part2/

Homekit-controller cannot send request to pair with device

https://github.com/home-assistant/core/issues/14320

MIIO COMMAND LINE TOOL

Miio devices

Use of Miio should be done before the Vacuum is connected to Mi Home.

If you already connected to the app you will need to delete it and then join the ad-hoc Wi-Fi network the Vacuum creates.

If the vacuum is already paired it’s likely this method will only return ??? as your token.

https://www.home-assistant.io/integrations/xiaomi_miio/

[Discovery]Yeelight 1S Color -  force Home Assistant to re discover entities

del it from yeelight app  30649278

删除后，米家app里面改灯也已经同步删除


重新添加情况

1.用Yeelight app添加，按照操作手册，死活添加失败，说找不到设备

2.用mi home app 添加成功。用mi home app 添加，立即自动发现此灯，添加成功。

此步测试Discovery情况

homekit controller能自动发现此灯
yeeligt  integration 不能自动发现此灯
手工添加失败。

Yeelight app 开启 Lan control后

homekit controller能自动发现此灯
yeeligt  integration 不能自动发现此灯

yeelight integration
homekit controller integration

yeelink.light.ceiling21 by alone's Miio for Yeelink ？
ip + token？
miot auto integration

So with homekit the firmware updates are largely applied using the vendor app, rather than the Home app. And this typically means through a private non-homekit api. Nanoleaf is no exception.

Some vendors do have update APIs that we could implement, but for those we don't know where to get the firmware from or if it needs pre-processing. (Again, to be clear, nanoleaf isn't one).

We might at least be able to flag if an update is needed. But only for devices that are in this file: https://configuration.apple.com/configurations/internetservices/HomeKit/v1/ManufacturerDatabase.plist. But we don't know if that's still the canonical location.

https://configuration.apple.com/configurations/internetservices/HomeKit/v1/ManufacturerDatabase.plist

<plist version="1.0">
<dict>
<key>DataVersion</key>
<integer>67</integer>
<key>Manufacturers</key>
<dict>
<key>10 Plusair (Beijing) Tech Co., Ltd</key>
<dict>
<key>Models</key>
<dict>
<key>DX-100-B-SJT1-HK</key>
<dict>
<key>BundleID</key>
<string>com.10plusair.xinfeng</string>
<key>StoreID</key>
<string>1435450474</string>
<key>FirmwareVersion</key>
<string>2.3.21</string>
<key>ProductData</key>
<string>686d5eb2c3774c2b</string>
</dict>
</dict>
<key>DefaultModel</key>
<dict>
<key>BundleID</key>
<string>com.10plusair.xinfeng</string>
<key>StoreID</key>
<string>1435450474</string>
</dict>
</dict>
<key>1Home</key>

HomeKit only lets you have one pairing at a time

If you unpair a device from HA while it is not connected (be it a bug, or it's just off or out of range) then it won't be able to clean the encryption keys off it before it is removed from HA. HomeKit only lets you have one pairing at a time, so you'll have to hard reset this device to get it pairable again. On my eve Energy there is a button on top that you press and hold for 10-20 seconds. When it flashes (red for mine), you can release.

Option One: Reset Your HomeKit Device
Option Two: Reset Your HomeKit Configuration


There are two types of resets you can perform with HomeKit devices:

you can press the physical reset button on the device itself,

or

you can reset of the HomeKit configuration on your controlling iOS device.

Option One: Reset Your HomeKit Device

Some products may require that you press the button while the device is unplugged and then plug it in while still pressing the reset button (or some variation like that).

The downside to performing a factory reset on your hardware is that any settings stored on the device itself (and not the companion application)--like Wi-Fi credentials, schedules, configuration files, and so on--will be wiped back to their factory state.


Option Two: Reset Your HomeKit Configuration

Remove Home

https://www.howtogeek.com/230906/how-to-reset-your-homekit-devices-and-configuration/

https://github.com/home-assistant/core/blob/dev/homeassistant/components/homekit_controller/connection.py

RETRY_INTERVAL = 60  # seconds
MAX_POLL_FAILURES_TO_DECLARE_UNAVAILABLE = 3


BLE_AVAILABILITY_CHECK_INTERVAL = 1800  # seconds

homekit_controller对蓝牙设备检测时间是1800秒

https://github.com/home-assistant/core/blob/dev/homeassistant/components/homekit_controller/manifest.json

 "zeroconf": ["_hap._tcp.local.", "_hap._udp.local."],
  "bluetooth": [{ "manufacturer_id": 76, "manufacturer_data_start": [6] }],
  "dependencies": ["bluetooth_adapters", "zeroconf"],
  "codeowners": ["@Jc2k", "@bdraco"],
  "iot_class": "local_push",
/code]


https://github.com/home-assistant/core/blob/dev/homeassistant/components/homekit_controller/storage.py

[code]class EntityMapStorage:
    """
    Holds a cache of entity structure data from a paired HomeKit device.
    HomeKit has a cacheable entity map that describes how an IP or BLE
    endpoint is structured. This object holds the latest copy of that data.
    An endpoint is made of accessories, services and characteristics. It is
    safe to cache this data until the c# discovery data changes.
    Caching this data means we can add HomeKit devices to HA immediately at
    start even if discovery hasn't seen them yet or they are out of range. It
    is also important for BLE devices - accessing the entity structure is
    very slow for these devices.
    """

zeroconf cannot bind the port 5353, and my device (a tahoma box) is not detected by the HomeKit controller integration of the new instance of home assistant.
https://community.home-assistant.io/t/homekit-controller-intergration-bypass-zeroconf/502961

sudo netstat -ntulp | grep 5353

root@raspberrypi:/home/homeassistant20221103/.homeassistant/.storage# sudo netstat -ntulp | grep 5353
udp        0      0 192.168.2.50:5353       0.0.0.0:*                           13357/python3.11    
udp        0      0 192.168.2.50:5353       0.0.0.0:*                           22095/python3.11    
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           1286/hb-service     
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           408/avahi-daemon: r 
udp6       0      0 :::5353                 :::*                                408/avahi-daemon: r 
udp6       0      0 :::5353                 :::*                                22095/python3.11    
udp6       0      0 fd18:f22c:7814:d90:5353 :::*                                22095/python3.11    
udp6       0      0 :::5353                 :::*                                13357/python3.11    
udp6       0      0 fd18:f22c:7814:d90:5353 :::*                                13357/python3.11