feat: Implemented time response for cloudless time synchronization

[davidrapan]

SSIA;

Fixes #81

I think that this could be appropriate solution but what do you think guys?

😉

[jmccrohan]

Partial ACK/NAK on this.

serial was poor parameter name choice, but for compatibility reasons, I think it needs to stay.

v5_loggerserial stay as such because it refers to the logger serial number as opposed to that of the inverter (I've had issued raised on how do I enter inverter serial numbers with letters...)

v5_serial... yeah, I've no idea what I was thinking with that variable name. v5_seq or v5_seqno makes a lot more sense.

[jmccrohan]

For clarity, it would be easier if we stuck with either the existing definition of a two byte control code, or else redefine that into two, new, single byte fields. We refer to 0x4510 in some places, and now we are refering to just 0x45. Same with 0x3000 vs 0x30.

[davidrapan]

You reviewed outdated code.

[davidrapan]

But yes, I'm all for separating those bytes cause handling it that way (using int) is way easier.

[davidrapan]

serial was poor parameter name choice, but for compatibility reasons, I think it needs to stay.

What compatibility? It's not exposed anywhere. They are together with self.v5_loggerserial which is byte representation of self.serial and self.v5_serial representation of self.sequence_number. This inconsistency is way worse imo (not even mentioning how it drives my OCD nuts 😆) than any incompatibility (which I don't even think there is any given the fact that both are just inner/not exposed attributes).

v5_loggerserial stay as such because it refers to the logger serial number as opposed to that of the inverter (I've had issued raised on how do I enter inverter serial numbers with letters...)

I would totally agree /w this point if it was reflected here too

def __init__(self, address, serial, **kwargs):

But when I was going trough the code cause of building of that v5 header and so I was like wait what?

But you are the boss at the end so...