I’m having huge issues trying to get Home Assistant added to my Home App. I’ve done a clean install of Hassio, reinstalled Homebridge @frenck version twice, I’ve tried connecting to same Wifi on both 2.4ghz and 5ghz. The problem is I can see Home Assistant appear in my Home App, when I enter the Pin code I get the following error: “Couldn’t add Home Assistant. The Set-up code is incorrect.”
Does anyone know how to overcome this? I’ve even attempted to change the host IP… 
you could see 2 following"-" in the example pincode. This is one too many.
Best to change the pin in config.json in \config\homebridge\ to
"pin": "926-69-796"
Version 1.0.0 of my addon has a bug with the generated pin code, containing an extra dash.
e.g. it generates a pin like this 123--12-123, it should have been 123-12-123.
I’ve already fixed this issue and released version 1.0.1.
You can easily fix this by changing the pin code in your configuration file (/config/homebridge/config.json).
I did notice that, and I did remove it and I also added double dashes on both sides. I’ll give it another shot in a few hours. Do we know if it works with iOS11? It should do!
It should… I’m not sure, I’m not running any iOS11 devices at the moment.
Thanks Franck, that worked great. I am having other issues, but not sure if it is me or hassio. I will investigate and seek assistance if needed.
Thanks again.
It will. I have iOS 11 running on an iPad acting as a home hub; and a mix of iOS 11/10 devices in the home and they all function properly.All the iOS devices are shared from the one account on the iPad so it’s seamless between devices.
The only difference is when in the home app and adding the component. Apple is trying to get people to add everything via the camera; which is not an option for Homebridge. There is a little link below that says “If you do not have a code or can’t scan” click that and enter the pairing pin and the Homebridge instance should then show up or auto pair.
Yes, thanks for that. I managed to get it working after removing the double dash in the pincode, restarting Homebridge and Hassio. After linking it I got Siri to activate a third party light within 30 seconds, I’m extremely happy and can not wait to continue to build on my Home Automation!
Simply add “verify_ssl”: false to the config.json
{
"bridge": {
"name": "Home Assistant",
"username": "B4:53:CF:55:2A:54",
"port": 51826,
"pin": "664-12-345"
},
"description": "Homebridge for Home Assistant",
"accessories": [],
"platforms": [
{
"platform": "HomeAssistant",
"name": "HomeAssistant",
"host": "https://172.17.0.1:8123",
"password": "",
"supported_types": [
"binary_sensor",
"climate",
"cover",
"device_tracker",
"light",
"scene",
"sensor",
"switch"
],
"logging": true,
"verify_ssl": false
}
]
}
config.json
{
"bridge": {
"name": "Homebridge",
"username": "B8:27:EB:2D:5B:29",
"port": 38953,
"pin": "123-45-678"
},
"accessories": [],
"platforms": [
{
"platform": "HomeAssistant",
"name": "HomeAssistant",
"host": "http://127.0.0.1:8123",
"password": "123456",
"supported_types": [
"binary_sensor",
"climate",
"cover",
"device_tracker",
"fan",
"input_boolean",
"light",
"lock",
"media_player",
"scene",
"sensor",
"switch"
],
"logging": true
},
{
"platform": "config",
"name": "Config",
"port": 8766,
"log": "",
"restart": "sudo systemctl restart homebridge.service"
}
]
}
logs
starting version 3.2.2
[ADD-ON] Installing Homebridge plugin homebridge-config-ui
yarn global v0.23.3
warning No license field
[1/4] Resolving packages...
warning homebridge-config-ui > read-last-lines > [email protected]: Use mz or fs-extra^3.0 with Promise
Support
[2/4] Fetching packages...
warning [email protected]: The engine "homebridge" appears to be invalid.
warning [email protected]: The engine "homebridge" appears to be invalid.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
warning "[email protected]" has no binaries
warning No license field
Done in 58.61s.
[ADD-ON] Ensuring old PID files are absent
[ADD-ON] Ensuring D-Bus unique ID exists
[ADD-ON] Starting D-Bus daemon
[ADD-ON] [DEBUG] Waiting until system bus socket is ready
[ADD-ON] Starting Avahi daemon
Found user 'avahi' (UID 86) and group 'avahi' (GID 86).
Successfully dropped root privileges.
avahi-daemon 0.6.32 starting up.
chroot.c: chroot() helper started
WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Successfully called chroot().
Successfully dropped remaining capabilities.
chroot.c: chroot() helper got command 02
Loading service file /services/sftp-ssh.service.
Loading service file /services/ssh.service.
*** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is
thus not recommended. ***
Joining mDNS multicast group on interface vethc66780d.IPv4 with address 169.254.189.235.
New relevant interface vethc66780d.IPv4 for mDNS.
Joining mDNS multicast group on interface veth4a689a1.IPv4 with address 169.254.62.60.
New relevant interface veth4a689a1.IPv4 for mDNS.
Joining mDNS multicast group on interface vethe08c27d.IPv4 with address 169.254.34.186.
New relevant interface vethe08c27d.IPv4 for mDNS.
Joining mDNS multicast group on interface vethbed8eb4.IPv4 with address 169.254.247.180.
New relevant interface vethbed8eb4.IPv4 for mDNS.
Joining mDNS multicast group on interface veth2841c71.IPv4 with address 169.254.111.103.
New relevant interface veth2841c71.IPv4 for mDNS.
Joining mDNS multicast group on interface veth07a5964.IPv4 with address 169.254.89.28.
New relevant interface veth07a5964.IPv4 for mDNS.
Joining mDNS multicast group on interface veth1c062f4.IPv4 with address 169.254.65.124.
New relevant interface veth1c062f4.IPv4 for mDNS.
Joining mDNS multicast group on interface docker0.IPv4 with address 169.254.85.176.
New relevant interface docker0.IPv4 for mDNS.
Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.188.
New relevant interface eth0.IPv4 for mDNS.
Network interface enumeration completed.
..........................
Host name conflict, retrying with hassio-8
Registering new address record for 169.254.189.235 on vethc66780d.IPv4.
Registering new address record for fe80::2caf:78ff:fe1d:8c7f on veth4a689a1.*.
Registering new address record for 169.254.62.60 on veth4a689a1.IPv4.
Registering new address record for fe80::c87c:5cff:fe7d:56ad on vethe08c27d.*.
Registering new address record for 169.254.34.186 on vethe08c27d.IPv4.
Registering new address record for fe80::4869:994f:4bf9:9fd7 on vethbed8eb4.*.
Registering new address record for 169.254.247.180 on vethbed8eb4.IPv4.
Registering new address record for fe80::28df:7907:ecd6:6727 on veth2841c71.*.
Registering new address record for 169.254.111.103 on veth2841c71.IPv4.
Registering new address record for fe80::80da:af5d:4893:8439 on veth07a5964.*.
Registering new address record for 169.254.89.28 on veth07a5964.IPv4.
Registering new address record for fe80::5c8d:50ff:fee9:d7ff on veth1c062f4.*.
Registering new address record for 169.254.65.124 on veth1c062f4.IPv4.
Registering new address record for fe80::a61a:18a7:f739:a3f6 on docker0.*.
Registering new address record for 169.254.85.176 on docker0.IPv4.
Registering new address record for 172.17.0.1 on docker0.IPv4.
Registering new address record for 192.168.1.188 on eth0.IPv4.
module.js:472
throw err;
^
Error: Cannot find module '../build/Release/dns_sd_bindings'
at Function.Module._resolveFilename (module.js:470:15)
at Function.Module._load (module.js:418:25)
at Module.require (module.js:498:17)
at require (internal/module.js:20:19)
at Object.<anonymous> (/usr/local/share/.config/yarn/global/node_modules/mdns/lib/dns_sd.js:32:22)
at Module._compile (module.js:571:32)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:488:32)
at tryModuleLoad (module.js:447:12)
at Function.Module._load (module.js:439:3)Ok so I updated to the latest version and now all my devices have been moved into the ‘default room’ within the iOS home app. I had previously configured each device into the correct room (via the home app). Should I be configuring the devices and their corresponding ‘room’ within homebridge or is this a bug of some sort?
That is all iOS/HomeKit and not Homebridge related.
Homebridge just offers the accessory to HomeKit. How your device categories or names them, is something you need to do on your device itself.
Thanks for the clarification, I assumed that it was nothing to do with homebridge. Can I expect the same to happen during each update of your plugin? I’m sure it didn’t happen with @olivierg plugin however but could be wrong.
No, it won’t happen during an update. If you add/connect Home Assistant to iOS, it will treat it as a “new” device. So that’s why everything is in your ‘default room’. An update should not cause you to re-connect with your iOS device.
But that’s exactly what happened, I updated your plugin and I then had to reorganise my devices within the home iOS app because they all appeared in ‘default home’.
To be clear:
You’ve updated from v1.0.0 to v1.0.1 and had to re-add the iOS connection?
Not exactly, I updated to 1.0.1 and all my devices moved into ‘default room’ I didn’t have to reconnect iOS to homebridge (HASSIO).
That behavior is typical. I’ve been using homebridge for a long time and every time i restart the my RPi the home app “forgets” the room and favorites configuration.
Related discussions are going on:
The last one has some kind of workaround solution regarding Home Assistant, needless to say, the solution offered is far from reliable or stable.
I will create an issue on my repository on GitHub to research the possibility of implementing this workaround in the add-on.