iPhone on iOS 9 can't reconnect to bridge #31
Comments
|
Is this problem related to HomeControl? |
|
I can confirm this behavior. After a timeout (20-30 seconds) the connection is closed with "[INFO] Close connection and remove session" (https://github.com/brutella/hc/blob/master/netio/connection.go#L108) and iOS can not reconnect any longer. A restart of the HomeControl program fixes this problem imediatelly. |
|
Yeah, this seem to happen to me too. |
|
Same here. Initial pairing works as expected, but after toggling airplane mode my iPhone won’t reconnect. Is this maybe related to #25 ? |
|
If i on my iOS 9 device that won't reconnect (device says disconnected) deletes the connection to one of the brutella devices then i see the delete information on brutella console. So the connection isn't totally dead and removed. |
|
I have a similar issue with my iPhone running iOS 9.1. |
|
I've just tested it with an iPhone 6 running iOS 9.1, the latest version of HomeControl and the Home app. I could not reproduce the problem with the following steps:
If you experience the issue with the HomeKit Accessory Simulator, then it's definitely an iOS issue. |
|
I'm having the same issue with my iPhone 6S Plus, iPhone 5, iPad Air 2 and iPad 3, all running iOS 9.1. After paring with an accessory and losing connection (toggling Airplane mode, Wifi, or waiting a while) iOS isn't able to reconnect. When I remove the accessory and re-pair it, everything works as expected again until the connection is lost. The code is running on a Raspberry Pi in my case. I'm not able to download the HomeKit Accessory Simulator from the link you provided, as it isn't listed. Edit: This is weird: when I run the code on my Mac, everything is fine. The iPhone reconnects without a problem. It can't, however, reconnect to the exact same program when being run on my Raspberry Pi. |
|
@Obbut How did you compile the binary for your rpi? I think you have to use GOARM=5 instead of GOARM=6 because version 6 of the Raspberry has a floating point issue. See: http://selfcoded.com/blog/2015/07/31/diy-homekit-accessory.html under deployment. |
|
@0bscur3 I did indeed compile the binary using I just tried it, and I can confirm that using |
|
Compiling with |
|
I have the same issue with hc and hklifx. Before i disconnect from WiFi the light bulbs are controllable fine via Siri and the Home app. After reconnecting to my WiFi the bulbs are shown as not reachable. The only thing I can do to fix this is restarting the Bridge. Devices from Homekit Accessory Simulator are reachable instantly after reconnecting so it shouldn't be an iOS bug. I'm running hc/hklifx on FreeBSD in a Jail (FreeNAS) and all packages are up2date. Go version is 1.5.1 if this matters EDIT: I also don't get "[INFO] Close connection and remove session" after disconnect from network and waiting 10 minutes. I only get this message when closing the bridge EDIT2: Same issue on a rPi 2 with golang 1.5.1 on Raspian Jessie. Compiled on rpi with GOARM=7 and 5 - both have exact the same behaviour as the installation on FreeBSD. Whats your go version? |
|
Is this still an issue? |
|
Hi, have just tried it with a fresh go (version 1.6.1) installation inside a FreeBSD Jail. Same issue as some months ago |
|
Did you update to the latest hc changes? |
|
Yes - I did an complete clean install. I've just changed the broadcast address in pdf/golifx/protocol/v2.go to my subnet's broadcast - without this hklifx doesn't write anything in console/no lights get detected. Can this be the problem? Are tons of those messages in console are normal: |
|
Does all of your LIFX lights have a different name? |
|
Yes they have different names |
|
I've done dome debugging on the issue. It seems that the problem is something bonjour related. When I disable Wifi on iPhone all my bulbs are listed inside _hap._tcp. within bonjour browser. After about 30-60s after I reconnect my Phone to Wifi _hap._tcp. disappears completely from Bonjour Browser. The only way to fix it is by restarting hc/hklifx
|
|
I'm pretty sure this is related to mDNS. I've forked the bonjour library and made some changes. Please checkout the |
|
I've tested with your modified bonjour library. Indeed some "could not bind" error messages regarding IPv6 have disappeared, but the problem remains the same. _hap._tcp. disappears after some time after the iPhone is reconnected to wireless. EDIT: What also helps to bring the bulb back reachable in Home app is switching off the bulb, waiting some time and turn it on again. After this hklifx also finds the bulb again: 2016/04/20 08:36:16 [INFO] Discovered Device Martin |
|
Oddly enough I've had this issue since I began using this library. It's pretty simple to reproduce and I cannot reproduce it using the homekit simulator or the example provided in this repo, leading me to believe it's coming down to user error on my part (And quite possibly the same cause as above). Here's what it looks like in my instance (Repo here FYI: https://github.com/nickw444/homekit/tree/master/bridge) When pairing the bridge, I get this error:
Once pairing is complete, sometimes the accessories won't be able to be controlled (No response):
Upon restarting the homekit bridge all is good:
Until you go offline (i.e. airplane mode). |
|
After playing around for a little it seems to even be reproducible in the provided example code:
Initially I thought it may have been to do with using a Bridge type accessory as the first accessory, however that does not seem to be the case. In the example it also seems that toggling wi-fi brings the accessories back to life. (unlike in my actual usage where this does not bring them back to life). Example code I used using a bridge as the first accessory: package main
import (
"github.com/brutella/hc"
"github.com/brutella/hc/accessory"
"github.com/brutella/hc/log"
"time"
)
func main() {
switchInfo := accessory.Info{
Name: "BridgeLamp",
}
acc := accessory.NewSwitch(switchInfo)
bridge := accessory.New(accessory.Info{
Name: "TestBridge",
Manufacturer: "nickw",
Model: "bridge",
}, accessory.TypeBridge)
config := hc.Config{Pin: "12344321", Port: "12346", StoragePath: "./db2"}
t, err := hc.NewIPTransport(config, bridge, acc.Accessory)
if err != nil {
log.Info.Panic(err)
}
// Log to console when client (e.g. iOS app) changes the value of the on characteristic
acc.Switch.On.OnValueRemoteUpdate(func(on bool) {
if on == true {
log.Debug.Println("Client changed switch to on")
} else {
log.Debug.Println("Client changed switch to off")
}
})
// Periodically toggle the switch's on characteristic
go func() {
for {
on := !acc.Switch.On.GetValue()
if on == true {
log.Debug.Println("Switch is on")
} else {
log.Debug.Println("Switch is off")
}
acc.Switch.On.SetValue(on)
time.Sleep(5 * time.Second)
}
}()
hc.OnTermination(func() {
t.Stop()
})
t.Start()
}EditI have seemed to get it into a state in which I cannot get my phone re-connect to either instance: However, after waiting about a minute and toggling wifi back again, it seems like we're good again: |
|
Done a fair bit more playing around with this - it seems like some sort of timeout issue with bad Creating a bridge with a single accessory, almost always succeeds, when pairing I do not get the "could not complete operation" alert ever. Start adding more accessories, the likelihood of this gets greater. Additionally, it appears if I go to an area with lower wifi signal strength, the likelihood also increases for smaller number of accessories attached to a bridge. Looking at the source of hklifx, it appears each light detected actually creates it's own HC IP Transport: https://github.com/brutella/hklifx/blob/master/hklifxd.go#L155. Edit: Looks like I still have trouble pairing devices once I hit a ~10 even if they each have their own transport. Edit2: After going back to my original implementation (A single bridge accessory + numerous accessories), Adding 12 accessories appears to work fine - most of the time, however after adding an additional accessory, during pairing i am unable to even get past the "Pairing X, make sure it stays connected to power and nearby" screen. The log from HC outputs: Edit3: Refactored my project to allow passing in a dummy MQTT instance, just in case that was causing some goroutine scheduling weirdness - doing this had no effect 😢 |
|
Looking over at nfarina/homebridge, it appears they have similar issues: |
|
@nickw444 Did you test this without running an instance of an MQTT client? |
|
Yep, as mentioned above, I refactored my repo to allow DI of MQTT (using a simple interface), and passed a dummy implementation (which did not use MQTT at all) |
|
I should mention that all of my devices are running iOS 10 & tvOS 10, and I'm having these issues. I don't remember this cropping up until I added a 3rd bridged accessory. |
|
Same here, iOS10 on all my devices. Should also make note that the issue seemed more prominent when using an iPad (iOS 10) as a home hub - it's not as bad now though. I turned it off as a home hub, and it seemed to improve the situation. |
|
I shutdown my iPad at home, which was the original HomeKit host, so now it's just my ATV4 running. I also changed the default port number. The accessory connections have been stable for the past 45 minutes, so fingers crossed. |
|
@Tylerflick, how'd you end up? Any connectivity issues? |
|
hi , all! i have a same trouble. i had tested on macox , ubuntu. I try use my iphone 6 s with ios 10.3.2 |
|
My iphone was disconnected from bridge after 2-5 minutes |
|
Removing my iPad as a hub solved my issues, but I'm only running 3 accessories on my server. My setup is as follows:
|
|
Weird, I can reproduce consistently by building/running on an OSX El Cap machine- usually response errors during pairing, but after clicking through and restarting the bridge it all works (for a few minutes or until disconnection) Not so consistently (but rather intermittently) on a MacBook running Sierra; Building on the el-cap machine, targeting arm v5 or v6 and running on a Rpi2 seems to have occur but not as frequently - pairing almost always successful. Worth mentioning I have an ATV3 but (obviously, thanks apple) can't use it as a home hub. |
|
I'm wondering if this has something to do with Avahi. You're using an iPad as a hub? |
|
Yep, using an iPad as a hub but it's still intermittent with the iPad hub functionality turned off. It could quite be avahi, but if that was the case it should be working on macOS, since it uses mdns (or whatever it's called now) rather than avahi |
|
It could also be a firewall setting on your mac. I saw that suggestion pop up on of the linked issues. Have you looked at the port Homecontrol is running on? |
|
I think this issue comes up because the used bonjour library is not fully compliant with mDNS. The best way to verify that would be to use a different mDNS library and see what happens. |
|
That seems like a good idea, I might give that a shot on the weekend if I get some time. Worth noting, I took delivery of a lifx bulb, I am also experiencing the issue with the hklifx package too. |
|
So I updated all the dependencies for my project, recompiled, and it seemed that all my problems were gone. The bridge was working 100% of the time. After actually investigating the server where the service was running, I soon came to realise there was a bug in one of my deps, causing a panic every now and then - essentially restarting the bridge. This really got my hopes up - I really do wish we can figure out why mdns/bonjour is so flakey (in my usage at least). Also, would it be worth renaming this issue to something that doesn't specifically target iOS9 - this is definitely an issue with other OS versions. |
|
I've made a new dnssd library which passes the multicast DNS test of Apple's Bonjour Conformance Test – as you can see here. This library is for now used in the dnssd branch of HomeControl. Please check out this branch if you experienced connection issues in the past. Update on 11-October-2017: The changes are now merged into master. |
|
Awesome thanks @brutella. I’ll give it a shot when I get the chance (quite busy at the moment, and my setup is now working flawlessly using the PR I submitted so I’m not too inclined to potentially end up in another flakey situation again, as it’s not just me using HomeKit in my household). Side question- is there any reason you’re favouring using your own self rolled library rather than the zeroconf project? Just curious that’s all. |
|
@nickw444 I took it as a challenge to work on a new library and learn more about DNS. 😉 Also the zeroconf project doesn't fully comply with mDNS and DNS-SD. |
|
Sounds like a good enough reason to me 😃 I'll pilot the changes on the lifx bridge i'm running (a slightly modified hklifx). |
|
Closed due to inactivity |
iOS 9 connects and findes products in home app, after connection is lost (wifi | flight mode toggle on/off) and products remains disconnected..
Philips hue bridge connects right away (so no ios9/ iPhone problem)
The text was updated successfully, but these errors were encountered: