exactly, so true.
I’ve tried to convey that to the Ikea dev team . Would be best, and should be rather easily done, since Tradfri pushes its states to HA (unlike Hue, which has to be polled)
Anyways, I think you are right with your above techniques establishing unavailable, though it seems rather complicated, and, needs a smart powerswitch.
Theres no need to change the brightness. Try my automation and you’ll see it works just fine, and nobody notices anything 
This is my configuration. It will with this timer configuration manage to set the bulb to unavailable within 30 seconds if the power is cut manually.
- id: '1542230014070'
alias: Check Ikea Kitchen
trigger:
- hours: /1
minutes: /1
platform: time
seconds: /30
condition:
- condition: state
entity_id: light.kitchen_1
state: 'on'
action:
- data_template:
entity_id: light.kitchen_1
brightness: >
{{ state_attr('light.kitchen_1','brightness') | int}}
service: light.turn_on
When the power comes back the light shows up as on again in HA without any custom automations.
sorry, but i don’t understand that would work given the condition you have:
- condition: state
entity_id: light.kitchen_1
state: 'on'
state won’t be on if the light is unavailable, hence the action won’t trigger? Ive tried many situations, and ended using !=‘unavailable’… working in any situation
If you cut the power to the bulb while it is ‘on’, HA still thinks it is on, and the condition is met.
In my case I am only interested in when the light has the power cut while it is turned on, and then make it go ‘unavailable’
If it is off I currently don’t care if it is unavailable or just off. At least for now 
I see. I had to make the distinction between being power cut and being ‘off’ with power.
I both cases my automation does its job.
cool to see each has their own needs. and solutions
In case this is of use to anyone, I’ve had a go at creating a blueprint for this, which can be found at TRÅDFRI unavailable detection.
Hi @Mariusthvdb, sorry to reopen this old post.
I would like to know if your trick works again also today.
I tried with this automation but it didn’t works:
alias: ikea test
description: ""
trigger:
- platform: time_pattern
minutes: /5
condition:
- condition: template
value_template: "{{ states('light.luce_bagno_blu') != 'unavailable'}}"
action:
- service: light.turn_on
metadata: {}
data:
brightness: |
{{ state_attr('light.luce_bagno_blu','brightness') | int}}
target:
entity_id: light.luce_bagno_blu
I got the IKEA Tradfi Gatawey and I haven’t Zeegbee/Decons/ZHA or other USB dongle…
If I power off the Ikea Bulbs from the wall switch their status remains “on” and don’t go to “unavailable”. Only some bulbs do this, the others stay always “on” for hours/days. So, your automation give me a fake value of brightness, because in reality the bulb is switched off from the wall.
This happens also in the Ikea App (smartphone). No status updated
My Ikea Bulbs firmware for someone is 2.3.093, for others 2.3.095 (but this issue seems non related to bulbs firmare). Instead, my gateway firmware is 1.21.31.
Thanks
That doesn’t work.
Hub is smart enough to not send the same info to the bulb.
You have to change the brightness.
What I did, create a script:
alias: Control IKEA light
sequence:
- if:
- condition: template
value_template: "{{ states(light_name) != 'unavailable' }}"
then:
- if:
- condition: template
value_template: "{{ states(light_name) == 'on' }}"
then:
- if:
- condition: template
value_template: "{{ state_attr(light_name,'brightness') > 1 }}"
then:
- service: light.turn_on
data:
brightness: "{{ state_attr(light_name,'brightness') - 1 }}"
target:
entity_id: "{{ light_name }}"
- delay:
milliseconds: 100
- service: light.turn_on
data:
brightness: "{{ state_attr(light_name,'brightness') + 1 }}"
target:
entity_id: "{{ light_name }}"
else:
- service: light.turn_on
data:
brightness: "{{ state_attr(light_name,'brightness') + 1 }}"
target:
entity_id: "{{ light_name }}"
- delay:
milliseconds: 100
- service: light.turn_on
data:
brightness: "{{ state_attr(light_name,'brightness') - 1 }}"
target:
entity_id: "{{ light_name }}"
else:
- service: light.turn_off
data: {}
target:
entity_id: "{{ light_name }}"
mode: parallel
icon: mdi:lightbulb-question-outline
max: 50
Then call the script in your code:
alias: "[Contols] Check IKEA lights"
description: ""
trigger:
- platform: time_pattern
minutes: /5
condition: []
action:
- repeat:
sequence:
- service: script.turn_on
target:
entity_id: script.control_ikea_light
data:
variables:
light_name: "{{ repeat.item }}"
for_each: >-
{{ expand('light.ikea_lights') |
map(attribute='entity_id') | list }}
mode: single
I’m using a group that contains all my IKEA lights `light.ikea_lights
Explanations: if light is off, I off it. If it is on, I change the brightness by “1” up or down to not off it nor exceed 255 and back.
This force a message to the light and if it doesn’t work, it is marked as unavailable by HA.
Hi Oliver, thanks a lot.
In the script you write:
I don’t understand if I have to create a script for each Ikea bulb or if I have to recall also here the light group of my IKEA bulbs.
light_name is a variable that I’m giving to the script.
It is built on each of the entity_id that are the light group.
{{ expand('light.ikea_lights') | map(attribute='entity_id') | list }}
Oh, OK!
So i have only to group my ikea lights and use it in the script. I’m going to try it. Thanks again!
out of curiosity: why would this still be a useful automation?
in the past, I only did this to keep the gateway alive, and controlling a single light did help. setting a light to its current state.
now I see this being executed to all lights, I am wondering why you would hammer the gateway so often, and it this isnt more hurtful than the original issue.
btw, the Ikea integration suffers terrible performance regularly, requiring restarts more than a few times per day, and even HA restarts now, to complete the integration restart…
GitHub issues for that exist since over a year and no action is taken unfortunately
It is because when a light is physically switched off, the tradfri gateway is not reporting the light as unavailable. It never did unless you change something on the light.
So this script, by slightly changing from time to time the brightness on all lights trigger the unavailable state to be reported correctly in HA. Otherwise, the light remain on/off while it is actually unavailable.
If 5 minutes is hammering the gateway, you can increase the time and/or change the group to only contains the lights that really matters (e.g.: state transition from/to unavailable used in another automation). Note: only include lights that are powered by the main line, otherwise it will drain the battery.
As I said, sending the exact same values did not work for me, the gateway being smart enough to not flood the zigbee network for nothing hence the slight change of brightness.
I see, you are still tackling that peculiar behavior.
I on the other hand am getting more and more frustrated with the integration losing touch with the gateway and requiring reload or worse , restart of Ha…
Don’t you experience that, seems way more impactful and blocking core operation because of unavailability to the system
I do of course.
I bought a sonoff micro for that particular reason that is cutting the usb cord of the tradfri gateway.
I’ve an automation to off/on the sonoff when there is a suspicion of disconnection (I compare some light sensors with the status of some key light bulbs)
If I have reasonable suspicion, I switch the sonoff, wait 1 minute then restart the IKEA integration (I used to restart HA but it seems to be from the past, at least for me)
For all those reasons, I’m moving to a Zigbee CC2531 that is plugged to my RPi. It is not very powerfull but with the meshing, it is working fine (up to 30 devices I think but still not there, for now)
yeah, if only the Ikea Integration would be working properly again we could save ourselves all of that trouble…
I am in the midst of deciding to migrate most to the Dirigera and integrate via Homekit, or add the devices to my SkyConnect ZHA.
unfortunately we see a lot of ZHA issues too, so that makes me hesitant to move over all of these devices (I have a bit more than 30).
Technically, Zigbee (and ZHA) are not limited in number of devices.
But the small CC2531 that was originally meant to do zigbee sniffing and that I flashed for zigbee2mqtt is not strong enough to handle more than 30 devices or very poorly probably.
I tried @Olivier1974 his script and automation, I see in the log that it is changing the intensity of the lights, but the lights don’t become unavailable even though they’re powered off. Also, if I change something manually about the lamp, it just jumps back to the previous value without becoming unavailable.
Are the other people in this thread who were using this kind of scripts/automations having the same issue?
I’m using a Dirigera with Home Assistant 2025.1 Tried with both the IKEA Dirigera integration and through Dirigera to Matter. In the Ikea Home Smart app the lamps become unavailable a few seconds after turning off the power.
In those days it was a Tradfri not a Dirigera gateway.
Don’t know if the script is working in the same way with the Dirigera GW.
But since, I’ve also switched to a more powerfull Zigbee USB key and in Zigbee2MQTT, I asked for a reporting of color, intensity and OnOff status, that solved the issue I had with Ikea.
Moreover I was able to pair all my zigbee devices on only one non proprietary hub.
