LaCrosse TX, invalid humidity value

[rstephan]

I have a LaCrosse TX compatible temperature/humidity sensor which sometimes report -- for the humidity on the base station.
The raw value in this case is 0x0FF. Due to the fact, that there is no additional check, the BCD decoder gives me 16.5 for the false value.
What about two and a half extra lines of code to make it nicer?

-- snip --
  uint16_t msg_value_raw   = (msg_nybbles[5] << 8) | (msg_nybbles[6] << 4) | msg_nybbles[7];
-- snip --
    "humidity",         "Humidity",     DATA_COND, msg_value_raw != 0xff, DATA_FORMAT, "%.1f %%", DATA_DOUBLE, msg_value,
    "humidity",         "Humidity",     DATA_COND, msg_value_raw == 0xff, DATA_STRING, "invalid",
-- snip --

[zuckschwerdt]

Yes, that is good (just the != 0xff line). Do you want to PR the change?

[rct]

@rstephan - when you get these invalid humidity values, are you getting sane/valid temperature values that are worth keeping?

For some other sensors (Acurite and Ambient Weather) we've wound up dropping messages when temperature or humidity is invalid. The messages are usually corrupt, but the managed to pass the MIC checks, because the checks (often 8 bit checksum) isn't that robust.

These additional sanity checks have helped helps eliminate bad data that throws off graphs and aggregations (daily high/low).

[rstephan]

@zuckschwerdt Sure, I will do a PR. Give me a day or two to test my changes.

@rct The invalid value is "stable". Over long periods of time the frame is constant with the 0x0FF value. The integrity check passes every time, but yes it is just a sum of nibbles. The error occurred sometimes with very high humidity.
And my sensor transmits the temperature and humidity in two separate frames, so no direct relation between the values.

[gdt]

@rstephan How is your PR doing?

[rstephan]

The PR was merges ~8 month ago.
#2335

Ups, left the issue open, sorry.