Update candeo.ts

[dhc25]

Adding Candeo C-ZB-SM205-2G

[dhc25]

@Koenkk Can you please help with this lint formatting error again please? Still can't see what we're getting wrong here...
Thanks

[Koenkk]

Why are these reads needed?

[dhc25]

Hi @Koenkk - to give the user a better out-of-the-box experience, and ensuring that the states of the device are accurately presented straight away.

[Koenkk]

But how are these values exposes? Because I see no corresponding expose and fromZigbee converter.

[dhc25]

Sorry, we're not really sure what specifically you're asking.
You're referring to lines 187-192, correct? These are for OnOff cluster attributes for fz.on_off and fz.power_on_behavior.
Maybe we're not understanding the question...?

Can you please give us more info if there's a better way to do this, or if we've added something that looks incorrect to you?

[Koenkk]

I cleaned the code a bit, can you check if everything is still OK?

[dhc25]

Thanks for taking a look at this.

A problem we have is that a converter using modern extend does not offer powerOnBehaviour correctly for multi endpoint devices.

Initial view of your changes - it looks like -

1. Power on behaviour isn't configurable on each endpoint with modernExtend
2. State aren't pre-populated
3. The electrical measurement and metering clusters are on endpoint 11
4. Reporting cannot be customised to report more frequently when there is no activity.

[Koenkk]

1. This is supported now:

   zigbee-herdsman-converters/src/lib/modernExtend.ts

   Line 482 in a554f6b

   exposes.push(...exposeEndpoints(e.power_on_behavior(['off', 'on', 'toggle', 'previous']), args.endpointNames));

2. It should do that here:

   zigbee-herdsman-converters/src/lib/modernExtend.ts

   Line 126 in a554f6b

   await endpoint.read(

   , could you provide the debug log when configuring the device?
3. What problems do you experience with this?
4. It is possible to change it, but we want to standardise the reporting interval for all devices as much as possible. If for any specific use case you want to have more specific reporting, you can change that via the z2m frontend.

[dhc25]

1. Ok great - we can't replicate your suggestion in what we're currently using. (Home Assistant add-on, 1.40.2, zigbee-herdsman-converters version 20.21.0)

2. Again, as above we can't replicate that. Is this also something that has been fixed in the latest updates, and yet to be rolled out?

3. The electrical measurement is on endpoint 11, which has been removed in your edits

4. We would like to pre-set the reporting values for our devices, as it seems that 65000 seconds is too long. Although we know customers can change this themselves, our approach is to set the device up in pairing as best we can, so the customer does not have to edit the reporting settings.

Would it be possible to go with the code we have written? We have tested this and we are happy that it works with our device, providing the features that the device supports.

If the updates to modernExtend in the next rollout fix issues 1 and 2 on this list, we will edit the code to use modernExtend instead.

Thanks

[Koenkk]

1. You need to use the dev branch or wait for the 1 November release
2. Should be OK in 1.40.2, could you provide the debug log when configuring the device?
3. Does anything break because of this?
4. 65000 is the max reporting interval, if the value changes it should immediately report the change, is this not the case?

[dhc25]

Thanks.

We don't have a dev branch setup, so can't test your responses to 1, 2, 3 of our observations.

4. Yes - reporting is immediate if the value changes, but we want a shorter reporting time if the value does not change. Why is not possible?

As per my previous message, is there a good reason that we cannot go ahead with our tested and working code?

And then we can modify the code once we've tested on the 1 November release.

[Koenkk]

We don't have a dev branch setup, so can't test your responses to 1, 2, 3 of our observations.

Switching to the dev branch is documented here: https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html, does that help?

Yes - reporting is immediate if the value changes, but we want a shorter reporting time if the value does not change. Why is not possible?

If the value doesn't change, why do you want to have it reported again?
By using standard values we provide a consistent experience for all devices, that's why I'm pushing for the default values.

[dhc25]

Thanks.

I understand, but 18 hours is a long time, and we would prefer a more regular reporting.

I am not able to switch to dev branch on my current set up.

I go back to my earlier question - is there a good reason that we cannot go ahead with our tested and working code? Is it simply because you want more slimline code?

We will slim it down after the November release if everything works as you're saying... Is that ok?

[Koenkk]

We will slim it down after the November release if everything works as you're saying... Is that ok?

Ok then let's do that! Could you update the PR again?

[dhc25]

Thank you for this. We will be sure to look at again after the next roll out.

Sorry - I don't think I've done this correctly. Please forgive the newbie approach to Github.
I've opened another PR that needs conflicts resolving