Ikea Bulb

[theendisnye]

I have just included an ikea bulb into my configuration and it behaves very different to an OSRAM bulb using the same homeseer event to trigger it via DeConz.

On a transition up to full brightness the bulb goes up to the minimum level and then stops.
On some occasions when it is set to go to full brightness with no transition it goes to minimum brightness and then increases to full before decreasing back to minimum brightness a second later.

The details of the bulb are below.

Steve

[theendisnye]

I believe this is probably an instance of the issue related to sending CT and brightness settings in teh same message to an Ikea Bulb.

Steve

[ebaauw]

Setting brightness and setting colour temperature are two different ZigBee commands, it's technically impossible to combine them in a single ZigBee message. The deCONZ REST API translates the body of a PUT to a light state into one or more ZigBee messages.

When PUTting `{"bri":254, "ct":500} to the light state, deCONZ translates that into a Move to level command with Level 254 and (default) Transition Time of 4 (= 0.4 sec), followed by a Move to Color Temperature command, with Color temperature 500 and, again, a (default) Transition Time of 4. When issuing two separate PUTs, deCONZ sends exactly the same two commands to the bulb, but now there's some more time between the two commands.

The IKEA bulb cancels the current transition when it receives a new command. When combining "bri" and "ct" in a single PUT, the Move to Color Temperature arrives at the bulb while the birghtness transition of 0.4 sec is still in progress. A PUT of {"bri":254,"ct":500,"transitiontime":0} works as expected; a PUT {"bri":254,"transitiontime":40} followed by PUT {"ct":500}` doesn't work. I haven't tested this, but I bet the behaviour will be exactly the same when connecting the IKEA bulb to a Hue bridge.

In my humble opinion, this is a fundamental issue with the ZigBee "standard": it leaves too much room for manufacturers to interpret how to implement these commands, causing a different user experience (potentially) for each bulb/gateway manufacturer combination.

One could argue that this is a bug in the IKEA firmware. One could argue that this is a bug in deCONZ (and the Hue bridge) and that it should apply the default transition time of 0.4 sec only to Hue bulbs (but what about mixed groups...). It would be interesting to know how the IKEA hub handles this (if it even provides a single API command to change brightness and colour temperature). One could even argue it's a bug in the application (i.c. homeseer), that it doesn't specify the desired transition time explicitly (there was a similar problem with the OSRAM V1.03.07 firmware, for which I implemented a workaround in homebridge-hue).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Shaolo]

Are there any workarounds for this or are Ikea bulbs not supported at the moment?

I've tried sending temperature commands separate from brightness commands even throwing in a delay between the two and I still have issues with the Conbee not changing the light color, brightness, or both.

[manup]

The Ikea lights should work fine with delays between brightness and color temperature (so that the transition time is not active while a command arrives).

Which lights are you using and what exactly are the commands you're sending?

[Shaolo]

I'm using these: https://www.ikea.com/us/en/catalog/products/20318267/

I put in a 2 second delay

'office_bright':
  alias: Office Bright
  sequence:
  - data:
      entity_id: switch.office_lights
    service: switch.turn_on
  - delay: 00:00:03
  - data:
      brightness: 254
      entity_id: 
        light.office_bulb_1,ha
        light.office_bulb_2,
        light.office_bulb_3,
        light.office_bulb_4
    service: light.turn_on
  - delay: 00:00:02
  - data:
      color_temp: 250
      entity_id: 
        light.office_bulb_1,
        light.office_bulb_2,
        light.office_bulb_3,
        light.office_bulb_4
    service: light.turn_on

What's the minimum delay I should (can) use?

[manup]

Is it possible to get the actual REST-API commands send to deCONZ?

I don't know what the (HA?) yaml creates for api requests.

[Shaolo]

Yeah, this was pulled from last night: https://gist.github.com/Shaolo/367bbcc4933782cbd76e478f8f3a3468

[Shaolo]

Here's one I just pulled. The gateway is returning success but the lights aren't changing.

https://gist.github.com/Shaolo/9cd21a0c0609366ed5c0319b2e8df23f

[manup]

Interesting which deCONZ version is this?

It looks like this jumps to color mode xy, which is wrong for this kind of light.
Latest version 2.05.57 shouldn't allow this.

[Shaolo]

I'm running 2.05.57. Updated yesterday or the day before. Firmware 262F0500.

Should I attempt to reflash? If so, can I do it from windows. The docker process on the rPI was ...

[manup]

2.05.57 and Firmware version 262f0500 is fine.

Is the light controllable via Phoscon App?

Currently I just have Ikea color temperature GU10 spots here but they work very smooth without issues. We've also testet with E27 color temperature and CWs color bulb.

In the Phoscon App under Menu > Settings > Lights you may check the firmware version of the lights, maybe it is too old and needs to be updated.

[Shaolo]

Some report 1.2.217, some report 12217572. Most are 1.2.217 and the inconsistency is spread among both versions.

Works from Phoscon sometimes. Not consistently.

[manup]

some report 1221757

That's the old firmware version, not sure if it is related.

I can't replicate the issues with my current setup here. I'll do some tests with the E27 versions but it might not be before Friday.

[Shaolo]

I opened the conbee on windows so I could open deConz. Some of the lights present with only profiles 00/06/08.

I doubled checked the others and their short form string reads 1.2.217 and the long form says 12217572. I think they are likely all on the same firmware.

Not sure why some of the lights are only partially reporting.

Image below:

[manup]

Is this with the backup from the Raspberry Pi?

The lights on the top left are not fully queried (noteable by the ffff).
With deCONZ 2.05.57 this should be resolved automatically.

It can be done manually by selecting a node and pressing 8 on the keyboard, but normally this shouldn't be needed.

[Shaolo]

I unplugged the conbee from the π and took it to the win10 pc. Wasn't able to get in to the gateway as mentioned in another thread but that's what win10 deconz showed. Those lights were on for a while and they never self corrected in deconz.

On a potentially similar note, I think some of the issues are because the bulbs are not connecting or being recognized in the mesh network on startup. Regardless of how long they are left on. Seems random on which ones will work and won't work. I don't have access to the deconz gui on the π to see if the lights are connecting and what they might be connecting to, so it's difficult for me to help debug. Is there a way to sniff the network with another Conbee or CC2351?

[manup]

Those lights were on for a while and they never self corrected in deconz.

Hmm strange, I'll to some tests to recreate this incomplete descriptors situation, looking forward to solve this for 2.05.58.

Have you tried to query them manually by selecting a light and pressing key 8?

Having full descriptors is important since some of the functionality depends on them.

I don't have access to the deconz gui on the π to see if the lights are connecting and what they might be connecting to, so it's difficult for me to help debug. Is there a way to sniff the network with another Conbee or CC2351?

Yes you can sniff traffic with another ConBee with ZSHARK + Wireshark sniffer.
CC2351 support also sniffing but I have no experience with that.

But I'm afraid sniffing won't help much in this case, the issue needs to be solved in deCONZ core.

[Shaolo]

I did manage to get deconz UI setup and displaying over VNC on the PI. A couple of the bulbs take literally an eternity to connect to the network. Likely the ones that were refusing to take commands. I left them on and after about 4-6 hours they eventually connected. Before 4 hours I would see them come awake, send traffic, establish connections, then go back to red status.

These are all 980lm 3 color Tradfri bulbs with the latest firmware 1.2.217.

If there's anything else I can send let me know.

[Shaolo]

Something that might be related; I did notice tonight that turning the lights off and on without a specific color or brightness command causes them to come up in a default color other than what I typically use. I think someone else posted an issue similar to this. I don't know if that's an Ikea issue, or a deconz issue.

I'll have to test it out some more.

[manup]

Asking again :)

Have you tried to query them manually by selecting a light and pressing key 8?

Something that might be related; I did notice tonight that turning the lights off and on without a specific color or brightness command causes them to come up in a default color other than what I typically use.

The lights don't remember their color over a power-cycle.

[Shaolo]

Aside from that one time the profiles have been querying successfully.

A couple of bulbs keep dropping off the mesh even though they are no more than 2-4ft. from bulbs that have really solid mesh connections.

Second image was no more than a minute later that bulb dropped off. Selecting it and pressing 8 does nothing.

[manup]

The Kitchen bulbs seem to have a weak connection to the rest of the mesh in general. Are these located so far away from the other devices? Also not the housing of bulbs should preferably not be metal.

When you enable the LQI button in deCONZ UI you can see the Link Quality Indicator as number for the connections. (takes a while to populate)

[Shaolo]

Living room bulbs 1-3 and all 4 kitchen bulbs are in recessed lighting fixtures.

Kitchen light bulbs are spaced maybe 3ft apart and numbered in order. 4 is the furthest to the edge of the house and 1 is the closes to the center of the house. Kitchen bulb 3 has no reason to be dropping off the network. I occasionally see Office bulb 2 or 3 drop off the network and they are no more than 8ft. from the conbee stick in the middle of all the other lights in the mesh.

Conbee is on a 1ft usb extension cable sitting at least 1 ft from any metal.

Noting in the house is more than 50ft from the conbee stick. It's located centrally in the house.

[manup]

Living room bulbs 1-3 and all 4 kitchen bulbs are in recessed lighting fixtures.

Are these metal or plastic?

Kitchen bulb 3 has no reason to be dropping off the network.

As mentioned before the whole kitchen group has a very weak signal to their surroundings, I don't see a strong path to the coordinator. I guess this can only be improved with further repeaters in-between, like a Zigbee power plug.

Since as you mentioned in the other thread that your lights are also powered-off at times, the mesh has not really a chance to be strong and stable.

Noting in the house is more than 50ft from the conbee stick. It's located centrally in the house.

Side note: The common direct signal range for Ikea Tradfri is 32ft (aka 10 meters), but only in free sight with no housing or walls in between. This number drops rapidly with any obstacles.

[Shaolo]

Recessed fixtures are metal.

I'll look in to some cheap routers to improve the mesh. Any recommendations? I know of the Ikea Tradfri wireless control outlets.

Using the Tradfri gateway I never observed the kind of drop-off I'm getting now. At the least, the kitchen bulbs should have strong connections to each other shouldn't they?

Kitchen Bulbs 1,2,4 are all on the network. 3 still won't get back on.

[manup]

Recessed fixtures are metal.

Metal is a wireless killer no.1

I'll look in to some cheap routers to improve the mesh. Any recommendations? I know of the Ikea Tradfri wireless control outlets.

I would recommend to stay with Ikea here.

Using the Tradfri gateway I never observed the kind of drop-off I'm getting now.

Was the network the very same? I'm not sure how the Tradfri gateway handles routing and deciding when a device is not reachable anymore. Be aware that you see much more of the network with deCONZ than with Tradfri App.

At the least, the kitchen bulbs should have strong connections to each other shouldn't they?

When you look at the numbers it doesn't look strong to me. It's best to have at least some > 200 LQI numbers between "isles". Anything below from 180ish might work but should not be considered a strong signal.

Here is for example my small test network distributed through my home (apologies it's a bit messy).

And here is another of my test networks, but these devices all have power amplifiers ;)

[Shaolo]

I'm not aware of any plastic recessed lighting fixtures in the US. All the ones I've seen are metal.

I don't disagree about the connection strengths. I have a lot of orange in my graph.

Network was the same with the Tradfri gateway. Conbee is more more than 8ft from where the Tradfri sits, everything else is stationary and identical. I can't see signal strengths on the gateway though and maybe they are doing some sort of connection persistence? Who knows. Would have to disassemble their firmware to know for sure.

Are the numbers on the graphs sent/received? How are you calculating strength?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.