since your explaining an automation in your first line, how can you stop doing so in the second line? Im really interested how you’ve setup that, could you please share your code here?
With my testing once HA has the state unavailable , this will stay in this state until power is returned to the lights. You only need to force HA to get the unavailable state once.
So HA will remember the last state of the lights when power is cut . if you attempt to change the bulb state in HA when power is cut , it will then change the state of the bulb to unavailable. this stays in thiat state until power is restored and the lights resync with the tradri gateway hub. I have the advantage that I use a smart switch so I know when power is off , so I just wait 20 seconds and if the switch is still off i issue a light toggle to light group to force unavailable.
I use a template sensor (see above) and query this before I issue a command. If the sensor shows off I know there is no point in issuing the command as the lights are off. again with a smart switch I can just turn the lights on wait till they sync then issue the dim commands.
Without a smart switch you can run an automation against the template sensor . If the template sensor is on , you can prove they are on by changing brightness by 1% and back . If the lights are off , this will force unavailable. Therefore if the sensor is off the lights are really are off and you don’t need to test .
What we really need is HA to work this out for itself so the template sensor is always accurate.
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 
1 Like
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.
2 Likes
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.
1 Like
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 bought it a long time ago to test some devices, now it is becoming my main Zigbee hub.