Windows stuck “up” and won’t respond to interior switches after latest OTA (until hard reset or cover trigger)

[EarlCrane]

Since the latest updates, I noticed a quirk where the windows will stay up and not respond to manual button pushes inside the car. A soft reset does not resolve it, but a hard reset or triggering from the windows cover will allow manual control of the windows.

I don't want to bring this up to Rivian since I love this integration and use it a LOT. (batter charging, home automation, maintenance, battery health, etc).

Has anyone else seen this issue?

(Chat GPT analysis below)

⸻

Windows stuck “up” and won’t respond to interior switches after latest OTA (until hard reset or cover trigger)

Integration: Rivian (Unofficial)
Integration version: 1.4.0
Python client: rivian-python-client[ble]==1.4.1
Home Assistant: 2025.8.3 (OS 16.1, Supervisor 2025.08.3)
Install type: Home Assistant OS (x86_64, Docker)
Timezone: America/Chicago
Vehicle: R1T Launch Edition (MY2022)
Vehicle OTA: 2025.26.01 (installed successfully today)

What’s happening

Since updating to 2025.26.01, I’m seeing a quirk where the windows stay up and won’t respond to the interior window switches.
• A soft reset (two-button hold) does not resolve it.
• A hard reset or triggering via the windows cover (i.e., issuing a window action from the app/integration) does restore manual control.

This repeats intermittently after the truck sits, or sometimes after charging.

Expected
• After any window action, manual window control from the interior switches should work normally without needing a hard reset or an external trigger.

Actual
• Manual window control is ignored, even though the integration reports windows are calibrated and action is allowed.

Timeline & relevant entries (from this morning)

OTA status/version (just before issue observed):

2025-08-29 13:22:43Z otaCurrentStatus = Install_Success
2025-08-29 13:22:43Z otaCurrentVersion = 2025.26.01

Windows report calibrated, but “next action” sticks:

2025-08-29 14:00:36Z windowFrontRightCalibrated = Calibrated
2025-08-29 14:00:36Z windowFrontLeftCalibrated = Calibrated
2025-08-29 14:00:36Z windowRearLeftCalibrated = Calibrated

2025-08-29 14:00:37Z windowsNextAction = Close_Allowed

history around this shows: Closing / Open_Allowed / Opening (then it remains at Close_Allowed)

Window closed-state flips, but manual switches still unresponsive:

2025-08-29 14:00:36Z windowFrontLeftClosed = open (history shows open/closed toggles)
2025-08-29 14:00:36Z windowRearLeftClosed = open (history shows open/closed toggles)

No obvious DTCs or faults reported for windows/hardware:

2025-08-29 14:06:05Z btmFfHardwareFailureStatus = dtc_not_set
2025-08-29 14:06:07Z btmLfdHardwareFailureStatus = dtc_not_set

(Battery and other subsystems look nominal; including just for context):

2025-08-29 14:06:38Z batteryCapacity.value ≈ 128.485001
2025-08-29 13:55:20Z chargerState = charging_active

Repro steps (what I did)
1. Vehicle on 2025.26.01 (confirmed Install_Success).
2. After charging / sitting, attempt to use interior window switches → no response.
3. Soft reset (two-button hold) → still no response.
4. Trigger a window action via cover/integration (or do a hard reset) → window switches work again.
5. Later, after another sit/charge period, it can recur.

Hypothesis

Right after the OTA, the windowsNextAction FSM/flag looks “stuck” at Close_Allowed even though windows are Calibrated and should accept manual inputs. A hard reset or an external window command seems to unstick the state and restore normal behavior.

What would help
• Confirmation if there was a change in how window action states are published post-2025.26.01.
• Whether the integration should “nudge” or re-query the window state machine after certain transitions (e.g., after charging completion / sleep).
• Any additional debug flags I can enable to capture the exact transition where windowsNextAction fails to return to a neutral state.

Additional environment details

Home Assistant: 2025.8.3
OS: Home Assistant OS 16.1 (Linux 6.12.41-haos) / Docker 28.3.3
Arch: x86_64 (amd64)
Integration: Rivian (Unofficial) 1.4.0
rivian-python-client[ble]: 1.4.1

Happy to run with debug logging and provide a narrower window of logs if you share the desired logger config. I rely on this integration a lot (charging automations, maintenance tracking, battery health), so I’d love to help pinpoint the regression. 🙏

⸻

rivian_windows_summary_2025-08-29.txt

[natekspencer]

I'm not really sure what the ask is here as it sounds like you are having vehicle issues, not integration issues, which we do not have control over. I would suggest that you raise a ticket with Rivian directly if you are still experiencing this.