v2.7.8 release

[crankyoldgit]

v2.7.8 (20200622)

[BREAKING CHANGES]

• Fix Manchester code handling; Increase Airwell to 34 bits. ([BREAKING BUG] Fix Manchester code handling; Increase Airwell to 34 bits. #1200)

[Bug Fixes]

• Carrier40: Use correct gap value. ([BUG] Carrier40: Use correct gap value. #1193)

[Features]

• CarrierAc64: Add detailed support. (CarrierAc64: Add detailed support. #1133)
• Add experimental support for Hitachi A/C 344 bit protocol (Add experimental support for Hitachi A/C 344 bit protocol #1139)
• Automatic & full library code/API documentation via Doxygen (Add Doxygen automatic documentation config for the library. #1150 Doxygen-ify IRac.cpp #1154 Doxygen-ify the IRtimer files. #1155 Doxify more protocol files. #1156 Doxygen-ify the protocols beginning with 'C' #1158 Doxygen-ate all the protocols beginning with D #1165 EF'ing more doxygenation #1167 G'eee! More doxygen updates. #1169 H'ow many more protocols are left to doxy? #1180 I Just Keep Loving doxygening protocols. #1184 MMmmmmm, More Making Marvellous Method Manuals #1189 Needlessly Procedural Repetitious Doxification #1191 SsssSufferin’ ssssuccotash! Doxygen'ed again! #1194 Total Vexation With Doxygen! #1195 Misc doxygen fixes. #1197 Add an overview/intro for the Library API #1198)
• Hitachi344: Add detailed support and change bit ordering. (Hitachi344: Add detailed support and change bit ordering. #1147)
• Add Corona AC Protocol (Add Corona AC Protocol #1152)
• Hitachi344: Add Swing(H) and improve Swing(V) (Hitachi344: Add Swing(H) and improve Swing(V) #1148)
• Update auto_analyse_raw_data.py with better code comment sections (Update auto_analyse_raw_data.py with better code comment sections #1164)
• Add support for Midea24 protocol. (Add experimental support for Midea's NEC-like protocol. #1171)
• Add basic Zepeal protocol support (Add basic Zepeal protocol support #1178)

[Misc]

• scrape_supported_devices.py: avoid changes to SupportedProtocols.md (scrape_supported_devices.py: avoid changes to SupportedProtocols.md #1140)
• auto_analyze nice exit on empty rawdata input (auto_analyze nice exit on empty rawdata input #1141)
• Comments update + cleanup (Comments update + cleanup #1143)
• Update D_STR_IRRECVDUMP_STARTUP text and comments. (Update D_STR_IRRECVDUMP_STARTUP text. #1144)
• Minor code cleanups (Minor code cleanups #1149)
• Update README.md's to point to new API docs. (Update README.md's to point to new API docs. #1151)
• Update "Supports" sections (Remove legacy "compatible with" sections #1160)
• Add a doxygen check to CI/Travis. (Add a doxygen check to CI/Travis. #1161)
• scrape_supported_devices: warn about misplaced or legacy supports sections (scrape_supported_devices warn about misplaced or legacy supports sections #1159)
• Add Supports sections to some files (Add Supports sections to some files #1163 Add Supports sections to more files #1166)
• Fix compile error when DEBUG is enabled.
• Add no-output option and return code on error to scrape_supported_devices
• Travis: Add scrape_supported_devices error check
• Update auto_analyse_raw_data.py to have a default Supports: section
• Treat compiler warnings as errors. (Treat compiler warnings as errors. #1174)
• Remove calcLGChecksum() and use new generic sumNibbles() (Remove calcLGChecksum() and use new generic sumNibbles() #1175)
• Suppress more potential compiler warnings. (Suppress more potential compiler warnings. #1179)
• Load balance travis tasks to reduce wall clock time. (Load balance travis tasks to reduce wall clock time. #1183)
• Set PlatformIO's default baudrate to 115200 (Set PlatformIO's default baudrate to 115200 #1188)
• Some fixes to Doshisha protocol handler
• Minor cleanups of Corona and Zepeal
• Enable Doxygen warning when the parameters for a function/method/procedure are wrong/missing. (Enable more Doxygen warnings #1196)

[crankyoldgit]

@NiKiZe Hopefully, this will be the worst release PR to review (if you even need to) as it includes ALL the updated doxygen stuff we've both done for the past few weeks.
There are no code changes in this PR, just followed the wiki "new version checklist" (which I updated along the way)

[NiKiZe]

Should Hitachi344 be marked as breaking as well?

[crankyoldgit]

Should Hitachi344 be marked as breaking as well?

I thought about it, but it isn't "breaking" from 2.7.7. it wasn't included in that release.

[s-hadinger]

Great job. I updated Tasmota accordingly. The code impact is +5.2kb.

Do you have any idea that could shrink back the code size a little? We still have headroom but we may eventually need to specialize some version with only a fraction of the protocols.

[crankyoldgit]

Great job. I updated Tasmota accordingly. The code impact is +5.2kb.

@s-hadinger Thanks for the data point and the feedback. The code size impact is in-line with what I'd expect given the additions. i.e. ~2K per detail protocol, ~0.5K per detail-less protocol.

Do you have any idea that could shrink back the code size a little? We still have headroom but we may eventually need to specialize some version with only a fraction of the protocols.

There are some very small code (space) optimisation that are left, but I can't see them saving more than a couple of K total.
Each time we add an AirCon it going to increase by 1-2K (and we've got another waiting to be merged already)

From a Tasmota perspective, I think you need to assume this library will grow similarly every month or so if you include every protocol.
My guess(es) are the .toString() methods are something you might be able to ditch if you can avoid them.
Any use of these will cause significant code increase too:

IRremoteESP8266/src/IRac.h

Lines 405 to 410 in 576e71b

	/// Common functions for use with all A/Cs supported by the IRac class.
	namespace IRAcUtils {
	String resultAcToString(const decode_results * const results);
	bool decodeToState(const decode_results *decode, stdAc::state_t *result,
	const stdAc::state_t *prev = NULL);
	} // namespace IRAcUtils

The IRac common A/C api is probably the bulk of the bloat from your perspective. Maybe have a tasmota version with all IR protocols but no IRhvac support at all, and then have a version with just the IRhvac ones and maybe the base level ones included in the standard tasmota build?

Maybe also have a "send only" version? The decode parts for each protocol are the largest/most complex etc.

If you or anyone else has suggestions on how to save significant space (e.g. 1-2K at a time), I'm all ears.

[s-hadinger]

Indeed, having a "send only" version would be a nice alternative, especially for HVAC protocols. However I have already heard users that wanted to capture IR interactions too.

I didn't spot any obvious area where to reduce code size. Maybe there is code factorization possible.

For ex: IRAcUtils::decodeToState() could be a candidate. If all classes inherited from the same base class, you could leave only constructors in the switch/case, and have only one final ac.setRaw(decode->state); *result = ac.toCommon();. I understand there are some exceptions as some need ac.setRaw(decode->value); instead. This could save some Flash size.

[crankyoldgit]

Indeed, having a "send only" version would be a nice alternative, especially for HVAC protocols. However I have already heard users that wanted to capture IR interactions too.

This is just my $0.02/personal opinion. Most people don't need to detect/decode in-bound IR A/C messages. I'd figure most people just want to control their A/C. Some might want to use an IR remote to control something. i.e. press button on remote, have tasmota generate a MQTT message and turn on/off the fan/kettle/lamp etc.
They'd probably do that with something like NEC etc.

So, I'd give them the base tasmota decode IR protocols + send-only for all other protocols. i.e. they can still capture raw etc.
removing all the AC decodes will save some space, but not a massive amount.

Perhaps having two "full" versions. Both with all "simple" protocol send/decodes etc, and each having A-M & N-Z "detailed" A/C protocols respectively?

I didn't spot any obvious area where to reduce code size. Maybe there is code factorization possible.

Yeah, I'm running out of obvious savings. :-(

IRAcUtils::decodeToState()

I think the amount of coding to try to reduce the space used by decodeToState() would just be transferred to each A/C class. Thus no nett gain. That said, I sorely want to make that & the to String variant simpler if I can. :-/

[s-hadinger]

Thanks, good insights. We still have some headroom for now. Indeed if we need to shrink code, having a send-only HVAC version makes sense.