Added support for Eglo Totari-Z 380 light.

[tommials]

Device information

https://www.eglo.com/de/deckenleuchte-totari-z-900001.html

Home Assistant Device information

Checklist

• I have created a single PR per device. When you have multiple submissions please create separate PR's.
• For lights - I have only included the gzipped files (*.gz), not the raw CSV files.
• For lights - I have provided a CSV file per supported color mode. Look that up in Developer Tools -> States

Additional info

[github-actions]

Thank you for submitting light measurements!
Here are some visualizations for the CSV files.

[bramstroker]

Thanks for your first contribution!
Measurements are looking great, no outliers and very consistent.

Could you please share the device info from the Device page in Home Assistant. To be found on the top left.
We can make sure auto discovery of this profile will work correctly.

[tommials]

Thanks for your first contribution! Measurements are looking great, no outliers and very consistent.

Could you please share the device info from the Device page in Home Assistant. To be found on the top left. We can make sure auto discovery of this profile will work correctly.

Hello! I didn't share it on purpose because this Totari-Z 380 shows up as "LED light with color temperature (33955) by AwoX" (#4075) even though they are totally different lights as you can see from the measurements. And I'm pretty confident that the bigger version (Totari-Z 530) shows up also as "LED light with color temperature (33955) by AwoX"

[bramstroker]

@tommials Ah I see. We also need to change the already submitted profile, as it would otherwise cause to be discovered for users under AwoX 33955 and cause wrong estimations.
Or is that other submitted light actually correct and indeed the AwoX 33955?

Which integration are you using to integrate this light? Is it a matter light?

[tommials]

@bramstroker The other submitted light is correct and is AwoX 33955, but the Totari-Z show up as AwoX 33955.

I'm using Z2M. It's a zigbee light. Should this issue be fixed at Z2M? Though I'm not sure if it's possible to do so..

[bramstroker]

Yes, pretty sure this must be fixed in Zigbee2Mqtt.
I don't use Zigbee myself (only have Zwave and Hue) and don't have any deep knowledge about the Zigbee libraries and project.
Maybe this resource helps? https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html.
Could you have a look?

I think it misinterprets the lights because there are no definitions / converters for it defined yet in Zigbee2Mqtt database.

[bramstroker]

I assume definition must be added here:
https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/src/devices/eglo.ts

[tommials]

I"ll have a look, thank you!

[tommials]

@bramstroker Hi, I'm now pretty sure this isn't possible, unfornately. There are atleast four different lights displayed as AwoX 33955 (https://www.zigbee2mqtt.io/devices/33955.html) Here is the list:

EGLO 900316

• which has max power of 23 watts
• https://www.eglo.com/nl/plafondarmaturen-paranday-z-900316.html
• https://www.zigbee2mqtt.io/supported-devices/#v=EGLO&s=900316 and it opens up the AwoX 33955 device page

EGLO 900317

• which has max power of 35 watts
• https://www.eglo.com/nl/plafondarmaturen-paranday-z-900317.html
• https://www.zigbee2mqtt.io/supported-devices/#v=EGLO&s=900317 this opens up the AwoX 33955 device page

EGLO 900053

• which has max power of 37 watts
• https://www.eglo.com/nl/plafondarmaturen-salobrena-z-900053.html
• https://www.zigbee2mqtt.io/supported-devices/#v=EGLO&s=900053 this opens up the AwoX 33955 device page

EGLO 900084

• My Totari-Z
• which has max power of 24 watts (according to EGLO, but it has a 21,7 watt driver)
• https://www.eglo.com/nl/plafondarmaturen-totari-z-900084.html
• I have't done white label correction PR so this isn't shown in the Z2M AwoX 33955 device's white label section

There is similar problem with the Fueva-Z, according to PR #3575 it displays as https://www.zigbee2mqtt.io/devices/33957.html which is a bulb and it has bulb power, like 10 watts max but the Fueva-Z (this particular Fueva-Z, there are many other sizes also) has power of +20 watts.

So, what are we going to do now?

[bramstroker]

Hmm yeah, I see what’s happening.

The current device definition lives here:
https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/src/devices/awox.ts#L296-L318

Those EGLO models are defined as whiteLabel, which typically means they are functionally identical to the AwoX 33955 and share the exact same Zigbee fingerprint.
When that’s the case, Zigbee2MQTT has no way to distinguish between the different SKU’s at runtime, so it will always resolve to the “base” definition (AwoX 33955).

For Zigbee control this is perfectly fine, but I agree it’s not ideal from a UX perspective, because in Home Assistant (and thus also in Powercalc) the device shows up as AwoX instead of EGLO.

There are basically two possible directions to improve this:

1. Fix it upstream in zigbee-herdsman-converters (preferred)

Check if there is any distinguishing information between the devices, for example:

• different manufacturerName
• different modelID
• slightly different endpoints / clusters
• anything else in the fingerprint

If such a difference exists, the EGLO models could get their own fingerprint + definition, which would make them correctly identifiable.

If the fingerprint is truly identical, then separate definitions won’t reliably work, because Z2M cannot know which SKU it actually is.

2. Work around it in Powercalc

If we cannot distinguish them on Zigbee level, we can handle it on our side by adding:

• AwoX as an alias under the EGLO manufacturer
• model 33955 to the EGLO profiles

That would result in Powercalc finding multiple matching profiles for AwoX 33955 and letting the user choose the correct one during setup.

Not perfect, but at least it gives the user control and avoids incorrect auto-selection.

[tommials]

I triend viewing the fingerprint, if I did it correctly they are identical.. Can we do the alias method?

[bramstroker]

Yes then the only option is to add an alias. Could you go forward and add this?

[bramstroker]

@tommials could you resolve conflicts on library.json please? Cannot merge currently because of conflicts in this file.

For future PR's. You never have to edit library.json file that is auto generated by a Github action.

[tommials]

@bramstroker I have no idea how that file has changed... I didn't edit it or atleast I didn't mean to do so.
I pressed some buttons on my forked repo and replaced the file with current from original repo. How about now?

[bramstroker]

@bramstroker I have no idea how that file has changed... I didn't edit it or atleast I didn't mean to do so. I pressed some buttons on my forked repo and replaced the file with current from original repo. How about now?

Other contributor also had this issue. I'm pretty sure it was caused because you also used master branch, and that triggers a github action which updates the library.json.
Have probably fixed that yesterday: 3dfec89.
But will only work on next PR.

There are still conflicts. I will try fixing it with copilot. I see that's a listed option. never tried that before.

[bramstroker]

@copilot resolve the merge conflicts in this pull request