LX470 vs. Land Cruiser
The smartest architecture here is:
One HVAC control module family with two lower-panel fitment variants, not two separate products.
Same electronics, same firmware, same behavior, only the lower cassette-area fitment changes.
LX470 oriented w/ display
Code:
┌──────────────────────────────────────┐
│ STATUS STRIP │
│ 72° FAN 3 AUTO/VENT │
│ │
│ ( TEMP ) ( FAN ) │
│ │
│ [A/C] [AUTO] [MODE] [DEF] [RECIRC] │
└──────────────────────────────────────┘
Land Cruiser oriented w/ display
Code:
┌──────────────────────────────────┐
│ slim status strip │
│ │
│ ( TEMP ) ( FAN ) │
│ │
│ [A/C] [AUTO] [MODE] [DEF] [REC] │
└──────────────────────────────────┘
Triple Rotary w/ display (Doable, but much more sensitive to cassette-area dimensions)
Code:
┌──────────────────────────────────┐
│ slim status strip │
│ │
│ (TEMP) (MODE) (FAN) │
│ │
│ [A/C] [AUTO] [DEF] [RECIRC] │
└──────────────────────────────────┘
Path A - 2 Rotary
- Temp rotary
- Fan rotary
- Mode via pushbutton (cycled with indicators)
Easiest to package across both models
Cleanest firmware behavior
Path B - 3 Rotary
- Temp rotary
- Fan rotary
- Dedicated mode rotary
More traditional HVAC feel
Much tighter packaging
Adds system complexity
No Display - Simplest Implementation
Firmware only needs to:
- Read inputs
- Maintain state
- Transmit MPX behavior
- Drive LEDs
No rendering
No UI refresh
No display timing
Lowest complexity
Most robust
Constraint:
State must be communicated via:
Small Display - Adds Capability (and Scope)
Adds:
- Display driver
- UI update loop
- State-to-visual mapping
- Brightness / startup handling
Once present, expectations increase:
- Temp readout
- Fan level
- Mode indication
- System status
The display must stay fully synchronized at all times.
2-Rotary, No Display
- Simplest firmware
- Lowest validation effort
- Easiest packaging
Constraint:
- Requires strong LED/UI design
2-Rotary, Small Display
- Low input complexity
- Clear system feedback
- Avoids 3rd rotary sync issues
3-Rotary, Small Display
Constraint:
- Higher firmware complexity
- Larger validation scope
- Tight packaging
- More startup/state edge cases
2-rotary is simpler from a system perspective, and remains the cleanest and most robust direction BUT I’m not avoiding complexity.
If the community strongly prefers a true 3-rotary layout, I’m willing to take that on, I just want to make sure it’s what people actually want before committing to it.
