The acurite_txr_decode function that handles Atlas, 5n1, and 3n1 weather stations, TXR temperature/humidity, 6045 lightning, 515 refrigerator/freezer and1190/1192 water sensors, and 899 rain gauge has been refactored. Changes: * Refactor 5n1, 3n1, 515, 899 decoders into separate decoding function * The shared callback function should be easier to understand and add new devices * Fix: valid messages with checksum == 0 were being rejected * This was due to a bad check for an extra byte being added by demodulators * Test case `-y 3863187dbbc6f3d87bff` * Fix: Invalid short messages could be accepted resulting in bad data if last byte of message resulted in a valid checksum * Test case 9 byte Atlas message that should be rejected `-y 'f8 63 99 fc 7b af 3f 5f'` * See also PR #2116 * Improve rejection of invalid messages * Use message type, rather than message length as the primary identifier * Validate minimum message length by specific message type * Accept messages with one or more extra bytes (demodulator can add extra bits) * but only use correct number of bytes for the specific message type. * Add parity check to MIC for all devices except the 3n1 weather station * Parity was previously only being checked correctly for the tower and leak detector * (The 3n1's g001 sample in rtl_433_tests has odd parity on the 2nd to last byte of both message copies. It seems unlikely both repeats would have the same problem. However the g002 sample does use even parity on all bytes. * Note: the samples for the 899 range gauge do not have enough data to verify parity is used on the whole message. Need testing from someone with this device. * Reject messages if certain fields such as temperature, humidity, wind direction, and other fields have invalid values (such as humidity > 100). This helps when the MIC passes, but there is invalid data in the message. * Previously some sanity checks for humidity and temperature were added to a few devices like the tower sensor. Most devices now have humidity validated at a minimum.
