According to the homekit docs here
Discovery has to be specifically ENABLED for homekit for it to be discovered. This would indicate it can be excluded by this:
discovery:
ignore:
- homekit
Discovery has to be specifically ENABLED for homekit for it to be discovered. This would indicate it can be excluded by this:
1 Like
discovery:
ignore:
- homekit
Didn’t work. It’s really weird as I don’t have anything apple in my home. People who visit aren’t allowed on the same network as what I have on HA.
Are you saying it is seeing other devices as homekit devices?
That is correct. One that is already registered and set up is rachio. I can access all the zone switches just fine to run a quick 10 watering as well as the other information it provides. But even though it’s set up already, it shows up as a new homekit thing. My ultimate goal is to figure out how to completely remove homekit… because apple.
It’s broken for me also, I’ve tried to exclude google chromecasts using this and HA completely ignores my request
I’m not sure you can.
The homekit protocol is built into discovery now. 0.94: SmartHab, Watson TTS, Azure Event Hub
Discovery
Discovery has been mordernized thanks to @Kane610 and with the input from @Jc2k. Each integration is now able to specify how they can be discovered in their manifest, and the new
zeroconfandssdpintegrations will do the rest. The new discovery is non-obtrusive: no devices are set up without approval by the user. Instead, you will need to approve each discovered integration. You can find them in the discovered section of the integrations page in the config. Only a handful of integrations have been migrated to the new approach in this release: Hue, LIFX, Deconz, Trådfri, Axis, ESPHome, HomeKit Controller.The new discovery is now part of the default config. If you are not using the default config, add
ssdp:andzeroconf:to your configuration.yaml.
It looks like the docs weren’t updated when this integration was moved from the discovery integration to the zeroconf integration.
The new zeroconf and ssdp discovery mechanisms do not have ‘ignore’ like discovery used to. I asked here whether a feature like that would be added back, and the answer was no.
I also raised an architecture issue about stopping the notifications here. That seems to have stalled.
Right now the best workaround I have is to actually try and complete the HomeKit pairing. If it succeeds you can then delete the configuration entry and restart HA. That will leave the device thinking its paired, and HomeAssistant will now ignore it because it ignores paired devices. And you have now discarded the crypto keys - so thats actually more secure, because nothing can try and pair with it if its already paired and they can’t get the keys you just deleted. They’d have to be able to hard reset the device then.
If you’d prefer not to do that in your main HA, either use a throwaway clean install or do it on the command line with this library
Seperately to the annoying notifications, I just wanted to reassure you all from an Apple tin foil hat POV. I know many people are surprised (horrified, even) to find they have an Apple ecosystem on their network they didn’t know about. The way HomeKit works is by having a standard protocol to expose IoT devices on the local LAN and ensure they are securely paired and data is exchanged securely. There is nothing about this protocol that is tied to Apple beyond them having made it and making sure the accessories that support it arent utter crap heads that are lying about compliane. We have a completely open source Apple-free implementation of the controller end of HomeKit. This means that we can talk to any device that speaks the accessories end of the protocol, and we do not need Apple hardware or software involved to do it. For some HA users this is a god send - they have a choice between HomeKit (a local protocol that isn’t affected by AWS outages) or a cloud protocol. Note that even if you disable HomeKit support on the HA side, if you don’t pair them to something all your accessories will still be sat in HomeKit pairing mode on your network.
3 Likes
Is there any advantage to using the HomeKit setup instead of the LIFX (local) setup?
So, how do you go about a homekit pairing without any apple hardware? In your proposed questions on github, I’m in that first & third group for sure.
The workaround I have implemented is using the compact-header configuration and disable the bell.
Considering homekit is a rework of bonjour coupled with mDNS, there would be very little difference with LIFX (if any). Once a light is paired, it’s connected to a single account and managed as such… That account can manage the bulbs with or without internet/cloud connectivity. Also, the same bulbs can be accessed via guest accounts to turn on/off, change colors, or brightness. If using an assistant type thing (Google Home, IFTTT, that cortana thing, amazon’s alexa, or whatever apple calls theirs), you would need access to the cloud account at least for set up. No cloud is needed for LIFX unless you are needing to control them remotely. With LIFX I prefer the native method as I can use the cloud connection to control them remotely without going through another third party like apple’s thing.
I just set up local only using the Lifx app and use HA for remote control.
When you bought the devices they would have had a pairing code on the box that looks like 111-11-111. Sometimes its on a sticker on the device, sometimes its on the instructions. For devices that have a screen, it’ll likely display on the screen when you start configuring the device in HA. You need that. You click on the configure button in the HomeAssistant app, enter that code and it pairs. No app, no cloud account, no apple hardware, no internet.
1 Like
HomeKit doesn’t rework mDNS or Bonjour as such, it just uses them for discovery like every other mDNS-using piece of hardware. It’s a completely standard use of it, It’s not some incompatible fork of mDNS like e.g. Dyson use for their fans.
At a protocol level, its actually pretty much just vanilla mDNS for discovery and then a single TCP connection is used, with HTTP for payload framing and the JSON payload is encrypted with decent public key/private key mutually authenticated crypto.
HomeKit controller is currently a local polling implementation, so it beats remote polling and remote push from a privacy point of view and from a reliability point of view. For a local only protocol, its currently unlikely to beat the native implementation unless the pairing process is particularly arduous. In the future we’ll be moving to a push based implementation which will mean we beat polling implementations on functionality. But that just means if you turn a light on or off with the native app HA will find out a bit quicker, so not that exciting for light bulbs.
HomeKit controller (which is the bit detecting your LIFX bulbs) has got nothing to do with Apple’s assistant (Siri), and doesn’t involve the cloud. If you want to control a HA device with an iPhone or with Siri there is a seperate homekit component (homekit: in your config) that can expose any HA entity. It makes your HomeAssistant instance look like a HomeKit bridge to your iPhone/iPad. So you could have HA control your bulbs with the LIFX protocol, then have an iPhone control your HA with the HomeKit protocol. In otherwords, there are 2 integrations and between them HomeAssistant can speak both “ends” of the HomeKit protocol on its own.
If you wanted to remote control HomeKit devices that you had paired to HomeAssistant I would probably say to use on of the HomeAssistant remote access. There is a paid for remote access feature, but i just have a VPN. Going via VPN means I can control things remotely without any third party servers - be it Apple’s or LIFX’s - this is true of whether i was using the native implementation or the HomeKit controller one.
2 Likes
I was an early adopter of the specific product which didn’t offer homekit support when it was initially released. So there’s no pin on the box, instructions, or hardware. Reading the instructions on rach.io I would be required to use the homekit application on an apple device to create the ID. That’s not about to happen any time soon. I can see this issue continuing to happen going forward. No way to create a pin for devices but constant reminder notifications through the “discovery bell” every few minutes after constant dismissal. The only viable option I’ve found so far is to hide the bell completely and ignore it until I have a new integration I want to add. For that, it would just be smart to use the integrations configuration instead. But then that leaves an issue of lack of notification about important things like failed login attempts. I know there are more out there in my situation.
On a sidenote, my LIFX bulbs don’t show up on this “homekit discovery” of other already set up devices. When LIFX was offering their z-strip lights without homekit support at a heavy discount (less than half price at the time), I picked up a bunch.
1 Like
Correct! In my case… Yeelight Bulbs are recognised as HomeKit Accessories and I can´t configure it because I don´t have the code with this format XXX-XX-XXX… 
3 Likes
I don’t know if this is still possible, but if you can reach the configuration files of the components. You could simply add the Yeelight to the ignore list.
The file should live in the homekit component files. I will take a look later on and update this post with the actual location/filename. It worked for me in the past with Tado. However I use the controller now so I don’t need this method anymore.
Keep in mind that it will be overwritten every time you update HA unless you make a custom component out of it.
1 Like
Actually, yes and no. I didn’t find the location, however I did go to the home assistant github page and checked out the component there. It would be better to create a custom component than to modify core files. However, when getting to the component, it seems the component has changed entirely since the change to zeroconf (which is quite a few HA updates ago). It seems that what I was talking about is no longer possible with the current component. Yes it used to work for the old one, but the old one could also be excluded from discovery (which I believe the current one can not unless you turn off zeroconf entirely).
I did try to look into different files for you on the repo, but to no avail. I guess you will have to ask the HA devs if there is a way to do this. (unfortunately I think I have read somewhere that it isn’t possible unless you turn off zeroconf, which in turn will turn off discovery entirely). I hope this answer helps, even though it is not satisfying.
@jimz011 Cheers Jim - I thought that that might be the case but was holding on to s sliver of hope LOL. I’ll just have to keep on getting the Yeelight discovery notice forever!
Looks like something is coming down the track.
I need this to stop my LG TV being discovered all the time as a homekit accessory.