Test if Tradfri light is available/reachable?

Third party integrations
15

just to be precise, it will turn to unavailable if the power IS cut. Not if it WAS cut and is restored…

setting the brightness is a bit of a trick which comes in useful when turning the light on when it already is on and you don’t want to change it.

The |int is a second trick needed when the light is actually off (but is powered), for then is doesn’t have a brightness and is in fact None. Making it an int in that case allows the same automation to run.

the condition is obvious: if it has already been diagnosed as unavailable, there’s no need to run the automation to say so :wink:

I’ve added a little customization to show on the group of lights, making it clear in the frontend the group has no power:

group.parking_lights:
  templates:
    icon_color: >
      if (state === 'on') return 'rgb(251, 210, 41)';
      return 'rgb(54, 95, 140)';
    _stateDisplay: >
      if (entities['light.parking_light'].state === 'unavailable') return 'Power off';
      return '';
16

Thanks for the input. Setting the brightness did the trick.

Just to clarify regarding my use case.

I want the lights to go to unavailable as soon as the wall switch turn them off.
This works by periodically send on and brightness to the bulb if it has state on in HA. Then it will switch to unavailable if it is not reachable by HA.

If the wall switch turns them on again, HA automatically catches this and set the correct state without any automations involved.

Thanks again!

17

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?

18

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.

19

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

1 Like
20

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
21

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

22

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

23

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

24

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.

25

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

26

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
27

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.

28

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 }}
29

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!

30

@Olivier1974:
OMG!!! I love you man! You solution works perfectly!
Kudos and respect!

31

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

32

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.

33

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

34

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)