probot-home-assistant[bot]
commented
4 years ago Hey there @bdraco, mind taking a look at this issue as its been labeled with a integration (homekit) you are listed as a codeowner for? Thanks!
Closed Ttech closed 3 years ago
probot-home-assistant[bot]
commented
4 years ago Hey there @bdraco, mind taking a look at this issue as its been labeled with a integration (homekit) you are listed as a codeowner for? Thanks!
probot-home-assistant[bot]
commented
4 years ago Hey there @Jc2k, mind taking a look at this issue as its been labeled with a integration (homekit_controller) you are listed as a codeowner for? Thanks!
Jc2k
commented
4 years ago This is a possibly a problem with the zeroconf library (not the HA integration). We've seen a bunch of cases recently where devices on your network which are almost but not quite standards compliant can sometimes be discovered and some times not be. We've already fixed one of these recently where a totally unrelated HomeKit device could actively interfere with the pairing process, but you should have that fix already.
First of all can you first follow the steps in this comment and attach the output:
https://github.com/home-assistant/core/issues/33085#issuecomment-606206419
It will run forever (its monitoring the network for changs), so press Ctrl+C to get out of it when it stops producing output.
Ideally run it on the same machine as your Home Assistant so we can rule out any networking weirdness.
Ttech
commented
4 years ago I got the output from that tool, but it doesn't show up as _hap which I presume is Home Assistant, or _http, instead shows up as _airplay. I had to use a different app to see that.
Got the HAP results now for the TV:
And here's the output from the other tool:
Service HP Color LaserJet MFP M277dw._http._tcp.local. of type _http._tcp.local. state changed: ServiceStateChange.Added
Addresses: 172.24.40.100:80
Weight: 0, priority: 0
Server: printer.local.
Properties are:
b'UUID': b'5*SCRUB*-3ca82af89fd9'
Service HP Color LaserJet MFP M277dw._http._tcp.local. of type _http._tcp.local. state changed: ServiceStateChange.Updated
Service powernap._http._tcp.local. of type _http._tcp.local. state changed: ServiceStateChange.Added
Addresses: 172.24.42.205:8080
Weight: 0, priority: 0
Server: powernap.local.
Properties are:
b'path': b'/'
Service powernap._http._tcp.local. of type _http._tcp.local. state changed: ServiceStateChange.Updated
Service Web on pegasus._http._tcp.local. of type _http._tcp.local. state changed: ServiceStateChange.Added
Addresses: 172.24.40.4:80
Weight: 0, priority: 0
Server: pegasus.local.
No properties
Service Web on pegasus._http._tcp.local. of type _http._tcp.local. state changed: ServiceStateChange.Updated
Service ds._http._tcp.local. of type _http._tcp.local. state changed: ServiceStateChange.Added
Addresses: 172.24.42.13:5000
Weight: 0, priority: 0
Server: ds.local.
Properties are:
b'vendor': b'Synology'
b'model': b'DS213+'
b'serial': b'*SCRUB*'
b'version_major': b'6'
b'version_minor': b'2'
b'version_build': b'24922'
b'admin_port': b'5000'
b'secure_admin_port': b'5001'
b'mac_address': b'*SCRUB*'
Service ds._http._tcp.local. of type _http._tcp.local. state changed: ServiceStateChange.Updated
_hap is indeed what i need to see. It stands for HomeKit Accessory Protocol AIUI. Can you try with the python script and _hap again, it looks like you ran with _http maybe.
This python script is using the same library Home Assistant uses to discover your devices, so it's behaviour is more important than other zeroconf apps. If it sometimes can and sometimes can't see your device it may be a bug we need to raise with them, and it's likely the reason for the error you are seeing.
So far it sounds like it couldn't detect your TV at least once so far, as that's why you used a completely seperate app. So we need to keep stopping and starting that script and try to work out if its random about when it can and can't see the TV or if there is a pattern to it. Try and figure out if theres any external factor. Does the state of the TV matter? Does not running the script or any zeroconf apps for half an hour and then trying mean it doesn't work?
BTW, I don't think the python zeroconf library depends on avahi - its a pure python implemtation of the protocol. Maybe it's worth turning avahi off in case that is interfering some how.
Do you have a firewall? There's another possibility that a firewall that has connection state tracking and sees outbound udp zeroconf traffick (HA announcing itself) might temporarily allow inbound zeroconf udp traffic. As UDP is stateless, the connection state tracking is based on heuristics so is fun like that.
If that screenshot is from a Mac, you should be able to run the zeroconf script on a mac too. So you can see if you get different behaviour from different parts of your network.
Ttech
commented
4 years ago Firewall allows 5353 and 3702 input and forwarded. Hopefully this helps, HA said it found a new device (the tv), I clicked configure and nothing happened as usual
Browsing services, press Ctrl-C to exit...
Service Home Assistant Bridge._hap._tcp.local. of type _hap._tcp.local. state changed: ServiceStateChange.Added
Addresses: 172.24.40.36:51827
Weight: 0, priority: 0
Server: Home Assistant Bridge._hap._tcp.local.
Properties are:
b'md': b'Home Assistant Bridge'
b'pv': b'1.0'
b'id': b'D7:07:5E:D6:5B:8B'
b'c#': b'2'
b's#': b'1'
b'ff': b'0'
b'ci': b'2'
b'sf': b'1'
b'sh': b'2IbBzg=='
Service Home Assistant Bridge._hap._tcp.local. of type _hap._tcp.local. state changed: ServiceStateChange.Updated
Service Family Room._hap._tcp.local. of type _hap._tcp.local. state changed: ServiceStateChange.Added
Addresses: 10.22.44.36:80
Weight: 0, priority: 0
Server: Family-Room.local.
Properties are:
b'c#': b'3'
b'ff': b'1'
b'id': b' (SCRUB)'
b'md': b'LIFX A19'
b's#': b'1'
b'sf': b'1'
b'ci': b'5'
b'pv': b'1.1'
b'sh': b'eBFnOw=='
Service Family Room._hap._tcp.local. of type _hap._tcp.local. state changed: ServiceStateChange.Updated
Service Living Room._hap._tcp.local. of type _hap._tcp.local. state changed: ServiceStateChange.Added
Addresses: 10.22.44.35:80
Weight: 0, priority: 0
Server: Living-Room.local.
Properties are:
b'c#': b'2'
b'ff': b'1'
b'id': b'(SCRUB)'
b'md': b'LIFX A19'
b's#': b'1'
b'sf': b'1'
b'ci': b'5'
b'pv': b'1.1'
b'sh': b'avlfJA=='
Service Living Room._hap._tcp.local. of type _hap._tcp.local. state changed: ServiceStateChange.Updated
Service Thermostat._hap._tcp.local. of type _hap._tcp.local. state changed: ServiceStateChange.Added
Addresses: 10.22.44.90:1200
Weight: 0, priority: 0
Server: Thermostat.local.
Properties are:
b'c#': b'7'
b'ff': b'1'
b'id': b'(SCRUB)'
b'md': b'ecobee3 lite'
b'pv': b'1.1'
b's#': b'1'
b'sf': b'0'
b'ci': b'9'
b'serial_number': b'(SCRUB)'
b'MFG': b'ecobee Inc.'
Service Thermostat._hap._tcp.local. of type _hap._tcp.local. state changed: ServiceStateChange.Updated
Service Family Room TV._hap._tcp.local. of type _hap._tcp.local. state changed: ServiceStateChange.Updated
Service Family Room TV._hap._tcp.local. of type _hap._tcp.local. state changed: ServiceStateChange.Added
Addresses: 172.24.42.15:35085
Weight: 0, priority: 0
Server: Android.local.
Properties are:
b'c#': b'1'
b'ci': b'31'
b'ff': b'8'
b'id': b'54:CA:1C:EC:40:5D'
b'md': b'XBR-55X850G'
b'pv': b'1.1'
b's#': b'1'
b'sf': b'1'
b'sh': b'9xX8dw=='
Djowie
commented
4 years ago I got the same issue, the homekit integration can't seem to connect to the tv anymore. The controls via Home Assistant itself seem to work fine.
Ttech
commented
4 years ago New Device was attempted to be paired on Home Assistant via HomeKit and it also displayed the unknown error
Jc2k
commented
4 years ago @Ttech what was the new device?
The current plan is to rewrite how Home Assistant passes it's version of the discovery to homekit, to reduce the number of discoveries that are required. That should "fix" the case where it see's the device but then loses it again. But it will be a while before I have the free time to do that.
This shouldn't be needed for it to work though. There's still something environmental which is interfering with zeroconf that I can't reproduce over here. It's annoyingly common, but i've not had much look narrowing it down.
github-actions[bot]
commented
3 years ago 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.
Problem: When attempting to new device to HomeAssistant via HomeKit it sits at "Configuring Integration" for a while, eventually timing out. If you restart the TV and Home Assistant, it will trigger the HomeKit pairing, entering the code on Home Assistant will trigger a confirmation on the TV. However the TV considers its self paired, while "an unknown error" takes place on Home Assistant.
Expected behavior is to successfully pair with the TV and control it.
Environment: venv install on Debian, avahi installed as well as dependencies. $hass --version 0.108.7 HomeKit Integration
Packages List:
Problem-relevant
configuration.yamlTraceback/Error logs
Additional information