I have a number of iDevices devices. They work outstandingly within HomeKit, but I’d like to have access to them from Home Assistant.
Could someone who is using these provide some insight into how you’re using them?
When I try to pair them to the HomeKit Controller, they just pair to my Home.app, I don’t see a way to actually get them to pair to the HomeKit Controller
Once paired to the HomeKit Controller and published back to Home.app, can you actually upgrade the firmware? Does the iDevices app on your iOS device see them as valid iDevices switches?
Within HA do you have full access to the nightlights? Including color?
Just curious. For now I’ve left them paired to Home.app and I build virtual light templates published to Home.app with automations to bi-directionally allow the switching to work, but it’s a lot of work to maintain, and you cannot do dimming that I’ve been able to discover.
You need to unpair any HomeKit devices before Home Assistant can see them. Then you can add them using HomeKit Controller (see that page for the types of HomeKit devices that can be connected to Home Assistant). Then you can forward them back to HomeKit.
I don’t think you can upgrade the firmware when paired with HomeKit Controller, but someone else can probably verify that.
You should have full control of the lights in Home Assistant, but it might vary by device.
I realize I have to unpair the iDevices and then repair to the HK Controller. The issue is that as far as I can tell the only way to unpair them is to reset the switch. Then the switch isn’t on my WiFi and the only way to get it on the WiFi is to re-pair it to Home.app (or the iDevices app which is just a proxy).
That and the added issue of not being able to handle firmware updates means I’m keeping them in Home.app and building my own “bridge”.
Mike, I don’t believe it’s possible. All of the iDevices switches have to be paired to HomeKit in order to connect them to the wireless itself. That precludes you connecting them to HA. I’ve been successful in building virtual switches within HA that leverage Homebridge to actually control the switches, but I was never able to get past the “double tap” issue with this solution (when I turn the switch “on” in HA nothing happens, then I turn it off, then back on again and then it turns on. Same issue to turn it off). It’s too bad really, as they’re nice switches.
Hi @pickerin. I have good news for you. I think I know how to resolve the “double tap” issue. I think the issue is that HomeKit gets confused with the current state of the HA device. I created the four bi-directional automations in HomeKit, but I had to add conditions to each that will only turn the switch on IF it is off, and only turn it off IF it is on. You can’t do that directly within the Home app, unfortunately. I have an app called Home+ that exposes more HomeKit functions than the native Home app. Adding those conditions seems to do the trick for me.
Having said all of that, I sure wish HA could natively talk to iDevices and Koogeek devices. It would make life a lot easier!
@pickerin The Home+ app is great. I think it costs about $10, but it really expands HomeKit functionality quite a bit.
Here is an example from the Home+ app:
When the “Night Lights Switch” (which is the HA input_boolean) turns on, it performs the action of turning on two night lights (which are the LED lights in the center of the iDevices outlets).
But this only happens under the condition that either of them are on.
I’m not sure why this fixes the issue, but it does seem to work for me. Let me know how it goes for you.
Mike, thanks for the additional info, I did purchase Home+ to take a look.
Doing so may have identified the problem I was having as Home+ shows several duplicated automations (all with a “2” at the end) that are not visible in my Home app.
I’m going to clean things up within Home+ and hopefully that’ll fix my odd behaviors.
The process I followed to get my iDevices Switch into HomeKit and Home Assistant is as follows…
Pair iDevices Switch with HomeKit as intended in order to connect it to WiFi and the HomeKit DB.
Once iDevices Switch is available within HomeKit
a. Open the Device
b. Open Settings
c. Scroll past the device information, to the bottom.
d. Click Remove Accessory (See attached image.)
e. Wait until process completes.
- Will take longer than you might expect. Be patient. Think minutes, not seconds nor milliseconds.
f. The iDevices switch is now on Wifi, but no longer within HomeKit.
Initiate a discovery scan for new devices within Home Assistant. (I simply restarted.)
Once discovery is complete, you should be told that a new device is available.
Import the device into Home Assistant’s HomeKit Controller integration with the same HomeKit ID that you used in step 1.
Advertise the iDevices Switch device to HomeKit using Home Assistant’s HomeKit integration.
The iDevice Switch should now available via the Home Assistant Bridge
Hi @homekitter - I actually just recently moved several iDevices switches from HomeKit to HA. Strangely, they work at first but after a day or so of use I am noticing that they are losing their connection to HA very often. They come back up when I unplug them and plug them back in, but this is less than ideal. This doesn’t happen with other HomeKit devices that loaded into HA using homekit_controller. Have you had the same issues?
My dimmers, switches and outlets all work fine and have no dropouts paired with HA. I hesitated pairing them with HA since the controller doesn’t support power monitoring.
Is it possible to connect iDevices without connecting to HomeKit? (I don’t have iPhone)
I have iDevices outdoor switch which is working perfectly fine with native app, and I can see it on the network and its IP address. Is there any way I can connect to it? (just starting with Home Assistant, this is my first device)
Using the native application will work (it’s basically just HomeKit). You can instead enable the HomeKit Controller integration and then pair the switch to the controller running in HA.
The main point I wanted to drop in here (as it catches a lot of peole out) - for most devices there is no need to have an iOS device to use homekit_controller. HomeKit controller is an emulation of an IOS device and connects to the device directly (no cloud, no apple id, no nothing) over your local network.
There are only 2 cases where an iOS device is needed:
Theres a WiFi credentials sharing feature for some devices where you need to pair with an iOS device once to get it onto the network. You then unpair from your iPhone and the accessory stays on your network and HA can pair instead. This is a one time step, and the iPhone is not needed after this so its OK to borrow one.
Theres a WiFi to BLE range extender called Eve Extend that has a proprietary scheme for managing child pairings. Right now the device itself works with Home Assistant but you need an iOS device to configure the bridge in the first place. Again, iPhone not needed after initial setup.
I don’t think either of these cases apply to iDevices that already have an IP.
Another thing to mention is that there are 2 HomeKit integrations in Home Assistant. For talking to iDevices you use homekit_controller. This is the one that emulates an iPhone. The other is just ‘homekit’, and its the opposite. It emulates an accessory so that an iPhone can talk to it. Again both of these are using local (cloud free and apple free) encrypted connections.
@Jc2k Thanks for the clarification, it’s good to keep this straight as a lot of new users don’t realize there are two distinct HomeKit integrations, each for a different component. Unfortunately, I’ve given up on getting an iDevice to pair. I’ve tried multiples and they will not work.
@pickerin turns out the maintainer of the other homekit integration has iDevices and while pairing did kind of work for him he has sorted out a bunch of issues, so worth trying again on 0.115.0 when its out.
First of all a lot of devices have broken zeroconf, and the zeroconf library we are using is strict (i’d argue too strict) and it meant that valid devices were being ignored when these bad devices were on the network.
There were also some bugs about how pairing retries worked. It did not recover from a “busy error” properly, for example, and could get wedged in a mid pairing state. This wasn’t detected before because a bunch of iDevice users hit the “happy path” where something was just not quite slow/fast enough to catch the busy error. During review i spotted (and he fixed) some other edge cases that only impacted devices with screens.
Also another user replied that IGMP snooping on some switch hardware can interfere with mDNS and stop devices being discoverable. I’m going to add a note to the docs about that.
Also I think he submitted this for an iDevice switch:
