genTime: Respond with default value for daylight saving time-related fields

[DerDreschner]

The Bosch devices ask the coordinator for information about daylight saving time. Without any answer, the device still asks regularly, which drains the unncecessarily drains the battery. Therefore, I've added an appropriate fromZigbee converter for that case.

During testing for Koenkk/zigbee-herdsman-converters#10110, I realized that this solution doesn't work anymore in Z2M Edge as zigbee-herdsman doesn't forward the request to zigbee-herdsman-converters. To solve that, I've rewritten my solution to a customReadResponse. But @Koenkk made the suggestion to solve it here.

I'm not sure if my solution is okay, but I just answered the missing fields with their default value according to the Zigbee Cluster Library Specification, Revision 8:

Okay, the device doesn't shut up asking with the default value. It has to be 0x00.

[DerDreschner]

@Koenkk : Is there a reason for the dstEnd field being requested here, but not expected that to be there later on (expect(message.payload.length).toBe(3))?

[Nerivec]

The targeted code actually needs a review re #1503 since it appears to be writing attributes that are not actually writable. readRsp not write

About the dst attributes, they are optional. Could create friction with some devices that don't support them.
This code has to remain generic enough, as it is used by all devices that implement the cluster.

The time cluster appears to be calculating localTime internally (hence why it's readonly).
This is using the equation in 3.12.2.2.4, so, shouldn't dst fields be set to proper values so they calculate this correctly internally instead of just using time without shift (time is set to UTC, so localTime would remain UTC too)?

[Koenkk]

As discussed in Koenkk/zigbee-herdsman-converters#10110 (comment), the value that needs to be returned seems to be too specific, let's use the customReadResponse for this.

[DerDreschner]

As discussed in Koenkk/zigbee-herdsman-converters#10110 (comment), the value that needs to be returned seems to be too specific, let's use the customReadResponse for this.

That makes sense. 👍 About general support for daylight saving time in the future: What is your opinion about using third-party libraries, specifically https://github.com/SpiritIT/timezonecomplete for that? Just that I don't waste time. 😄

[Koenkk]

@DerDreschner it's a quite bulky dependency (1.85MB) (https://www.npmjs.com/package/timezonecomplete), so would not use it.

[Nerivec]

We probably should look into replacing the moment library from Z2M deps, it seems to be pretty much abandoned (2023), and it's very bulky for what we use it for (2 calls...):
https://github.com/moment/moment/commits/develop/
It has been in maintenance mode for quite some time (cf https://momentjs.com/docs/)

We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done.

This might be a good time to look for the features needed for this as well. There are some refs on moment website, but I haven't looked into what's the "most popular" successor.

[DerDreschner]

Yeah, I've considered moment-timezone first (timezone focused extension for moment), but it's in maintenance mode as well. Considering the combined size of moment and moment-timezone (4.35MB and 2.85MB), timezonecomplete looks pretty slick to me.

There are some refs on moment website, but I haven't looked into what's the "most popular" successor.

Yeah, I've checked the successors mentioned on their website. But 3 out of the 4 mentioned libraries (that's all I've checked so far, besides timezonecomplete) don't support use cases like "give me the moment of the next dst for that timezone", "does that timezone have a dst at all?", "what's the shift to utc not considering dst" etc. There's always something missing.

But these two calls could be done with timezonecomplete as well, so, maybe that is a possible solution?

[Nerivec]

I'm not very familiar with the time cluster or what's needed here, rarely used it, but we probably should look at a more established lib.
The underlying tz lib for date-fns maybe? Tiny lib.
We can add a few manual utils if needed (also have to look at the API directly, not the general docs, because the stuff we need is likely to be abstracted away for common use, but still available to call raw).
The stuff in Z2M is likely replaceable without even using a package at all.

[DerDreschner]

About the dst attributes, they are optional. Could create friction with some devices that don't support them.

Yeah, but as we only send the attributes that are requested (and therefore supported), this shouldn't be an issue in my opinion.

The targeted code actually needs a review re #1503 since it appears to be writing attributes that are not actually writable.
[...]
The time cluster appears to be calculating localTime internally (hence why it's readonly).

Both localTime and standardTime can be calculated by the device or the coordinator (as we're the time-master) according to revision 8 of the ZCL (pages 199 and 200). In case they calculate it internally, I would expect the device to not request these attributes at all. I've experienced both cases: some devices calculate it internally, some ask the coordinator.

Only lastSetTime is set automatically according to spec. But I don't know if that means "the device set it internally" or not. I don't have any devices that requested the lastSetTime, honestly.

Lets continue that discussion in #1517.