HomeKitty (AKA HomeyKit 3.0) HomeKitty is an almost complete rewrite of HomeyKit and serves the same purpose: expose your Homey devices to HomeKit so you can control them using iOS, Siri and Shortcuts. Current version Stable: v2.4.4 Test: v2.5.8 You should be able to run it next to HomeyKit without getting in the way. See follow-up post for installation instructions. Please be aware: I don’t use Homey or HomeKitty myself, so I can only test with a very limited amount of (virtual) devices, and am reliant on community users to test it fully with their apps. COMMON ISSUES Please read this before creating a diagnostics report or posting an issue report on Github! It’s very common for iOS to have issues that are not related to HomeKitty, and can therefore not fixed by me. “No Response” Sometimes this is iOS just lying to you. I see this issue all the time, and changing the device on iOS usually works just fine. It typically can take some time after starting Homey and/or HomeKitty before iOS will show the proper state of devices. This is also one of the reasons why Apple has tried (and failed) to introduce a new HomeKit architecture, because the current architecture can be very unstable. Another reason for this can be misbehaving Home hubs, like an Apple TV or HomePod. If you have any of these devices, reboot them or toggle the switch where they are allowed to act as Home Hub. Also, make sure that your Homey has a fixed IP-address. Because this can’t be configured in Homey itself, it has to be configured in your internet router. Look for “DHCP” or “DHCP leases”. App crashes This doesn’t happen very often (I get notified when it happens, and it doesn’t happen a lot), but the most common reason is when you have two Homey’s in the same network and both are using the same HomeKit identifier. An identifier has to be unique in the network, so when this happens, change the identifier from the app settings (after first turning off HomeKitty on the other Homey). Do be aware that changing the identifier is basically a reset, so you will have to start over with the HomeKit configuration for the new Homey. iOS losing devices or places them back in the Default Room After Homey reboots/restarts, HomeKitty will try to wait for all devices of all your apps to be created before it starts communicating with iOS. However, if apps take a really long time before creating their devices, HomeKitty might “miss” these devices and they are added to HomeKit after communication with iOS has already started. Such devices are considered to be “new” by iOS (a major flaw in the HomeKit protocol) and will be placed in the default room. To make HomeKitty wait longer, starting with v2.2.0, there’s a configuration option to delay the start of HomeKitty by a fixed amount of time. If you have this issue, it’s recommended to set this option to about 10 or 15 minutes, just to make sure that all devices have been created before HomeKitty starts. Unable to add HomeKitty to iOS Make sure that both Homey and your iDevice(s) are on the same network segment (in other words: if your Homey is part of a separate VLAN/IoT/guest network, there’s a good chance it won’t be found). Still having issues? You can file an issue report here: Issues · robertklep/name.klep.homekitty · GitHub Changelog v2.5.8 — Support thermostats with operational_state capability v2.5.7 — Support for occupancy sensors v2.5.6 — Support for onoff sprinklers v2.5.5 — Fixed issue with Adaptive Lighting discovery v2.5.4 — Revert changes to home alarm map v2.5.3 — Fixed crash issue with thermostat devices v2.5.2 — Support thermostat devices with “onoff” capability v2.5.1 — Removed Night mode from home alarm, since Homey doesn’t have an equivalent v2.5.0 — Support for fan_speed capability v2.4.4 — Fixed issue with “heater” map v2.4.3 — Increased “settle time after reboot” to 30 minutes v2.4.2 — Added support for “airconditioning” devices v2.4.1 — Fixed issue with lights becoming dimmable when they weren’t v2.4.0 — Adaptive Lighting support v2.3.5 — Hopefully fix issues with thermostat temperature units v2.3.4 — Set Homekit target temperature limits to match Homey’s v2.3.3 — Also allow “other” device class to be considered for window coverings v2.3.2 — Fixed issue with temperature units for thermostats v2.3.1 — Tilt support for window coverings v2.3.0 — Don’t expose hidden/maintenance capabilities to iOS v2.2.18 — Work around button.remove_node capabilities that get added to Matter devices :man_facepalming:t3: v2.2.17 — Bugfix for v2.2.16 v2.2.16 — Added support for heatpump device class v2.2.13 — Correctly set temperature display units for thermostat and heatercooler v2.2.12 — Allow outlets/sockets to be dimmable v2.2.11 — Fixed issue with tv’s being mapped twice v2.2.10 — Added (partial) support for televisions v2.2.9 — Fixed issue with Bold locks using onoff the wrong way around v2.2.8 — Added support for onoff locks (Bold) v2.2.7 — Fixed issue with v2.2.6 v2.2.6 — (unreleased) fix low battery status v2.2.5 — Use alarm_battery for low battery status v2.2.4 — Added optional tamper state for other types of sensors v2.2.3 — Added optional tamper state for water leak sensors v2.2.2 — Added support for battery levels (sensor and other) and updated homey-api to latest version v2.2.1 — Added support for devices of class sensor and capability button (e.g. Heimdall Alarm switch) v2.2.0 — Added option to delay start of HomeKit bridge after Homey reboot v2.1.0 — Fixed issue introduced by rc88 firmware v2.0.1 — Home alarm state fixes v2.0.0 — Compatibility with HP2023 and homey-api@3 v1.4.2 — Upgraded to latest homey-api v1.4.1 — Sort device list v1.4.0 — Debounce changes to dim/brightness for light devices v1.3.2 — Bugfix v1.3.1 — Support onoff capability for sensor devices v1.3.0 — This version should handle app crashes/restarts much better: devices belonging to such apps should retain their room assignments, automations, etc, once the app is back up again. v1.2.10 — Work around issue in Web API related to (un)exposing devices to HomeKit v1.2.9 — Hopefully fixed issues with state-only window coverings implementation v1.2.8 — Updated to latest version of homey-api and allow contact sensors with “other” device class v1.2.7 — Support for Eufy doorbell devices v1.2.6 — Fixed issue with virtual devices losing their configuration v1.2.5 — Fixed more issues with positionless window coverings v1.2.1 — Fixed issue with positionless window coverings v1.2.0 — Rewritten/restyled app settings, bugfixes, additional device support v1.1.0 — Rewritten mapping logic and streamlined app settings page some more v1.0.5 — Improved app settings v1.0.4 — Bugfixes v1.0.3 — Bugfixes v1.0.2 — Bugfixes, more device support, and Flow Starter device v1.0.1 — Bugfixes v1.0.0 — Initial (test) release Further plans In no particular order: Reach a stable version Implement various virtual devices: a Virtual Switch device to trigger HomeKit automations from Homey a Virtual Service, basically a virtual device. See below for more info. More/better device support. Flow Starterᵇᵉᵗᵃ device (since v1.0.2) The Flow Starter device can be used to create a HomeKit button to trigger flows. It’s a regular Homey “button” device with the “Button Pressed” action card. By renaming the device in HomeKit (you can rename it on Homey too, but that will not change its name in HomeKit) you can get Siri to trigger on any name you like. Because of limitations in HomeKit, this device actually appears as a switch (on/off) which, when turned on, will turn itself off after 300ms. This is still an experimental feature, so it might be subject to change. Virtual Service device (unreleased) HomeKit supports a long list of Services (somewhat equivalant to Homey device classes). These services have required (and possibly optional) Characteristics (somewhat equivalent to Homey device capabilities). With a Virtual Service device you can create a HomeKit device based on a service, and set the characteristics of that service from Homey flows. Basically the same as the Virtual Devices app for Homey, but for HomeKit. Why a rewrite? HomeyKit is now 5 years old. During that time, it has had various “main developers”, the last one being myself (@robertklep). It’s a relatively complex app because it has to deal as good as it can with incompatibilities between Homey devices and HomeKit devices. This complexity means there’s a lot of unstructured “special case handling” in the code, which makes it difficult to maintain. For the upgrade of HomeyKit to SDKv3 I initially planned to also do a cleanup of the code, but ran into issues with outdated external dependencies. Updating these dependencies meant an upgrade would be backward incompatible, breaking the HomeKit setup for all HomeyKit users once they upgraded to the new version. So I decided it was best to do a complete rewrite and release it as a separate app, HomeKitty. This also means that HomeyKit will, as of now, drop into maintenance mode, meaning that I will probably do one or two new releases (including an upgrade to SDKv3) but no more. Once HomeKitty is published as a stable v1.0.0 in the app store, I will ask Athom to hide HomeyKit from the store (meaning that new users will not be able to find it in the store anymore). Donations Donations are very welcome! You can make donations through Paypal.

Problem with dimming lights opened 02:17PM - 23 Jan 23 UTC (UTC) [itzbolsi] itzbolsi Hi, having some problems with dimming lights on the new app, worked fine with th…e old one. Sometimes the first try/tries works fine but not always. After dimming once, it usually fails on the next try, jumps back to last dimming level without the lights changing. After this it dosent respond to new inputs. (When dimming directly on homey everything works fine.) Also, old Homeykit app is uninstalled and the integrated homey one is disabled so shouldent be any conflicts there. ### Type (brand/model) of device Heatit Z-Dim (Heatit controls app) ### Is it supported by HomeyKit? Yes, worked fine on Homeykit, but problems with Homeykitty. ### Device Classes zw_device_class_basic "BASIC_TYPE_ROUTING_SLAVE" zw_device_class_generic "GENERIC_TYPE_SWITCH_MULTILEVEL" zw_device_class_specific "SPECIFIC_TYPE_POWER_SWITCH_MULTILEVEL" ### Device Capabilities (see above for where you can find these; please post ID, title and type) ID 850de1fa-c3e7-4d17-bb4d-f0256bc31275 Name Lys stue Class light

Hi, [EDIT] Problem solved after several resets of HomeyKitty [EDIT] I get the following error when i try to add HomeyKitty to Homekit. [IMG_5996] When i create a fresh new house i get it aswel. Running ios 16.4 with updated Homekit intergration, Homey early 2018 Anyone has an idea what to do? tried to reboot Homey and Phone. [EDIT] Problem solved after several resets of HomeyKitty [EDIT]

Hello, I am looking for a possibility to integrate a Homekit device (thermostat) that have no app in the Homey App Store. I don’t think this is possible with Homekitty right now, but are there plans for this? If anyone has a suggestion to realize this, I’d love to hear it :slightly_smiling_face: So I’m looking for a way the other way around!

[image] Steven_Bareman: but are there plans for this? No, sorry.

@robertklep, Any way you could integrate homekit’s geolocation in the app (ie read home/away per user) and use it as “when” trigger? I guess it’ll be tough as right now it’s more of a “push” model rather than pull data from Homekit but it’d be a great feature

[image] Hannes85: integrate homekit’s geolocation in the app (ie read home/away per user) and use it as “when” trigger Here is one way to do it: [image] Using HomeKitty and Apple Homekit for people presense Tutorials One way to utilize presence from Apple devices is with virtual devices in Homey and publish them to Apple Home with HomeKitty. Instructions how to prepare HomeKitty. Enable the Virtual Devices experiment from Homey settings. Create a virtual device with On/Off capability for each person: [Screenshot 2023-04-07 at 9.12.19] Use HomeKitty to publish the devices to your Apple Home: [Screenshot 2023-04-07 at 9.19.13] Now in Apple Home, prepare some home and away automations to switch…

Thanks, that is how I have it now but if there’s a way to just use the geofence triggers directly it saves the extra steps

Geofencing is something that happens on the phone itself, HomeKitty is unaware of your location. So you’ll need an automation. Instead of a virtual device you can also use HomeKitty’s “Flow Starter” device.

Thanks Robert, appreciate your response. I was afraid it would be impossible to directly act on these triggers. Tried the flow starter device and it’s nice but a button (needs to be a switch for it to work properly). Maybe add the possibility to either create a button or switch? Although in the end it won’t really change the mechanics needed, except for potentially removing the need for the Virtual Device app… if you don’t use the more complex devices such as curtains (sliders etc)

Ah yes, a switch makes more sense. The Flow Starter device has a specific reason for existing (just using a regular virtual button causes problems with flows triggering multiple times) but for a switch a virtual device is just as easy to use. I don’t have plans to add a virtual switch to HomeKitty in the foreseeable future.

[App][Pro] HomeKitty 😸 (aka HomeyKit 3.0)

Apps

OH2TH April 7, 2023, 6:27am 81

Here is one way to do it:

Topic		Replies	Views
HomeyKit Apps	218	12855	April 18, 2022
[App][Pro] HomeyKit Apps app , tools , devices , homey-pro	56	4980	April 21, 2024
[Discontinued] HomeKit Controller Apps	121	9838	January 15, 2024
[APP][Pro] HomeKit Device Bridge Apps app , homey-pro	119	2217	October 31, 2026
[APP][Pro] HomeKit Controller - for a better Homey Apps app , homey-pro	605	28647	November 4, 2026

[App][Pro] HomeKitty 😸 (aka HomeyKit 3.0)

Related topics