midea-lan/midea-local

While reviewing midealocal/devices/ed/, I found a few pieces of code that look unreachable in production, and want a second opinion before touching them — some may be intentional test seams or placeholders for future subtype support rather than cruft. 1. _use_new_set() / MessageOldSet midealocal/devices/ed/__init__.py:171-173: def _use_new_set(self) -> bool: # if (self.sub_type > 342 or self.sub_type == 340) else False return True This is hardcoded to always return True, and no subclass overrides it. That means the else branch in set_attribute() (midealocal/devices/ed/__init__.py:418-419) that builds a MessageOldSet can never run on a real device, and by extension MessageOldSet itself (midealocal/devices/ed/message.py:504-521, whose body is always an empty bytearray([])) never gets used in production. The only place this branch executes is tests/devices/ed/device_ed_test.py:884-895, which mocks the private _use_new_set method (patch.object(self.device, "_use_new_set", return_

FD contains _detect_modes / detect_modes logic copied from the FC implementation, but it is never wired into the FD device attributes. As a result, the parsed mode information is currently unused. It is unclear whether this is incomplete functionality that should be exposed through the FD attributes or dead code that should be removed. We need to verify the intended FD behavior and decide whether the mode detection logic should be wired into DeviceAttributes or removed.

CAExceptionMessageBody defines around 25 error-flag attributes, but they all currently read the same bitmask: body[3] & 0x04. These attributes are also not wired into DeviceAttributes, so they are currently inert and have no observable effect. Correcting the bitmasks would require determining the actual bit positions for each error flag. Without firmware documentation or hardware/protocol data, assigning different bits would be speculative. We need to verify the CA exception message layout using reliable protocol or hardware data before changing the bitmasks or exposing these attributes through DeviceAttributes.

X34 parses a start field, but the value is never wired into DeviceAttributes, making it unreachable through the public device attributes. The field does have dedicated unit tests, so it is unclear whether this is an incomplete implementation or intentionally retained parsing logic. We need to verify the intended behavior for the start field and decide whether it should be exposed through DeviceAttributes or removed along with its dedicated tests.

FDA0MessageBody.tank and .mode both derive their values from body[10], unlike the C8 variant, which uses separate bytes for these fields. The existing test also explicitly derives both fields from the same byte value, suggesting this may be intentional firmware encoding rather than an implementation bug. We need to verify the FD firmware message layout and confirm whether sharing body[10] for both tank and mode is intentional. If confirmed, document the behavior and keep the existing implementation and test unchanged.