IKEA Trådfri Gateway

Ok. The current snapshot does not contain my changes yet. Needs to be
pulled in by the maintainer.

I thought you did a manual build from my repository. :wink:

I can send you the built files or put them on the market place if you’re
interested.

Sure, but it has been a while since your PR, @Kai are you still maintainer?
When do you think @sourceror 's PR will be part of the SNAPSHOT?

Once it is in a reviewed and mergeable state, simply check https://github.com/eclipse/smarthome/pull/3799.

Thanks. Will watch that tread. :slight_smile:

Found this on another forum. Might help people with gateway connectivity problems.
I manage 3 OH2 sites and will try this on a problem site this upcoming weekend.
My gateway is no longer visible in the router client list, so a bad cable could very well be the reason.

The network cable that came with the gateway was delivered as a big knot, so I suspected that it would cause problems. As soon as I swapped it with a better cable, all problems vanished. The app now connects to the gateway instantly, and I’ve had no random drops.

Source

1 Like

Follow up:

This works fine, so the problem must be in the LED driver receiver it seems:

          logInfo("Motion", "hallLights ON")
   	      sendCommand(TradfriP1Bright, 90)        			
   	      sendCommand(TradfriP2Bright, 90)        			
          Thread::sleep(600)
   	      sendCommand(TradfriP1Temp, 50)        			
   	      sendCommand(TradfriP2Temp, 50)

Just seen the Tradfri binding, great job.

Is there a posibility to use the Tradfri motion sensor with the binding? Couldn’t find anything yet.

It might be possible when @sourceror 's PR comes through.
In the mean time it is possible to use the bulb/panel-state as an input to a rule:

rule "HallightsChange" 
when
    Item TradfriP1Bright changed or
    Item TradfriP2Bright changed
then 
    logInfo("TradfriP1Bright.state", "Update: TradfriP1Bright.state=" + TradfriP1Bright.state);    
    logInfo("TradfriP2Bright.state", "Update: TradfriP2Bright.state=" + TradfriP2Bright.state);    
end

I love openHAB integration of Tradfri - it works like a charm with bulbs! Thanks for the binding!

I consider buying the motion sensor.
I read that it can be paired to e.g. a bulb so that motion can turn on the bulb.
Will there events be visible in openHAB when motion is detected, so that I can use it to control something else than Tradfri bulbs? E.g Z-Wave items or alarm groups in openHAB?

It might be possible when @sourceror 's PR comes through.
In the mean time it is possible to use the bulb/panel-state as an input to a rule:

I have gone the other path, using the Z-Wave Aeotec Multisensor 6 sensor. That gives me temperature and humidity readings also.

If I have understood the motion switch correctly, it can only be set between 1 and 10 minutes. Would not this mean that it will send an off signal to the bulb after the given period?

Probably.
Just make the rule turn it on again.
Or use another bulb just as a state keeper. :slight_smile:

I guess that would work :stuck_out_tongue:

Are these smart bulbs multivoltage (multi-region compatible), i.e. can they be used with both 110V and 220V?

Marking on bulb says 220-240V 50/60Hz.
But then again, when I accidentally tries one on a dimmer, it lighted up fairly quickly, but made a noise, so I did not leave it on long enough to test the Radio part.
Ikea have a good return policy, so you could just try it out.

So they are not universal voltage bulbs like the Sonoff B1 bulbs.

No. Also checked out the Floalt panels. Same marking.
It could also be related to regional frequencies used for ZigBee.
I know that Z-Wave frequencies are different around the world. Unsure about ZigBee.

Thats a shame. Zigbee is universally 2.4GHz.

There is a change in the Tradfri Binding that was induced by @Kai (Kai Kreuzer) when modifying the original binding which I find very illogical. This is regarding the colot temperature. In the initial binding when sending “0” two the “color_temperature” challenge it would turn the light to the lowest color temperature i.e., the warmest light and “100” the highest temperature and coldest light. This I at least found very logical. In the current version this has been flipped around.

Could anyone explain why this was changed and how I could change this back to the original behaviour. I have tried with both the map and scale transformation on the item but I suspect that I’m not writing it correctly.

For my items, this is how they are normally specified and work:

Dimmer item_name "Name" <colorwheel> {channel="tradfri:0220:gwb072bfb31b8f:65537:color_temperature"}

And I have tried to change it to

Dimmer item_name "Name" <colorwheel> {channel=">[tradfri:0220:gwb072bfb31b8f:65537:color_temperature:MAP(tradfri.MAP)]"}

And I have a tradfri.MAP being:

0=100
1=99
2=98
3=97
...

This approach has been working well for my MQTT bindings but does not work at all for the trader binding.

Would be great to get som help on this.

Simple: All existing bindings for color bulbs (hue, LIFX, milight,…) do it the same way, so this is about consistency. The channel should maybe be regarded as a “warmth” channel - it takes a percentage between 0% and 100%, which defines how “warm” the light is.

1 Like