[App][Pro] HomeyKit

Apps
, , ,
1

HomeyKit

With this app you can pair Homey to HomeKit and control your Homey devices using iOS, Siri and Shortcuts.

IMPORTANT: this app is deprecated

With the release of the new HomeKitty app, this app will not be developed any further, apart from an SDKv3 release before the release of the new Homey Pro.

You can keep on using HomeyKit for as long as you like, but it won’t be actively maintained anymore. You can run HomeyKit and HomeKitty on your Homey without getting in the way of each other (as long as your Homey has enough resources), so you can run HomeKitty on a “test home” to see if it works for you. It already supports more devices than HomeyKit, has some additional features, and hopefully it’s just altogether a better experience. Plus, it’s ready for the upcoming new Homey Pro.

HomeyKit support for the new 2023 Homey Pro

From version v5.1.0, currently in test, HomeyKit has preliminary HP2023 support.

However, I would urge all HomeyKit users to consider migrating to HomeKitty, as mentioned above.

Note on Home changes in iOS 16.2

With the current iOS 16.2 beta, Apple has introduced a new Home architecture (including support for Matter/Thread).

Upgrading to this architecture is optional. Given that the current beta is giving issues with HomeBridge and HomeyKit (at least for some people), my advice is to wait to upgrade.

For those that have upgraded already and are experiencing issues with HomeyKit (devices being unresponsive), the current test version (v4.3.0) should fix those issues. Be aware that test versions of apps can be subject to frequent changes and updates, and as a result, it may be required to do a full Home(y)Kit reset.

Usage Instructions

After installing the app grab your iPhone or iPad, open the Home app on your iOS device and then:

  • Click the + at the top of the screen and choose Add New Home (name it anything you like)
  • Once the new home is created, choose Add Accessory > More options…
  • (If your Homey isn’t already visible in the list of accessories, try My Accessory Isn’t Shown Here)
  • Pick Homey (because HomeyKit isn’t officially certified by Apple, you’ll get a question about adding an uncertified accessory)
  • Enter the code: 20020200 and Continue.

After Homey has paired with your iOS device your Homey devices will be added. When you add or remove a device from Homey the same wil happen in HomeKit. In the application settings for HomeyKit you can select which devices you want to pass (and not pass) to HomeyKit. By default, all supported devices will be passed.

The following classes are supported:

  • Lights (with RGB or Temperature)
  • Sockets
  • Switches
  • Motionsensors (with lux and temp)
  • Locks
  • Door/Window sensors (with temp)
  • Thermostats
  • Window coverings (blinds, curtains, sunshades)
  • Buttons
  • Fans/heaters
  • Most on/off devices
  • Home Alarm
  • Most sensors

Donations

Donations are very welcome, though they come with no guarantees, warranties, or preferential treatment (just think of it that you’re donating for the work already done, not the work to be done).

For now, Paypal only: PayPal.Me

Issues

A lot of issues with HomeyKit are not related to the app but have external causes, like Homey’s networking being unstable (especially after a firmware update). Typically, when you have issues with any app, the first recourse is to PTP.

If your problems with HomeyKit are persistent, you can perform a full reset from the App Settings.

If you are sure you found an actual bug with the app you can create an issue on Github .

Changelog

5.0.0

  • SDKv3 support and slimmed down the app considerably.

4.1.10

  • Added link to community forum page

4.1.9

  • Support for “remote” devices with onoff capabilities and fixed issues with “locked” subcapabilities.

4.1.8

  • Make sure all devices are ready before being added to the bridge.

4.1.7

  • Catching more Web API error.

4.1.6

  • More small fixes

4.1.5

  • Work around yet more issues with the Web API

4.1.4

  • Catch errors when starting the bridge

4.1.3

  • Limit the number of bridged accessories

4.1.2

  • Work around more issues in the Web API

4.1.1

  • More fixes to work around issues in v7.4.X-rc.Y

4.1.0

  • Changes for Homey v7.4.0-rc.X

4.0.1

  • Added support for state blinds/curtains/sunshades

4.0.0

  • New stable release

3.0.13

  • Added support for curtains and generic window coverings

3.0.12

  • Added support for blinds (#180 and hopefully #159)

3.0.11

  • Stability changes (hopefully fixes #137)
  • Allow user to set different bridge identifier (#151)
  • Added support for curtains (#153)

3.0.10

  • Fixes #149 (issue with CO2 and CO sensors)
  • Removing explicit subscription for device update events (not required anymore)

3.0.9

  • Some fixes for Satel Integra support

3.0.8

  • Swapped button/homealarm_system detection to work better with Heimdall

3.0.7

  • Support for device class speaker
  • Fixed issue with settings
  • Configurable settle time
  • Support onoff for device class homealarm
  • Support onoff and dim for device class sensor
  • Removed log tab from settings page (wasn’t being used anyway)

3.0.6

  • Wait longer after a reboot for devices to settle to prevent iOS from not recognizing devices anymore

3.0.5

  • Prevent non-existent capabilities from being accessed/used
  • Cleanups
  • Debouncing dim so it doesn’t glitch as much

3.0.4

  • Better check on required capabilities for devices to prevent crashes

3.0.3

  • Also check device.virtualClass during device discovery.

3.0.2

  • Fix to prevent issues due to Athom’s implementation hijacking our TCP port

3.0.1

  • Fixed an issue with the settings page not being shown

3.0.0

  • Homey v2 firmware support
  • Changes to settings pages
  • Option to clear persistent storage to resolve issues with Homey not being found by iOS

2.1.3

  • Delay start of Homekit server until device count has settled (#93)

2.1.2

  • Trying to fix #82

2.1.0

  • Reintroduced settings page
  • Other small fixes

2.0.12

  • Filename uppercase fix

2.0.11

  • Updated hap-nodejs, lodash and athom-api
  • Added alarm system support for Heimdall
  • Added fan support

2.0.10

  • Fix for sensors

2.0.9

  • Bugfixes in smoke and temperature class

2.0.8

2.0.7

  • Fixed color bulbs
  • Fixed thermostat

2.0.6

  • Small fixes

2.0.5

  • Small fixes
  • Thermostat display units added

2.0.5

  • Fixed contact sensor

2.0.4

  • Beta appstore release

2.0.0

  • Initial release where has-node got replaced by hap-nodejs
6 Likes
2

I don’t use the Homeykit app, but completely understand your position in regard to the mandatory upgrade in relation to the fact that it would only cost you money instead of earning some. Athom should really reconsider their approach towards high quality community developers.

4 Likes
3

You have done fantastic work with the apps you have built. I hope the community sees fit to donate enough for you to continue support and development. I have donated a little. Wish it could be more.

1 Like
4

no offense, good work with a app being useful for a long time, but this app will make no sense when the matter support comes out, so if i were you i would not use more time on it

5

You’re assuming that Athom will release Matter support for the current Homey Pro as well, which I very much doubt. Also, we’ll have to wait and see what “Q2 2023” means in terms of Matter/Thread support for the new Homey Pro; June 30th is still “Q2 2023”, and some people may want to keep controlling their Homey devices over HomeKit until then.

2 Likes
6

ah, i didnt realize that the sdk 3.0 requirements was for the old pro’s aswell. sorry

7

All SDK2 apps will be removed from the app store from Jan 1st, which (I assume) also means that it’s not possible to provide app updates from that date. Running installs will keep on running.

8

I came to this community forum in search of the difference between this HomeyKit app and the “Apple HomeKit” under Settings–>Experiments. I’m currently using “the built in one” without knowing what I’m missing out on? I also remember Athom mentioning “Apple support” during the Keynote, but still this app soon generates €400. Not trying to be rude or anything here, I’m just dead curious about the differences? :innocent:

1 Like
9

I’ve never used the built-in experiment (HomeyKit existed before it), but from what I know, the main differences are that HomeyKit supports more devices and it allows you to select which Homey devices should (and shouldn’t) be made available through HomeKit.

10

Ah, OK. I just delete the ones I don’t want inside Apples Home app. Not sure how to bring them back though :sweat_smile:

I found this app by looking at the comments on this tutorial. I see your name in the comments there as well. This specific comment made me think your HomeyKit made it possible to pass a value decided on runtime to Homey through Siri. Without adding a virtual device. But either this user don’t care about passing values, or I’m unaware of functionality in both your app and/or the experimental HomeKit support in Homey?

The app in the tutorial works for this though, but probably won’t make it to Pro 2023 unless updated. Hence the interest to swap app. Hell I’ll chip in on the last €20 if this appears in the SDK 3.0-version :sweat_smile:

11

It’s not possible to pass random values to Homey through HomeKit using Siri (that’s just not in the protocol).

That’s also not what the tutorial tries to achieve: the OP wanted a way of starting flows from Siri by using a shortcut and a phrase assigned to that shortcut.

With HomeyKit, you can control your Homey devices through Siri (“Hey Siri, turn off the kitchen lights”) but that only works because iOS knows which HomeKit devices are kitchen lights, and it tells HomeyKit to turn off those specific lights.

12

Request for Comments

In light of the SDKv3 rewrite of HomeyKit I’ve come to the conclusion that it would be best to do a full rewrite of the HomeyKit app, not just to support SDKv3 but also to do a complete reimplementation of how the app “translates” Homey devices to HomeKit.

Right now, the app is a large lump of spaghetti code with lots of code duplication, which makes maintenance difficult and adding new device support a challenge (I have already figured out a much more flexible way of implementing device support and ran some tests with it, and I’m happy with how much easier and better it works than the current implementation).

Sounds great, so what’s the problem?

The problem is that such a rewrite of the current app would sadly be backward-incompatible with the current version, and thus invalidate all HomeKit configurations for all current HomeyKit users (there are about 9.5K installs of the app right now).

Oh, doesn’t sound so great after all :thinking:

No, it doesn’t, and I don’t want to do that.

So what’s the plan?

My plan is do publish the rewrite as a completely new app (see below for caveats). This way, all current users can make an informed decision about if, and when, they want to move to the new app.

The necessity for a new app also stems from the way the App Store currently works: once a developer publishes a stable version of an app, no matter how big the changes, it will be installed automatically for almost all users (unless they have automatic app updates disabled, which about 99% of users will not).

What’s stopping you?

One big question that remains to be answered is if Athom will allow another HomeKit app in the store. I’ve already asked on Slack about it, so we’ll see. If I don’t get a definitive answer, I will try and see.

Athom suggested that I could do a final update for HomeyKit which would explain to existing users that the app is EOL (but see the following point) and there’s a new app. Then HomeyKit will be hidden on the App Store to prevent new installs.

And what about the SDKv3 rewrite for the current HomeyKit?

My intention is to rewrite the current app to SDKv3, so existing users will not be left in the cold once Athom turns off SDKv2 app support in the App Store at the beginning of 2023. But I will not keep on maintaining HomeyKit separately from a new app, and will focus my efforts on the latter. So new device support will only be implemented in the new app.

My goal is to have a new app ready (again, if Athom will allow it) before the new Homey Pro 2023 model is shipped.

So what are you requesting comments for?

I’m interested in hearing what you as users think of these plans. Please limit your comments to broader issues and not “Will you implement support for X in a new app?” (for the initial release of the new app, I will focus on implementing the exact same device support as the existing app).

I’m also open for suggestions for a new app name. For now, the working title is “HomeKitty” :smile_cat:

7 Likes
13

Totally agree! :+1:t3:

1 Like
14

HomeKitty it is! :joy:

This seems like a great step forward

1 Like
15

That sounds like a very good plan! :cat2:

1 Like
16

Awesome, I appreciate it!

Name suggestions are: HomKit, HomeyBridge

1 Like
17

Btw… @robertklep could you tell me what alarm device capability is checked by HomeyKit and exposed as “Alarm”?

I want to have my Security System hacked under Homey. I’ve created an “Advanced Virtual Device”, using MQTT I can set Armed Mode, Away and Home modes.

When a Security device is alarming in HomeKit, iOS lets a “Critical Notification” pass event silent or sleeping settings and can warn the user that something is going on. This is what I want to achieve by the above mentioned virtual device.

18

Either a device (virtual) class of “homealarm” and/or when the device has the “homealarm_state” capability.

19

Sorry, I mean “Alarming”

20

Ah sorry, I misread.

The homealarm_state capability (and HomeyKit) supports the following values: “armed”, “disarmed” and “partially_armed”. And it uses either “alarm_heimdall”, “alarm_tamper” or “onoff” capabilities to signal an alarming state (I guess that for the new app it makes sense to also implement support for “alarm_generic”, “alarm_contact” and “alarm_motion”).

1 Like