Help with Zigbee RGBW Downlights from 3A Smart Home (Nue)

Hi :slight_smile: TLDR: Can somebody please run my tests with any ZigBee 3.0 light (3A Nue preferred) and try to reproduce my results?

I’m having problems with my 3A Nue Zigbee RGBW 9W Downlights. Ideally, I’d really like it if somebody could please try to reproduce these results on 3A Nue lights, Philips Hue, or any other brand of Zigbee lights. I’m mainly using Home Assistant Dev Tools to call services, but I’ve also tested with the dashboard in some cases.

I’m using Home Assistant 2022.11.1, Operating System 9.3 and the Philips Hue integration (these lights are meant to be compatible).


Test 1 - brightness
Turning the light on with a brightness attribute always results in the lights turning on with low brightness, regardless of what setting is used.
Note that I deliberately chose to go from 1% to 100%. Test 2 shows why going the other way would compromise the test.

Click to expand and see details
  1. Start with the Zigbee light set to:
    • Colour name: Red
    • Brightness: 1%
  2. Call the light.turn_off service.
  3. Call the light.turn_on service with the following attributes.
    • Brightness: 100%
    • Do not set a Colour.
  4. Result: The light turned on with
    • :white_check_mark: Colour: Red
    • :x: Brightness: 1% sometimes, other times it’s low, but still not 1% and definitely not 100%. The intended result was to not change the brightness from 100%.

Test 2 - colour
Turning the lights on with a colour attribute and no brightness results in no colour change, but also with a brightness change, even though brightness shouldn’t be affected.

Click to expand and see details
  1. Start with the Zigbee light set to:
    • Colour: Blue
    • Brightness: 100%
  2. Call the light.turn_off service.
  3. Call the light.turn_on service with the following attributes.
    • Colour: Red
    • Do not set a Brightness. Uncheck the box.
  4. Result: The light turned on with
    • :x: Colour: Blue. The intended result was Red.
    • :x: Brightness: ≈1% or something low. The intended result was to not change the brightness from 100%.

Test 3 - turn off after brightness change
Turning the lights on with a brightness setting results in them never turning off.

Click to expand and see details
  1. Start with the Zigbee light set to:
    • Colour: White
    • Brightness: 50%
  2. Call the light.turn_off service.
  3. Call the light.turn_on service with the following attributes.
    • Brightness: 100%
    • Do not set a Colour. Uncheck the box.
  4. Result: The light turned on with
    • :white_check_mark: Colour: White.
    • :x: Brightness: ≈1% or something low. The intended result was to not change the brightness from 100%.
  5. Call the light.turn_off service.
  6. My result was:
    • :x: the light didn’t turn off. The intended result was for the light to turn off.
  7. Call the light.turn_off service again. And again… And again.
  8. Result:
    • :x: It still won’t turn off. The only way to turn it off now is at the wall switch or to first call the light.turn_on service WITHOUT a brightness attribute and then call light.turn_off again.

I have a Philips Hue Bridge V2, but I’m currently waiting for one of Tube’s CC2652P2 based coordinators to arrive. My hope is that this will fix my issues, or at the very least, that it will allow me to use Zigbee2MQTT or ZHA to get better diagnostics than I can from the Hue Bridge.

The 3A Nue manufacturer says this, referring to a combination of tests 1 and 2.

“Yes, our engineer can see this issue with Hue Lights and our lights as well. I suppose the reason is related with the scene commands that it is broadcast command that just send out one time and does not check if the the device receive it or not. In my opinion, it may happen with other zigbee hub as well .”

But I’m not using scenes, am I? What counts as a scene in the Zigbee world? I’m calling services from the Home Assistant Dev Tools.

Turning the lights on without any attributes (brightness or colour) does work, but that’s not good enough.

Click to expand and see details

Test 4 - Just turning the lights on and off

  1. Start with the Zigbee light set to:
    • Colour: Red
    • Brightness: 50%
  2. Call the light.turn_off service.
  3. Call the light.turn_on service without any additional attributes.
  4. Result:
    • :white_check_mark: Colour: Red
    • :white_check_mark: Brightness: 50%

Hi Mortalitas,
Did you ever get a result or fix with the 3A Nue lights?
I experience the same results as you.
Is it a 3A Nue firmware issue?
Cheers.

Hi Tom,

I’m always happy to help. Please forgive my aggressive response, I’m still annoyed with 3A Nue.

It’s 100% a 3A Nue firmware issue and the manufacturer is a disgrace to engineering because all he did for 5 months was pass blame to other systems like Home Assistant, Phillips Hue, ZigBee2MQTT, Tubes coordinator, Node Red, etc. And the workarounds he proposed would have defeated the point of having smart lights.
I sent my test data to Amazon who stepped in and refunded me for all 28 lights. The seller in this case is the Manufacture (they both have the same email).

Sorry, anything I’ve posted on this forum about this is out of date and probably wrong. I learnt a lot about ZigBee while testing these lights and haven’t updated my posts.

The summary is that the 3A Nue lights haven’t properly implemented all the mandatory commands that are defined by the Zigbee specification. Using some of these commands causes the lights to get stuck in various states. e.g. Anything that makes the coordinator decide to send the MoveToLevel or MoveToLevelWithOnOff will stop the lights from responding to the more basic On, Off, brightness and colour changing commands. Although when stuck in this state, you can still use the Move commands. To use the basic ones again you need to power cycle the lights at the wall switch.
Btw, a workaround @Interloping helped me with is to give the lights a permanent transition time on a coordinator level. Z2M has this setting under Settings (Specific). Pick something fast like 0.1s (or faster if it lets you) because the lights will transition instantly regardless of what you do (unless it’s a colour command which can transition, but with wrong timing). This will keep your lights working most of the time and you’ll only lose some features instead of most of them.

The other problem is when the Fade to Off (0.8s) command is sent which is used by the Philips Hue bridge. While that command is not mandatory, it’s not ok for a manufacturer to advertise compatibility with Phillips Hue only to break when it receives the command Hue uses to turn the lights off. It’s ok for Hue and others to use this command, but the expectation is that the lights would treat it as a basic Off command if they haven’t implemented it. These lights try to, but they break on whatever command you send after the Fade to Off which is why you might see the lights turning back on with weird settings.

Also, I pulled apart the hardware, and while it would be super easy to replace the processor with your own, I’m not entirely convinced that it’s safe to put >320V down a ≈2mm pitch connector. It might be and I know the IPC standards are more complicated than that. But I feel I should point that out just in case. Maybe somebody with access to the standard that talks about creepage can help.

Thanks @Mortalitas.
Sounds like you had to put a lot of time in to get to this conclusion!
Have you found an alternative to 3A that works with Phillips hue?
I have about 10 of these lights, and only a few spots I deem critical, where I want all options we would expect with a smart light.

I’ve not found anything yet. I was contemplating the idea of replacing the processor that’s on a separate PC with my own and making my own Nordic based firmware, but I’m not so sure about the design of this light.

But with the number of lights that look identical to the 3A Nue lights, I have to wonder if there’s some generic enclosure out there you can buy and put your own electronics in. I’d be more keen on that if I could track down the enclosure.
(I’ve not tested this light, I’m just showing that the enclosure looks the same.)

I’ve purchased over 140 Nue 3a zigbee (down)lights for use across 5 Hue bridges and I’m having exactly the same issues. I cant believe they’re still alllowed to sell this rubbish when it simply doesn’t do what it says it does. I’ve tried everything with no aid.
It’s that bad, that I’m considering buying a bunch of zigbee AC switches, and wiring each room up in the ceiling so the switch just turns the power rely on and off and the light switch in the room just controls that. It’s been a massive let-down, these lights have ZERO consistency, and don’t comply with the zigbeee protocol standards. If anyone has any success, please share.

HI Mark,
Can you get a refund on your 140? I bought my 40 through Amazon but since the seller was an arsehole, Amazon had to step in and refund me which took 5 months. They said they would investigate the seller and stop them from selling on Amazon, but I can see that didn’t happen.

I really dug in deep analysing these lights and they really are garbage. There are of course all the bugs I’ve posted about which make these lights unusable. However, you should know that they also put >300V on a 2mm pitch connector. I don’t have access to the IPC standards right now, but I doubt there is enough creepage for that to be safe. And after about 8 months of consistent use, several have failed. As in they don’t turn on, but I haven’t pulled the broken lights apart yet.

These 3A Nue downloads are not safe to use, and they are not functional enough to use.

1 Like

I’m trying to find gu10 zigbee to use now but not sure which one’s a good after all these conversations

Ive had so many other priorities that ive just left these in the ceiling. We have at least 1 light lock up a day and stay on, or never come on at all. All sorts of random brightnesses and colours. Ive just put up with it.
Ill ring this guy in Victoria one of these days and have a word. Its really shameful. I think ill setup an auto reset every week (or night) to try and bring them back. Im certain its some kind of bad code that gets itself stuck. Keen to hear if anyone has any luck in any form with the 3a Nue Zigbee downlights. I’ll try and wait it out until the lights die. Maybe replace them room by room, when someone can vouch for a product of equivalent type with actual consistency and reliability.

I’ve been looking at the LIFX and Philips Hue lights now.

Philips Hue uses Zigbee and is compatible with Z2M if you don’t want to use their hub. But they put the processor and flyback transformer in a separate box to the downlight. While that’s a great idea, the box they’ve designed has too much height which stops it from fitting in shallow ceilings (like the ground floor of a 2-storey house). I wish they had made that box longer instead.

LIFX uses WIFI which means it loses the ability to connect instantly like Zigbee can. I’ve heard they can have connectivity issues, but I’ve found that there’s no problem with quality APs that can handle enough connections. Definitely check that. If you have a lot of downlights, then the basic ISP routers might not cut it.

In both cases, the processor looks easily replaceable which would allow me to add my own, and support my own features. e.g. the Zigbee standard defines an execute while off command that sounds like it will solve a lot of ZigBee lighting issues. But I’m yet to find a light that has it implemented. Hue didn’t implement it either, but also didn’t seem to need it. I can’t remember.

3A Nue downlights (9W).
When the MoveToLevelWithOnOff (0x04) command from the Level Control (0x0008) cluster is used, the lights stop executing the more basic commands until they are power cycled. Such as On (0x01) and Off (0x00) from the On/Off cluser (0x0006), MoveToColor (0x07) from the ColorControl (0x0300) cluster, etc.
The 3A Nue lights respond to the coordinator with a success acknowledgement, but the lights don’t physically change.

Since they will still respond to commands like MoveToLevelWithOnOff (0x04) when in this broken state, you can partially get around the issue by setting a transition time in your zigbee messages (easier to set Z2M to always do it) . This will stop the coordinator from using the basic On (0x01) and Off (0x00) commands since they don’t support the transition time parameter, and will instead make it use the other commands. But that won’t solve the MoveToColor (0x07) problem.

You could make an automation to power cycle the lights when they get stuck but I’m not sure how. It seems excessive to use an illumination sensor and colour sensor to check that the lights aren’t lying with their responses to the coordinator.

I did all this testing and just handed the data to the manufacturer, But all they did was blame Home Assistant, the Philips Hue Hub and the TubesZB Coordinator. If the lights are acknowledging the commands with a success message but not following them, then the problem is definitely the lights.

The other issues seem mostly unsolvable without replacing the lights.
They put >300V on a 2mm pitch connector. I can’t measure the creepage, but it’s not much.
I’m fairly certain the memory code is badly written and cases write corruption since the lights stop remembering their state after several months of use.
Out of 40 lights, 2 just completely stopped lighting up the LEDs. Their radios were sometimes still connected, but there was no light.

Has anyone tried to implement their custom device handler? I’m not even sure where I would go modify the properties in the system?

Are you talking about the Z2M converter?

Thanks, yeah I’ve got over 160 of these and don’t mind starting with small rooms 2 or 4 at a time to replace them but I want to be 600% sure whatever I go with is going to work without fail. I have about a footin my ceiling and lots of Unifi AP’s. It’s reliability and consistency that I’m in trouble with the wife about!

Not sure I understand what this is I’m afraid…