Ikea Tradfri problem

Thanks for the info - I thought Homey would know the status of the bulb regardless of how it’s been turned on its supposed to be smart – So if you have a power cut and then the power comes back on all the Tradfri bulbs will be on but Homey thinks they are off? - only just got a couple of Tradfri bulbs to test - I have set up flows for the switch but unfortunately you can only have a set dim level when a long press happens – I wanted to be able to have a varied dim level depending on how long I press the button - just like when the remote is paired directly to the bulb

Many other brands have a setting to set the state after powerloss (usually on, off or last known state). I don’t think the Trådfri devices have this setting. I haven’t tested but I assume they default to last state (makes sense as “dum” bulbs behave this way)
Regarding dimming: There is no way using flows to simulate that kind of behaviour reliably sadly. What you can do is relative dimming; i.e. X% up or down per longpress on the remote (I don’t know which remote you have, but my Trådfri remotes have a longpress event)
That means that for example one longpress down will dim the bulb X% down from whatever level it currently is. Then you have to let go and do another longpress - and so on…
This has nothing to do with IKEA btw. this is dimming with flows in Homey regardless of brand.
(Using z-wave devices will allow what you want, but that does not help you of course)

Like I wrote; not a good experience by any means…

Example flow from my Trådfri remote - bulb combination:

What might work is to reset both devices, then add the light to Homey, then TouchLink it with the remote.

I’m don’t think the bulb has last state but will check that again - Will give that type of flow a go - Thanks

I have tried it that way as you mentioned when I first got the bulbs - turning on the bulb with the remote Homey doesn’t know the status of the bulb – shame really

The IKEA app should turn on attribute reporting then (it’s strange it doesn’t do so by default, because IKEA lamps support it and it’s not resource-intensive to do so).

I’m connecting the light bulbs directly to Homey and not through the Tradfri bridge – I didn’t want another bridge as I have a Philips Hue bridge – Only got a few bulbs to test last week as they are a lot cheaper than Philips Hue

Yes, I meant the IKEA app for Homey, which handles those lights.

I don’t have a Tradfri bridge so wont be able to use the Ikea app

If you paired your lamps with Homey you’re already using the IKEA app for Homey.

There is no doubt (I think) that we are both using the Trådfri app created and maintained by Athom.
The issue is that when both the bulb and the remote are included in Homeys Zigbee network (and both fully working as such) and the remote is direct linked with the bulb. (Like Athom describes here: https://support.homey.app/hc/en-us/articles/360015669840-Controlling-a-Zigbee-device-with-a-Zigbee-remote-directly)
What then happens is what I and @woto (If I understand him correctly) experience:

  • Homey gets no information when the remote is used (dimming, on/on). Homey is clueless as to what the remote is doing to the bulb
  • The remote that normally can change color temp when directly linked with the bulb without Homey (or included with the Trådfri bridge for that matter) Can no longer change color temp using the side buttons.
    Creating flows using all the buttons on the remote is however no problem.

I understand the problem, and I explained what the app developer has to do to get reporting working properly here.

As for the side buttons, I believe this is also an issue with other Zigbee implementations (like zigbee2mqtt) and seems to be caused by a non-standard way of how IKEA (or its gateway) deals with those buttons. But “direct dimming” should be possible.

I understood your point about attribute reporting - I was just trying to summarise a bit :slight_smile:

If the side button problem is a known issue even with other solutions then I guess that is a dead-end for now.

That leaves us with trying to get Athom to understand the issue and update their app accordingly…
I have been in contact with their support, but very little came out of it - see my first post in this thread.

1 Like

Yeah, I read it, hopefully mentioning the right words will get the support person to ask someone more knowledgeable about the app :slight_smile:

Ok - I thought you meant the Ikea Home Smart 1

1 Like

…I reopened the support ticket with a reference to this thread now - Lets see what happens :slight_smile:

That brilliant - fingers crossed

Athoms answer is in:

I checked this with our developers and the bulb, in this case an IKEA bulb has the responsibility to report a change in its status back to Homey. Unfortunately this doesn’t always work with every brand/bulb.
If you use a remote which is also paired to your Homey Pro, you can of course create a Flow so Homey will change the status of the bulb which results in a 100% accurate status.
I hope this answers your question to your satisfaction, which is why I’m closing your ticket. If you need additional support, please feel free to re-open your ticket by answering this email.

Brushing it off with “…doesn’t always work” seems a bit “easy” to me…

Typical BS answer, I’m afraid.

Reporting has to be turned on explicitly, and it’s working fine for all of my IKEA devices when using zigbee2mqtt.

That is my thinking as well.

I was thinking about having a look at the sourcecode (I can read Js/typsecript, but have never delved into Homey apps), but I can’t seem to find the code on Athoms github account. Don’t they even publish their own apps? (If that is the case: why the H… not??)
Looking at their example IKEA app I certainly can’t find a trace of Attribute reporting as described here, but that may no be representative of the apps actual code of course…

What do you think about the “solution” og creating a flow to set the state of the bulb? It seems a bit wonky to me - Sending an extra ON to a device that is already on does no actual harm (probably), but I can imagine issues when (not if) Homey/Zigbee misses an event and the state in Homey does not match the actual state.