Homey integration for Home Assistant - Now Available! 🎉

Developers
162

Hi Mike!

Just FYI, v1.2.0-dev1: it still shows discovered Homeys, details:
https://github.com/ifMike/homeyHASS/issues/22

And, the missing entity values are back again, that seems to be solved.

163

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

164

Hi Mike,

dev3 installed:

  • no second Homey Pro entry :check_box_with_check:
  • all sensors active :check_box_with_check:
165

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)”.

Added description to setup flow
Added description to setup flow617×583 28.5 KB

Better naming for discovered Homey
Better naming for discovered Homey343×250 9.46 KB

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

All the best,
Mike

166

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.

167

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)

168

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

Screenshot_20260317_202036_Home Assistant
Screenshot_20260317_202036_Home Assistant1080×1529 89.9 KB

Screenshot_20260317_203649_Home Assistant
Screenshot_20260317_203649_Home Assistant1080×1156 134 KB

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

169

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 :slight_smile:

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 :slight_smile:

170

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;
171

Hi Mike,

I know my Homey 2019 modelIds are homey3d and homey4d.

Screenshot_20260318_023242_Vivaldi
Screenshot_20260318_023242_Vivaldi773×622 93.1 KB

Screenshot_20260318_023347_Vivaldi
Screenshot_20260318_023347_Vivaldi773×633 90.6 KB

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).

172

Thank you both! This is probably what I needed!

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",
})
173

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.

174

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

175

Great! :slight_smile: 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.

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.

176

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

.

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

.

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

.

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.

177

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!