[App][Pro] HomeyKit

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.

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

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.

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:

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.

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:


Totally agree! :+1:t3:

1 Like

HomeKitty it is! :joy:

This seems like a great step forward

1 Like

That sounds like a very good plan! :cat2:

1 Like

Awesome, I appreciate it!

Name suggestions are: HomKit, HomeyBridge

1 Like

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.

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

Sorry, I mean “Alarming”

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

you realize that this will be solved when matter support is released? The app will be useless then :frowning: Appreciate your work on this, but you will have much work for nothing

Is it though… will our non-HomeKit supported devices be made Matter compatible through homey and presented to HomeKit? Please help me understand

Please go away.

What kind of reply is this?? It’s unheard. I’m trying to save you from a lot of work. Please explain your reply and stop being rude!

Yes, athom have said that homey will expose all devices to other matter controllers :slight_smile:

Because you keep repeating yourself, and I find your post to be rude.