Draft patch to support Hometronic Manager HCM200d controller, HCC80R manifolds and HCW82 thermostats.

[Ian-Pratt]

Honeywell Hometronic Manager HCM200d, HCC80R manifold controller, HCW82 thermostats
These devices uses the same Ramses II protocol, but required a number of changes:

• header type 1a is used frequently , which includes two device IDs and a sequence number.
• the HCM200d sends multiple commands in the same radio message, separated by an ff00 sequence. Loop over each command.
• the first nibble of the 55:5f:f0:04 preamble is frequently corrupted in otherwise perfect packets, so search for a 26bit preamble instead of 30.
• some devices (e.g. Jasper EIR) consistently send packets with the checksum summing to 1 instead of 0.
• added decode support for a handful of extra commands. However, several of the commands involve the controller sending information about multiple zones in the same message e.g. one message sends a temperature reading for every configured zone, another sends a setpoint for every configured zone. Following the format of the existing output format, I've added a further 15 entries of the form "temp (zone X)" and the same for setpoints and flags, but this may not be the preferred way of doing things, please advise.

[Ian-Pratt]

As per the comment, the original PR was really intended just to record what I'd done rather than a serious request for merging.
I've now had a chance to clean up the patch and I think its ready to review.
I'm afraid I couldn't figure out how to squash my local commit history, sorry.

[gdt]

We can deal with squashing, but if you want to learn it's git rebase -i.

[zuckschwerdt]

there is stray whitespace at the end

[zuckschwerdt]

This looks mostly ok, but the keys should be fixed strings and the naming ("temp_low (zone 0)") with spaces and parens is not allowed.
Also this is excessively many keys and will frustrate CSV users.

[Ian-Pratt]

This looks mostly ok, but the keys should be fixed strings and the naming ("temp_low (zone 0)") with spaces and parens is not allowed. Also this is excessively many keys and will frustrate CSV users.

The current upstream code uses the "temperature (zone X)" convention (see line 237) I've just followed the same convention when adding support for other messages. I agree it's not pretty. [note the upstream code does not register the messages.]

TBH, I'm not sure decoding the "flags (zone X)", "temp_low (zone X)", "temp_high (zone X)" messages are particularly useful for any real world applications (at least they're not for mine), so I could just put support for those messages behind a #ifdef to save some of the CSV columns. Current temperature and setpoint messages are definitely needed.

However, doing anything useful with the data coming out of these Honeywell systems requires a fair bit of additional code to map the temp sensors, manifold zones and controller zones and then provide useful output about the status and configuration of each zone, heat demand etc, so I'd be surprised if anyone was using CSV.
As an example, here's what I use to process the JSON: https://github.com/Ian-Pratt/house-monitor/blob/master/evo-parse.py

LMK what you want and I'll adjust.