Homey integration for Home Assistant - Now Available! 🎉

[Daniel_Cruz]

Hi @ifMike

Yes of course.

I added the code you requested as one issue there:

Shelly 2.5 - Cover Mode

Thank you.

[Marcel_Visser]

Hi, Thanks for this great addon. Its working really great.

Only one thing is not working. Logic numbers should also be availible right? I can not add them while I enabled them in the api.. I like to import numerical variables to HA. But I cannot select them. Should this work?

[ifMike]

Homey Integration v1.1.7 Released

Highlights

• Multi-Homey support with auto-rescope and collision-safe IDs (single-hub users unaffected)
• Logic Variables (numbers/booleans/strings) now show as entities
  • Requires homey.logic.readonly (and homey.logic for edits)
• Options improvements: update API key/host + better string exposure controls

Added

• Read-only string sensors enabled by default (optional editable text entities)
• Extra switch support for additional settable booleans
• Enum/string select entities for mode-like capabilities
• Capability reporting with prefilled GitHub issue links
• Generic sensor coverage for numeric/string capabilities
• Heat pump compressor counters
  … and more

Fixes

• Cover control handling for enum/numeric capabilities
• Prevent cleanup from removing the Homey Logic device
• Multi-homey collisions and migration gaps
• Light temperature inversion toggle persistence
• Binary sensor filtering for settable booleans
• Restored missing heat pump status entities
  … and more

Changelog: homeyHASS/CHANGELOG.md at v1.1.7 · ifMike/homeyHASS · GitHub

Notes

• Single Homey users: No change needed - the integration works as before
• Multiple Homeys: When a second hub is added, entities are re-scoped to avoid collisions and device visibility issues
• Missing status strings: If you can’t see status/notification strings, check the string toggles in settings; you can disable them if you don’t want those entities

Are you experiences issues?

Start by reloading the integration first. If that does not solve you issue, remove it completely and restart. Then add it again.

There is no loss of data if you remove the integration. Yes, your dashboard will look broken until it’s installed again. But that’s it.

[ifMike]

@Marcel_Visser

Hi, Thanks for this great addon. Its working really great.

Only one thing is not working. Logic numbers should also be availible right? I can not add them while I enabled them in the api.. I like to import numerical variables to HA. But I cannot select them. Should this work?

Fixed in v1.1.7 - thank you for that! I totally forgot about variables from the API documentation.

[Undertaker]

Hi Mikael,
since updating to v1.1.7, the Homey token has disappeared when I restart HA. This happens with early23 and early26. Perhaps you could take a look at this when you have a chance.

[ifMike]

@Undertaker

the Homey token has disappeared

Hi!
What do you mean with disappeared?
You lost connection?

[Undertaker]

[Peter_Kawa]

The API field was always empty, Uwe, right after you enter & save it. So that’s “by design”;
But, I noticed my 2nd Homey had unavailable devices;
Opening the selection menu, and then just save it (without changing anything in the selection) solved it for me.

[Undertaker]

I saved it empty and will report back.

[ifMike]

@Undertaker

I saved it empty and will report back.

As Peter said, that’s by design. You only need to enter it if you want to change it.
I don’t want to expose the full API key in that field at all times.

@Peter_Kawa

The API field was always empty, Uwe, right after you enter & save it. So that’s “by design”;
But, I noticed my 2nd Homey had unavailable devices;
Opening the selection menu, and then just save it (without changing anything in the selection) solved it for me.

I will have a look at why a second Homey would need to be “re-saved”. It should not be like that, but I’m glad you found a simple solution!

[Undertaker]

Unfortunately, saving it again does not solve the problem. Every morning, I have to enter the token again .

[Daniel_Cruz]

Hello @ifMike,

Just a quick feedback after upgreade to version 1.1.7.

I have already 50 devices using the this integration and for now they are working all in a stable way.

Just the cover mode in all of them (Shelly 2.5, Shelly 2PM Gen3, Shelly 2PM Gen4), stop isn’t working.

[ifMike]

@Daniel_Cruz

Just the cover mode in all of them (Shelly 2.5, Shelly 2PM Gen3, Shelly 2PM Gen4), stop isn’t working.

Hi Daniel!

From the capability dump, the device does expose stop as windowcoverings_state = “idle” and it is marked as setable: true, so in theory stop should work.

However, whether it actually stops depends entirely on how the Shelly cloud driver handles “idle”.

Can you test this directly in Homey Developer Tools → API Playground

Test 1

In the Homey Web API Playground, run the below while the blind is moving (up or down).:

Homey.devices.setCapabilityValue({
  id: "YOUR_DEVICE_ID",
  capabilityId: "windowcoverings_state",
  value: "idle"
});

Possible outcomes:

• If it stops:

Then the device supports stop properly, and the issue is likely in how the command is being sent and I can continue to check for errors in the code.

• If it does NOT stop:

Then the Shelly driver is simply ignoring “idle”.

After a “google trip” I noticed that some Shelly cover drivers only support up/down, and don’t implement a true stop command even though the enum exists.

Test 2

You can also try testing stop via position, since some Shelly drivers don’t handle “idle” but do stop when you re-send the current position.

First, note the current position from the device (e.g. 0.42).

Then in the Homey Web API Playground, run the below while the blind is moving (up or down).:

Homey.devices.getDevice({ id: "YOUR_DEVICE_ID" })
  .then(d => {
    const pos = d.capabilitiesObj.windowcoverings_set.value;

    return Homey.devices.setCapabilityValue({
      id: d.id,
      capabilityId: "windowcoverings_set",
      value: pos
    });
  });

Possible results:

• If it stops:

Then this device expects stop via windowcoverings_set rather than “idle”.

That means stop works, but only through the position path.

• If it does NOT stop:

Then the Shelly cloud driver likely doesn’t support stop at all — only up/down.

So please test both:

1. windowcoverings_state = “idle”

2. windowcoverings_set = currentPosition

That will tell us:

• which stop mechanism (if any) the driver supports

• whether this is a driver limitation rather than a bug

Let me know if any of the above worked or not!

[ifMike]

@Undertaker

Unfortunately, saving it again does not solve the problem. Every morning, I have to enter the token again .

I will check the code and try to verify. Do you get any errors in the HA log as well?

And just to clarify:

• The API key field in HA will always be empty - that is by design. You only enter the API key here if you need to change it, but that will also “disappear” once it’s been saved. This is just an “update API key field” so to speak.

Question:

• Do you need to enter the API key for the devices/integration to work every time you restart, or does this happen even if you don’t restart HA?
• I am guessing that you are running a multi-homey setup. Does this affect both of the hubs or only one? (The “first” or the secondary?)

[Undertaker]

@ifMike

Do you need to enter the API key for the devices/integration to work every time you restart, or does this happen even if you don’t restart HA?

It happens every night, even without restarting HA.

@ifMike

I am guessing that you are running a multi-homey setup. Does this affect both of the hubs or only one? (The “first” or the secondary?)

This only affects the secondary hub.

[Daniel_Cruz]

Hello @ifMike

Using Homey directly it stops in 2 ways.

1 - By the interface - All Good

2 - By the Web API Playground - All Good

I just had to change a little bit the code, because it was not geeting the deviceId.

Code used:

Homey.devices.setCapabilityValue({
  deviceId: "c0f48c3d-e04e-49f6-a8b3-cb33a8387512",
  capabilityId: "windowcoverings_state",
  value: "idle"
});

Response:

"root":{2 items
"transactionTime":float1770039198100
"value":string"idle"
}

[ifMike]

@Undertaker

It happens every night, even without restarting HA.

Hi!
The issue wasn’t the token itself (99% sure..).
A single transient 401 from the Homey API triggered an immediate reauth, so the secondary hub asks for the API key every night even though the key was still valid.

The fix:

We now only trigger reauth after repeated 401s within a short window, and we log a clear message explaining why it happens. This prevents false prompts while still catching genuinely invalid keys.

So if it happens again, check the log and let me know!

Look for these log lines from the Homey integration:

• Authentication failed (401) for devices endpoint …

• Received 401 from all device endpoints … Deferring reauth until repeated failures.

Those lines also include the likely causes we now log (token invalidated, hub unreachable, or host resolving to the wrong Homey/mDNS). If you don’t see them, enable debug logging for custom_components.homey and then reproduce overnight.

You should have the update in v1.1.8 (available in HACS).

[ifMike]

@Daniel_Cruz

2 - By the Web API Playground - All Good

Hi Daniel!

Root cause:

Some Shelly covers expose both a numeric position capability and an enum state (windowcoverings_state with up/down/idle). The integration was prioritizing the numeric path, so “Stop” never sent idle, which is what these devices require to stop.

The fix:

The integration now detects enum‑based covers and sends windowcoverings_state = “idle” for stop (even when a position capability exists). This restores stop on Shelly 2.5 / 2PM Gen3/Gen4 and similar drivers.

Hopefully this resolves your issues! Let me know otherwise!

It’s available in the HACS update (v.1.1.8)

[Peter_Kawa]

Hi Mike!

a. I’ve noticed a few “new capabilities found” notifications, but I cleared the notifications too quickly.
Can I find those in the app (logs) somewhere?

b. Is it possible to use the capability titles instead of the capability names?

Homey

H.A.

[ifMike]

@Peter_Kawa

a. I’ve noticed a few “new capabilities found” notifications, but I cleared the notifications too quickly.
Can I find those in the app (logs) somewhere?

Those are Home Assistant persistent notifications, not stored in Homey. Once you dismiss them, HA doesn’t keep a history you can browse. So we can’t really see them again.

I added that to let users report new capabilities their devices have - that I’ve been missing.

@Peter_Kawa

b. Is it possible to use the capability titles instead of the capability names?

Great input! And yes, it should be possible.

Some entities already use the Homey capability title (when available), but many still use the capability ID to keep naming stable and consistent.

For 1.1.9 I could add an opt‑in option to “Use Homey capability titles for entity names.” And possibly have that as the default behavior for new installs of the integration.

That means:

• Existing entities stay unchanged by default for current installs (no surprises, no broken automations).

• New entities created after you enable the option will use the nicer Homey titles.

• I’ll also add a one‑time “Rename existing entities” action that updates the display name only (not the entity_id), so automations keep working.

That gives everyone a clean, safe way to switch to titles only if they want to.

I’ll post again when 1.1.9 is ready (whenever I have the time )

How to get nicer names right now:

Rename entities in Home Assistant:

1. Settings → Devices & Services → Entities

2. Search for the entity

3. Open it → Rename

4. (Optional) Toggle “Update entity ID” if you want the entity_id changed too