Invert blocked status check in EelinkProtocolDecoder

[DemonExposer]

Status bytes sometimes get interpreted incorrectly because of bit 6 (for blocked status) being processed incorrectly. In decodeNew, it is not the same as in decodeStatus. I assume this was done because of the change in firmware documentation by Eelink.

I know they describe it weird, which could lead you to believe that they flipped the functionality, but this is not the case. They kept it the same.

I tested this with some devices where some packets show blocked = true and some show blocked = false. The change that I made fixes this to always show the correct status.

[tananaev]

Please attach the supporting documents.

[DemonExposer]

I'm not going to share a copyrighted document without having any authorization to do so.
I will tell you that in the 1.9.0 firmware, it states for bit 6 == 0: "cut off oil and power" and for bit 6 == 1: "restore oil and power". decodeStatus conforms to this.

For the newer firmware versions, such as 2.1, it states for bit 6 == 0: "The relay control is not triggered" and for bit 6 == 1: "The relay control is triggered"

I feel like the newer description is very ambiguous, but I don't see a reason for them to switch it around. Also, according to my tests, they didn't.

However, in decodeNew, it is switched around.

[tananaev]

Sorry, but we won't be able to accept it without documentation. At the very least you have to share it privately for verification.