Added support for Argo WREM-3 A/C remote protocol [part1]

[mbronk]

Adds support for ARGO WREM-3 remote

For: #1912

This PR is a standalone part1 of changes detached from: #1913

[crankyoldgit]

Again, thanks for the massive effort. I understand what it's like.

Thanks for splitting it up too.

[crankyoldgit]

Divide by 8 much earlier to get the bytes. And do the comparisons via that. That will reduce the resultant code size, and improve readablity. e.g. statelength.

[crankyoldgit]

Also, this really is a "strict" condition IMHO.

[mbronk]

That will reduce the resultant code size, and improve readablity. e.g. statelength.

Good point - will simplify (agree with the readability part of the comment).
Must add though, that I'd be very surprised it does anything positive to the resulting code size.
Compiler should be perfectly capable of optimizing it on its own.

---

Also, this really is a "strict" condition IMHO.

Well, yes and no.
That is, it is about the only thing separating WREM2 from WREM3 (and WREM3 detection must run before WREM2 non-strict, as it is a swallow-all).
While there's indeed a getMessageType() doing the detect, it only takes 2 bits of input, so a chance of a false-positive is way high. Aka. I consider "checksum" strict check, but anything else... I deliberately wanted to fall through to WREM2 and not get handled here.

That said, I only use the detect in strict mode anyway, so the point I'm making above is a bit moot and I could equally well remove 'strict' param entirely...
Leaving as-is for now, let me know where you'd like to take it.

[crankyoldgit]

My unwritten policy for strict is, if it is in some way protocol-format related and can cause it to abort decoding, encapsulate it in strict. The purpose is to allow more loose matching with strict set to false, and/or code re-use where the protocol timings etc are compatible, but the length or structure of the data differs in a different protocol.
i.e. Maximum potential for code-reuse to reduce library binary size etc.

[mbronk]

Please note though that WREM2 and WREM3 are variants (models) of the same ARGO IR protocol.
The difference is in message decoding and parsing, so in the case you describe:

... but the length or structure of the data differs in a different protocol....

...there's already a decodeArgo(..., strict=false) which would accomplish that result just fine.
The WREM3 flavor was meant signify this is semantically a different sub-proto.

If I make the length-check non-strict, then, arguably, decodeArgoWREM3(..., strict=false) would be almost no different from decodeArgo(..., strict=false)... which makes it a bit redundant IMHO (but arguably consistent)

My preferences (from most-preferred):

1. Leave as is (possibly less semantically consistent, but the most versatile impl.)
2. Remove strict param from decodeArgoWREM3 altogether
3. Make the length non-strict (it has a potential to clash with wrem2, but since I'm not calling it this way anyway... I guess the user would know what they're after).
   I.e. when you call it with strict=false a true response no longer means there's any confidence in it really being a WREM3.

Your pick? :)

[crankyoldgit]

Users typically can't call the decodeProtocol() routines directly. So, it's just us "internal" users.
Practically every decodeProtocol() has a strict, so I'd like to keep that calling convention.
Of the options, 3. sounds best to me. It is almost always a given if a decodeProtocol() is called with strict=false that it's not a confident match. It assumes the caller knows what they are doing.

[mbronk]

@crankyoldgit Thanks so much for reviewing! I know it wasn't a pleasant read, given the volume of changes in Argo class.

I think I addressed most of your comments in the new update. On a few comments that I left behind, I added replies or questions to you. Please take a look.
I'd also appreciate if you mark the conversations as resolved where you believe the changes address your comments, so that I know if there's anything withstanding. Where I did not comment, I merely incorporated the proposal as-is (hopefully didn't miss any).
For now I'm leaving it as-is and waiting for your inputs as to any follow-ups needed.
Thanks!

[crankyoldgit]

Looking a lot better. Just a couple of minor things left.

[mbronk]

Reverted the doc/doxy changes. Unfortunately, I wanted to do it (too) cleanly and rebased the whole thing, not to show the add + revert... which seems to have thrown github's incremental diff off :( Sorry for that!

Bottom line, as far as I can tell the only remaining comment from the original round would be the one about "strict" mode. Please take a look

[crankyoldgit]

Let me know when the strict changes are in as discussed, and I'm fine to approve & merge.

[mbronk]

Let me know when the strict changes are in as discussed

Just pushed. Please take a look.
Note I have pushed the lax logic into decodeArgoWREM3() (if not strict, bypasses call to isValidWrem3Message entirely).
Reason being: if I were to not make the length check in isValidWrem3Message, it becomes a return true.

[crankyoldgit]

Let me know when the strict changes are in as discussed

Just pushed. Please take a look. Note I have pushed the lax logic into decodeArgoWREM3() (if not strict, bypasses call to isValidWrem3Message entirely). Reason being: if I were to not make the length check in isValidWrem3Message, it becomes a return true.

Good. 'Cause that what I'd expect.

[crankyoldgit]

As discussed, LGTM