Homey integration for Home Assistant - Now Available! 🎉

[ifMike]

A new dev version has been released. If anyone wants to test, please do!

@Peter_Kawa

Just FYI, v1.2.0-dev1: it still shows discovered Homeys, details:

@Steffen_Schmitt

Edit: The not existing „second Homey“ is still found.

[Steffen_Schmitt]

Hi Mike,

dev3 installed:

• no second Homey Pro entry
• all sensors active

[ifMike]

A new release is out! I kind of had to rush this since a lot of sensors stopped working (and it was my dumb mistake). I also added some new features like better descriptions during setup, better error messages and discovery improvements.

v1.2.1

Critical

Sensor unavailability fix: A registry filter was incorrectly skipping existing sensors, causing them to become orphaned and show Unavailable. Controls (lights, switches, etc.) worked, but sensors did not. This is a critical fix for all users who rely on sensor data—temperature, humidity, presence, distance, and similar capabilities.

Added

• Discovery card identification: Shows IPv4 on discovered cards (e.g. “Homey (192.168.1.32)”) so multiple Homeys can be distinguished. Falls back to “Homey (IP unknown)” when IPv4 cannot be resolved.
• Setup step descriptions: Step descriptions explain what to do, required permissions (Devices, Flows, System read), and Pro 2023+ limitation.
• Translations: Added translations/en.json for config flow to display step descriptions correctly.

Changed

• Discovery host field: Never show .local hostname or IPv6 in the host field. Resolve to IPv4 when possible; use empty when resolution fails. Default manual host changed from homey.local to empty.
• Error messages: Full error messages for invalid_auth and cannot_connect with causes and solutions, including Pro 2019 not supported. Passed directly since translation keys may not resolve in custom components.

Fixed

• Sensor unavailability: Removed registry filter that skipped existing sensors, causing them to become orphaned and show Unavailable (controls worked, sensors did not).
• Discovery suppression: Suppress discovery when an existing config entry points to the same host. Fixes “Discovered” Homey showing when manually configured (manual uses homeyId, discovery uses MAC/hostname).
• IPv6 discovery suppression: When discovered host is IPv6, resolve hostname to IPv4 and compare with existing entries so discovery is correctly suppressed for already-configured hosts.
• Discovery card fallback: When title_placeholders was empty, the card showed “homey” (domain). Now always shows “Homey (IP)” or “Homey (IP unknown)”.

If you encounter any errors or bugs, please report them (preferably on GitHub) or just let me know here!

All the best,
Mike

[Steffen_Schmitt]

Hi Mike,

Thx for your work. Sensor are working fine but now I have a „new“ Homey pro again. The integration of the sensors works fine so its ok for me.

[ifMike]

Glad to hear it!

I’m working on a fix for this. I’ve already added it to my dev branch if you want to test (available in my HACS repo)

Release dev-1.2 · ifMike/homeyHASS

[Peter_Kawa]

Hi Mike,

The 2019 models are still on the ‘discovered’ devices list, but it’s no biggie of course. We can put it on the ignore list in the devices screen, which makes them disappear in the integration screen as well

I understand it’s hard to determine the model in the discovery stage.

[ifMike]

Yeah, I think I need to add a logger in my dev build and have you (or someone) try it. Then see what kind of differentiation we have between different models so that I can suppress them in the discovery.

The problem is that before we actually authenticate with our token, we don’t get the full picture.

I’ll let you know when I have something

EDIT:

It was a minor update to dev. So there is a new dev-1.3.

Once it’s installed, reboot and search for [discovery] in the logs.
There should be a “model” field e.g.

'model': 'homey5q', 'version': '13.0.0'}

So I need to know the model for 2019. I’m expecting it to be “homey2”, “homey2s”, “homey4d” or similar.

If someone wants to give me a legacy model ID that don’t have the local API then I can add that to the “Unsupported models” list and we won’t have that problem

[smarthomesven]

@ifMike

So I need to know the model for 2019. I’m expecting it to be “homey2”, “homey2s”, “homey4d” or similar

My Homey 2019 has model number homey3d if that helps.

Also, this is what I found while reverse engineering Homey SHS:

export const MODELS = {
  desktop: 'Desktop',
  homey1s: 'Homey (Early 2016)',
  homey1d: 'Super Homey (Early 2016)',
  homey1q: 'Super Homey (Early 2016)',
  homey2s: 'Homey (Early 2018)',
  homey2d: 'Super Homey (Early 2018)',
  homey2q: 'Super Homey (Early 2018)',
  homey3s: 'Homey (Early 2019)',
  homey3d: 'Homey Pro (Early 2019)',
  homey4d: 'Homey Pro (Early 2019)',
  homey5q: 'Homey Pro (Early 2023)',
  homey6q: 'Homey Pro mini',
  homey7q: 'Homey Pro (2026)',
  cloud: 'Homey Cloud',
  shs: 'Homey Self-Hosted Server',
} as const;

[Peter_Kawa]

Hi Mike,

I know my Homey 2019 modelIds are homey3d and homey4d.

Unfortunately it’s not in the v1.2.1-dev.3 debug log.

I’ll DM you the complete log entry which comes closest to discover specific info (too much data to anonimise).

[ifMike]

Thank you both! This is probably what I needed!

@smarthomesven

export const MODELS = {
  desktop: 'Desktop',
  homey1s: 'Homey (Early 2016)',
  homey1d: 'Super Homey (Early 2016)',
  homey1q: 'Super Homey (Early 2016)',
  homey2s: 'Homey (Early 2018)',
  homey2d: 'Super Homey (Early 2018)',
  homey2q: 'Super Homey (Early 2018)',
  homey3s: 'Homey (Early 2019)',
  homey3d: 'Homey Pro (Early 2019)',
  homey4d: 'Homey Pro (Early 2019)',
  homey5q: 'Homey Pro (Early 2023)',
  homey6q: 'Homey Pro mini',
  homey7q: 'Homey Pro (2026)',
  cloud: 'Homey Cloud',
  shs: 'Homey Self-Hosted Server',
} as const;

@Peter_Kawa

I know my Homey 2019 modelIds are homey3d and homey4d.

I’ve added a filtering so Homey 2019 and older no longer show up in discovery.

From the mDNS logs I see that Pro 2023 sends model: 'homey5q' in the discovery properties, while 2019 and older apparently don’t send a model at all sometimes. So I now:

1. Ignore devices without model - older firmware doesn’t broadcast it, so we treat them as unsupported.
2. Ignore known unsupported models - e.g. homey3d, homey4d, homey2s, etc.
3. Allow supported models - homey5q (Pro 2023), homey6q (Pro mini), homey7q (Pro 2026), and SHS.
4. Allow unknown models - so future devices still show up until we know their IDs.

This is in the latest dev build. If you still see your 2019 in discovery, tell me and I can look at the logs again.

As always, thank you for testing. Really means a lot!

HOMEY_MODELS_SUPPORTED = frozenset({"homey5q", "homey6q", "homey7q", "shs", "desktop"})
HOMEY_MODELS_UNSUPPORTED = frozenset({
    "homey1s", "homey1d", "homey1q",  # 2016
    "homey2s", "homey2d", "homey2q",  # 2018
    "homey3s", "homey3d", "homey4d",  # 2019
    "cloud",
})

[Peter_Kawa]

My pleasure, Mike.
It seems you nailed it, v1.2.1-dev.4 doesn’t show discovered Pro 2019s.

Observation:
When manually installing & updating the integration, my previous selection was gone, all devices were back. Is this “as expected” with manual updates?
To update, I rename the custom_components/homey folder and upload the updated homey folder to custom_components, followed by HA restart.

[Peter_Kawa]

@smarthomesven

Super Homey (Early 2018)

Funny, these ‘Super’ models never seem to be sold

[ifMike]

@Peter_Kawa

My pleasure, Mike.
It seems you nailed it, v1.2.1-dev.4 doesn’t show discovered Pro 2019s.

Great! Then I’ll prepare a new main release, but I’ll wait just a bit to make sure I don’t get any other errors with this version first.

@Peter_Kawa

Observation:
When manually installing & updating the integration, my previous selection was gone, all devices were back. Is this “as expected” with manual updates?
To update, I rename the custom_components/homey folder and upload the updated homey folder to custom_components, followed by HA restart.

The device selection is stored in the config entry (in Home Assistant’s .storage/core.config_entries), not in the custom_components/homey folder. So it should actually survive a manual update where you only replace the files and restart.

Why it might still disappear

1. Removing and re-adding the integration - If you delete the integration in the UI and add it again (instead of just replacing files), you create a new config entry. That new entry starts with no device filter, so all devices are selected again.
2. Integration failing during the update - If you rename/remove the homey folder while HA is running, the integration can fail to load. HA may then mark the entry as failed and ask you to reconfigure. Depending on how that reconfigure flow works, it might overwrite the entry and drop the device filter (but this seems unlikely).
3. How you perform the update - Renaming the folder and uploading a new one can leave HA in a state where it treats the integration as needing reconfiguration, which can overwrite the stored config.

Recommendation

Use HACS for updates when possible. HACS updates files in place, so the integration stays loaded and the config entry (including device filter) is preserved.

If you must update manually, avoid removing the integration from the UI. Just replace the files, restart HA, and the device selection should remain.

[Peter_Kawa]

@ifMike

The device selection is stored in the config entry (in Home Assistant’s .storage/core.config_entries)

Aahhhh, thanks! I knew it’s not in the custom_components/homey folder, but I didn’t figure out where it’s actually stored.

.

@ifMike

Integration failing during the update

This probably was what happened in my case.
I didn’t disable the integration before renaming the actively used homey folder.

.

@ifMike

If you must update manually, avoid removing the integration from the UI. Just replace the files, restart HA, and the device selection should remain.

It’s a plan to temporary disable the integration I think.

.

@ifMike

Use HACS for updates when possible

I know, and it’s preferred by me as well, but, after I removed it, I couldn’t add the custom repository anymore, no matter what.

In a bright moment I thought “what if I restore a backup from when it was added already”, and this brought things to life again.

[Martin_Carangelo]

You saved my home. I was at my wits end. I wanted to bring all devices in through Homey and then distribute to homeassistant and Alexa. Alexa has the skill built in, that worked right away. I was pulling my hair out trying to find a way to expose to HA. This is perfect. THANK YOU!

[Heinz_Himmel]

I can’t integrate Homey into Home Assistant. Homey isn’t being detected.

[Peter_Kawa]

Hi Heinz,

I get the mix-up, but, you ended up at the HACS “Homey” compound addon for the Home Assistant Community app by Ronny Winkler, which is deprecated and unrelated to this “Homey Integration for Home Assistant” app by Mike.

In short:
Please add the repository by Mike to HACS “Custom repositories” first:

Next, make sure it’s added correctly:

Now you can look for “Homey Integration” and install it:

Next, goto Settings > Devices & Integrations > Integrations;
Hit the “Add Integration” button;
Select “Homey”:

.

See this link for the complete and extended instructions:

@ifMike

For detailed instructions, troubleshooting, and permission requirements, see the GitHub README:
https://github.com/ifMike/homeyHASS

[ifMike]

A quick update as well.

This integration will soon be available in the default HACS repo so that if you search for it in HACS it will show up.

I’m still waiting for the integration to be reviewed (which I’ve been waiting on since April 2).

Once it’s available there I’ll update the guide - and let all of you know!

All the best,
Mike