Auto discovered HomeKit Controller integration cannot be ignored

[heisenberg2980]

The problem

The Heatmiser neoHub (Bridge) HomeKit Controller integration cannot be ignored once it has been discovered by Home Assistant:

What version of Home Assistant Core has the issue?

2022.10.0

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

HomeKit Controller

Link to integration documentation on our website

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

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[homeassistant]

Hey there @jc2k, @bdraco, mind taking a look at this issue as it has been labeled with an integration (homekit_controller) you are listed as a code owner for? Thanks! _{^{(message by CodeOwnersMention)}}

---

homekit_controller documentation homekit_controller source _{^{(message by IssueLinks)}}

[heisenberg2980]

Hi @bdraco, I am trying to create a pull request for this change as I believe it should be pretty straightforward for someone with knowledge of the integration (unfortunately I don´t have this knowledge, but trying to get it through some analysis). I understood according to https://developers.home-assistant.io/docs/config_entries_config_flow_handler/#unique-ids that in order for the integration to be ignored it needs to have a unique id, so I am guessing that unique id is missing for my device (Heatmiser neoHub (Bridge)), do you know what file of the integration should I be editing to add this unique ID for bridges?

[Jc2k]

Every integration that has a config flow has a file called config_flow.py, and thats where all the discovery and pairing stuff lives.

Here are the places where we set the unique id you are refering to:

• https://github.com/home-assistant/core/blob/eb0828efdb672c4861125fa4c02933a3943ea911/homeassistant/components/homekit_controller/config_flow.py#L142 (manually adding an integration)
• https://github.com/home-assistant/core/blob/eb0828efdb672c4861125fa4c02933a3943ea911/homeassistant/components/homekit_controller/config_flow.py#L181 (when un-ignoring)
• https://github.com/home-assistant/core/blob/eb0828efdb672c4861125fa4c02933a3943ea911/homeassistant/components/homekit_controller/config_flow.py#L256 (zeroconf)
• https://github.com/home-assistant/core/blob/eb0828efdb672c4861125fa4c02933a3943ea911/homeassistant/components/homekit_controller/config_flow.py#L367 (bluetooth)

We try to set the id as early as possible in the flow to avoid duplicates etc.

We use the "hkid" as the unique id. This is generated by the device every time you reset it but is otherwise persistent, and looks like a MAC address - but it isn't a MAC address. This is often a source of confusion. We do not use the MAC address because it doesnt work when there are routers etc on the network path. We dont use the serial number any more because it is not provided by all manufacturers and there is a risk of collision. We do not use per device or vendor magic hacky workarounds because its a maintenance burden and Apple's implementation doesn't need that.

Here it is working on the current stable release:

Any changes to config_flow.py need tests. Changes likely won't pass review unless you hit 100% coverage on that file.

[heisenberg2980]

Ok, that certainly seems like a less "easy to fix" issue than I though. @Jc2k do you know why this unique ID is not working with my device (Heatmiser neoHub (Bridge)) or what I can do to find out? I have other HomeKit devices and it is working fine for all of them except this one, so I guess they issue might be with the device itself, but I would like to try and fix it because it is pretty annoying having the "new devices has been discovered" notification every time I restart HA.

My guess is the device is not generating a hkid, is that possible? and in that case, could any of the other options you mention (i.e. MAC address) be used as an alternative so at least the devices having this issue can be ignored?

[Jc2k]

I don't have one of these, so you are in a better place to answer some of these questions than me 😆. You could add some debug logs or prints to the places i linked to and see what hkid is getting set to. You could turn on debug logs for the zeroconf package so we can see what the raw zeroconf records for this device look like.

If there was no id field present at all we'd consider it to be violating the HAP specs so badly that we wouldn't believe it was a real HomeKit device and we wouldn't show it in the first place, so i don't think that its that there is no id present at all. It could be getting set to something stupid that is breaking an assumption somewhere though.

[heisenberg2980]

Good idea, I will add some debug logs and share what I find. Thank you very much for the guidance.

[heisenberg2980]

Just one favour @Jc2k, any link/tutorial you can point me to of how to add debug logs to the integration in my HA installation? (I am running Home Assistant OS in a Proxmox VM)

[Jc2k]

What bit are you stuck on? Do you know how to turn on the log level to debug? Do you know how to edit files in the container?

[heisenberg2980]

I just found this guide explaining how to debug HA: https://developers.home-assistant.io/docs/operating-system/debugging/

I will follow it and hopefully once I get access to HA through port 22222 I will be able to change the log level to debug and add the debug lines to the code.

[heisenberg2980]

@Jc2k so far I have been able to turn on the log level to debug for zeroconf, and after restarting HA I am getting these lines (filtering by the name of the device "neoHub"):

2022-11-05 22:37:20.763 DEBUG (MainThread) [homeassistant.components.zeroconf] service_update: type=_hap._tcp.local. name=Heatmiser neoHub._hap._tcp.local. state_change=ServiceStateChange.Added
2022-11-05 22:37:20.764 DEBUG (MainThread) [homeassistant.components.zeroconf] Discovered new device Heatmiser neoHub._hap._tcp.local. ZeroconfServiceInfo(host='192.168.0.98', addresses=['192.168.0.98', 'fe80::409d:33ff:fe73:f930'], port=4238, hostname='imx6ulevk.local.', type='_hap._tcp.local.', name='Heatmiser neoHub._hap._tcp.local.', properties={'_raw': {'c#': b'7', 'ff': b'1', 'id': b'', 'md': b'Heatmiser_neoHub', 'pv': b'1.1', 's#': b'1', 'sf': b'1', 'ci': b'2', 'sh': b'jtyOIg=='}, 'c#': '7', 'ff': '1', 'id': '', 'md': 'Heatmiser_neoHub', 'pv': '1.1', 's#': '1', 'sf': '1', 'ci': '2', 'sh': 'jtyOIg=='})

I have also been able to ssh through port 22222, but I don´t know how to find the file you mentioned core/homeassistant/components/homekit_controller/config_flow.py, is it inside container "ghcr.io/home-assistant/amd64-hassio-supervisor:latest" or a different one?

And one more question, once I find the file and update it to add debug/print lines, will the changes stay after I restart HA or will the changes to the file be reverted back? if the later, my understanding is HA executes those lines and discovers this device just after restart, so how can I execute the added lines once HA has already started?

[bdraco]

There is the problem 'id': ''

Its actually has an empty id!

[heisenberg2980]

I guess that is good news because we know what the issue is, now we just need to figure out how this device passed the HAP specs validations @Jc2k mentioned so we can avoid this device (and any other device without id) popping up as a discovered device in HA.

[Jc2k]

In general if a device has gotten through certification we would want to try and support it, and we have worked around some nasty bugs to do this so far, including multiple bugs in basic JSON support.

That said, normally we do that to help a user to use homekit_controller.

Beyond using it in config flow and in unique ids, we also use hkid to route c#, ip and port changes to active connections. And we'd have to do the changes to the coap and tcp backends as they both use mdns. So unless my coffee hasn't kicked in yet, a lot of work to support this device. Given you don't actually want to use it with HomeKit I am in favour of just dropping discoveries where id is blank, unless @bdraco has any thoughts on making it work.

Out of interest, is it's firmware up to date? Do you have an iOS device? (I'd be interested to see what happened if you paired and unpaired it with iOS).

[Jc2k]

And have you tried restarting the hub?

[heisenberg2980]

I agree that dropping discoveries when id is blank seems like the best option.

I do have an iOS device and when I tried to pair the device with homekit it didn´t work, so I reset the homekit configuration following the instructions from https://faq.heatmiser.com/hc/en-us/articles/360001693040-I-am-unable-to-pair-my-neoHub-to-HomeKit and it is weird because after restarting HA I can now see the device twice, one without ID (that is giving an error when trying to configure it and I cannot ignore either) and another one with ID (that I can ignore and if I try to configure it, it ask for the HomeKit pairing code instead of giving the error). These are the logs now:

2022-11-06 09:54:01.047 DEBUG (MainThread) [homeassistant.components.zeroconf] service_update: type=_hap._tcp.local. name=Heatmiser neoHub._hap._tcp.local. state_change=ServiceStateChange.Added
2022-11-06 09:54:01.048 DEBUG (MainThread) [homeassistant.components.zeroconf] Discovered new device Heatmiser neoHub._hap._tcp.local. ZeroconfServiceInfo(host='192.168.0.98', addresses=['192.168.0.98', 'fe80::e48b:45ff:fe19:689c'], port=4238, hostname='imx6ulevk.local.', type='_hap._tcp.local.', name='Heatmiser neoHub._hap._tcp.local.', properties={'_raw': {'c#': b'7', 'ff': b'1', 'id': b'', 'md': b'Heatmiser_neoHub', 'pv': b'1.1', 's#': b'1', 'sf': b'1', 'ci': b'2', 'sh': b'jtyOIg=='}, 'c#': '7', 'ff': '1', 'id': '', 'md': 'Heatmiser_neoHub', 'pv': '1.1', 's#': '1', 'sf': '1', 'ci': '2', 'sh': 'jtyOIg=='})
2022-11-06 09:54:01.237 DEBUG (MainThread) [homeassistant.components.zeroconf] service_update: type=_hap._tcp.local. name=Heatmiser neoHub (2)._hap._tcp.local. state_change=ServiceStateChange.Added
2022-11-06 09:54:01.238 DEBUG (MainThread) [homeassistant.components.zeroconf] Discovered new device Heatmiser neoHub (2)._hap._tcp.local. ZeroconfServiceInfo(host='192.168.0.98', addresses=['192.168.0.98', 'fe80::e48b:45ff:fe19:689c'], port=4238, hostname='imx6ulevk.local.', type='_hap._tcp.local.', name='Heatmiser neoHub (2)._hap._tcp.local.', properties={'_raw': {'c#': b'7', 'ff': b'1', 'id': b'22:3A:D8:8E:B3:0E', 'md': b'Heatmiser_neoHub', 'pv': b'1.1', 's#': b'1', 'sf': b'1', 'ci': b'2', 'sh': b'+i+ADA=='}, 'c#': '7', 'ff': '1', 'id': '22:3A:D8:8E:B3:0E', 'md': 'Heatmiser_neoHub', 'pv': '1.1', 's#': '1', 'sf': '1', 'ci': '2', 'sh': '+i+ADA=='})

[Jc2k]

It's possible you have an mdns reflector on your network that has cached the old record. It should expire and then next time you restart ha it will be gone. Would be good to rule that out.

[heisenberg2980]

I use pi-hole to manage DNS in my network, and I can confirm after restarting pi-hole and then HA finally the entity doesn´t come up anymore, so my issue is solved.

I still think discovery should ignore devices until they provide an ID so other users don´t find this problem with this or other devices, so should I close this issue or keep it open to track that change?

[Jc2k]

I don't think it's an option to leave it like it is, and given you couldn't pair it with iOS im even less inclined to make it work without an id (because it's not clear that it can). So I think we should add a debug log entry and ignore it.

[bdraco]

Ignore is the way to go for this one. It’s never going to work without an id as there is no way to map it

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.