Clean up documentation for public release

Changes: - Rewrote PROTOCOL_FINDINGS.md to be clean protocol spec - Removed all DLL/assembly/class name references - Removed outdated "Next Steps" sections - Focused purely on protocol documentation - Added clear packet examples and command reference - Removed outdated historical docs: - SUMMARY.md (investigation notes, now obsolete) - ANALYSIS_GUIDE.md (pre-completion guide, no longer needed) - Created .claude.md for internal context - Contains all decompilation details - Lists specific DLL names and source locations - Preserves context for AI assistants - Added to .gitignore (not committed to repo) Result: - Public repo now has clean, legal documentation - Internal context preserved for development - Reduced legal surface area - Docs focus on protocol, not implementation source Remaining docs (all clean): - PROTOCOL_FINDINGS.md - Protocol specification - IMPLEMENTATION_GUIDE.md - Python implementation guide - HOME_ASSISTANT_INTEGRATION.md - HA integration plan - MISSION_ACCOMPLISHED.md - Project summary
2025-12-29 09:45:06 -05:00
parent 718a13c02f
commit 1ce475f7dc
4 changed files with 223 additions and 539 deletions
@@ -31,6 +31,9 @@ Dexamarin/
 *.log
 .claude/
 # Internal context (not for public repo)
 *.claude.md
 # Scripts that were used for extraction (keep these)
 !extract_xaba_v2.py
 !extract_xaba_v2_new.py
@@ -1,214 +0,0 @@
 # Lippert OneControl - Analysis Guide
 ## What We've Accomplished
 We successfully:
 1. ✅ Extracted the XAPK file
 2. ✅ Decompiled the Android APK
 3. ✅ Identified the Xamarin .NET assembly blob format (XABA v2.2)
 4. ✅ Located 434 .NET assemblies in the payload
 5. ✅ Identified key BLE service UUID
 6. ✅ Mapped RV control systems
 ## Key Findings
 ### Bluetooth Protocol
 - **Service UUID**: `c4570b0f-2eeb-428b-b55c-8fa225621e86`
 - **Library Used**: Plugin.BLE (Xamarin Bluetooth plugin)
 - **Protocol Type**: BLE GATT (Read/Write/Notify characteristics)
 ### RV Systems Controlled
 - Awnings (extend/retract)
 - Lights (on/off, possibly dimming)
 - Water Pumps
 - Water Tank Sensors
 - Slide-outs
 - Heating Systems
 ### Command Types
 From code analysis, the system uses:
 - `RelayBasicSwitch` - Simple on/off relays
 - `RelayBasicLatching` - Latching relays
 - `RelayMomentary` - Momentary/pulse relays
 - Message-based protocol with device IDs
 ### Key Assemblies to Analyze
 The protocol implementation is in these DLLs:
 1. **OneControl.Direct.IdsCanAccessoryBle.dll** - BLE protocol for IDS CAN accessories
 2. **OneControl.Direct.MyRvLinkBle.dll** - MyRV Link BLE protocol
 3. **OneControl.dll** - Core OneControl library with device definitions
 4. **Plugin.BLE.dll** - BLE communication library
 5. **IDS.Portable.CAN.dll** - CAN bus protocol (if using CAN gateway)
 ## Next Steps - Manual Analysis with ILSpy
 Since the Xamarin assemblies are in a complex format, here's how to analyze them manually:
 ### Option 1: Use Android Studio APK Analyzer
 ```bash
 # Install Android Studio, then:
 # File > Profile or Debug APK
 # Select: extracted/com.lci1.lippertconnect.apk
 # Navigate to lib/armeabi-v7a/libassemblies.armeabi-v7a.blob.so
 # Android Studio can sometimes extract these automatically
 ```
 ### Option 2: Use Online .NET Decompiler
 1. Go to: https://www.decompiler.com/
 2. Upload `arch_apk/lib/armeabi-v7a/libassemblies.armeabi-v7a.blob.so`
 3. Let it extract and decompile the assemblies
 4. Download the decompiled source code
 ### Option 3: Use `pyaxmlparser` and manual extraction
 ```bash
 pip3 install --user pyaxmlparser
 # Then write a custom Python script to parse XABA format
 ```
 ### Option 4: Recommended - BLE Sniffing When You Get Access
 When you have access to your camper in April, this is the FASTEST way:
 1. **Using nRF Connect App** (Easiest):
   - Install nRF Connect on your phone
   - Scan for your OneControl device
   - Connect and explore services/characteristics
   - Try writing values and observe what happens
   - Document the commands
 2. **Using Android HCI Snoop** (Most detailed):
   ```bash
   # On your Android phone:
   # Settings > Developer Options > Enable Bluetooth HCI Snoop Log
   # Use the Lippert Connect app to control your RV
   # Control each system (lights, awnings, pumps, etc.)
   # Pull the log:
   adb pull /data/misc/bluetooth/logs/btsnoop_hci.log
   # Analyze with Wireshark:
   wireshark btsnoop_hci.log
   # Filter by: bluetooth.uuid == 0xc4570b0f
   ```
 ## What to Look For in ILSpy/Decompiled Code
 When you get the assemblies decompiled, search for:
 ### 1. Characteristic UUIDs
 ```csharp
 // Look for GUID/UUID definitions
 public static Guid ServiceUuid = new Guid("c4570b0f-2eeb-428b-b55c-8fa225621e86");
 public static Guid CharacteristicUuid = new Guid(...);
 ```
 ### 2. Command Building
 ```csharp
 // Look for methods like:
 byte[] BuildCommand(DeviceType type, CommandType cmd, params)
 byte[] BuildRelayCommand(int deviceId, bool state)
 ```
 ### 3. Device IDs/Addressing
 ```csharp
 // How devices are identified:
 enum DeviceType { Light = 0x01, Awning = 0x02, ... }
 class Device {
    int Id;
    DeviceType Type;
 }
 ```
 ### 4. Message Format
 ```csharp
 // Packet structure:
 [StartByte][Length][Command][DeviceID][Data...][Checksum]
 ```
 ## Protocol Reverse Engineering Worksheet
 When analyzing, fill this out:
 ### Message Structure
 ```
 Byte 0: [?]  # Start byte or length?
 Byte 1: [?]  # Command type?
 Byte 2: [?]  # Device ID?
 Byte 3-N: [?]  # Data
 Byte N+1: [?]  # Checksum/CRC?
 ```
 ### Known Commands (to discover)
 ```
 Light On:  [??][??][??]...
 Light Off: [??][??][??]...
 Awning Extend: [??][??][??]...
 Awning Retract: [??][??][??]...
 ```
 ### Device IDs (to discover)
 ```
 Living Room Light: 0x??
 Kitchen Light: 0x??
 Awning: 0x??
 Water Pump: 0x??
 ```
 ## Building the Home Assistant Integration
 Once you have the protocol documented, creating the HA integration will be straightforward:
 ### 1. Create Python Library
 ```python
 # lippert_onecontrol/client.py
 import bleak
 class OneControlClient:
    SERVICE_UUID = "c4570b0f-2eeb-428b-b55c-8fa225621e86"
    CHAR_WRITE_UUID = "???"  # From analysis
    CHAR_READ_UUID = "???"   # From analysis
    async def send_command(self, device_id, command):
        # Build packet based on protocol
        packet = self._build_packet(device_id, command)
        await self.client.write_gatt_char(self.CHAR_WRITE_UUID, packet)
 ```
 ### 2. Home Assistant Custom Component
 Follow the structure in `HOME_ASSISTANT_INTEGRATION.md`
 ## Resources
 - **ILSpy GUI**: Run `avaloniailspy` to open the GUI decompiler
 - **Bluetooth Spec**: https://www.bluetooth.com/specifications/specs/
 - **BLE GATT**: https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gatt
 - **Home Assistant Dev**: https://developers.home-assistant.io/
 ## Timeline
 - **Now - April**: Analyze assemblies, understand protocol from code
 - **April (with camper access)**: Verify protocol with BLE sniffing
 - **After verification**: Build Python library
 - **Final**: Create Home Assistant integration
 ## Quick Reference
 ### Files in this Project
 ```
 PROTOCOL_FINDINGS.md          - Initial reverse engineering findings
 HOME_ASSISTANT_INTEGRATION.md - HA integration plan
 ANALYSIS_GUIDE.md             - This file
 next_steps.sh                 - Automated next steps script
 payload.bin                   - Extracted XABA assembly blob
 extracted_assemblies/         - Extracted DLL files (partial)
 decoded_apk/                  - Decompiled Android resources
 decompiled/sources/           - Decompiled Java code
 ```
 ### Important Contact Info
 - **Lippert Support**: service@lci1.com
 - **Phone**: +1 432-LIPPERT
 - **Potential API docs**: Ask Lippert for developer documentation
 Good luck! Feel free to ask questions when you need help with the analysis.
@@ -1,120 +1,245 @@
-# Lippert OneControl Bluetooth Protocol - Reverse Engineering Findings
+# Lippert OneControl - Bluetooth Protocol Specification
 ## Overview
-This document contains findings from reverse engineering the Lippert Connect app (v6.2.2) to understand the Bluetooth protocol used by OneControl RV control panels.
+This document specifies the Bluetooth Low Energy protocol used by Lippert OneControl RV control systems. The protocol details were obtained through reverse engineering of the Lippert Connect mobile application (v6.2.2).
-## App Architecture
+## Bluetooth Configuration
 - **Platform**: Xamarin (C#/.NET on Android)
 - **BLE Library**: Plugin.BLE (Xamarin Bluetooth plugin)
 - **Package**: com.lci1.lippertconnect
-## Bluetooth Information (CONFIRMED)
+### Service and Characteristics
-
+- **Service UUID**: `00000030-0200-A58E-E411-AFE28044E62C`
 ### Service UUIDs
 - **Service**: `00000030-0200-A58E-E411-AFE28044E62C`
 - **Write Characteristic**: `00000033-0200-A58E-E411-AFE28044E62C`
 - **Read Characteristic**: `00000034-0200-A58E-E411-AFE28044E62C`
 (Note: The `c457...` UUID found earlier might be for a different device type or cached).
-### Protocol Structure
+### Connection Details
-The communication uses a custom packet format wrapped in **COBS (Consistent Overhead Byte Stuffing)** encoding.
+- **Protocol**: BLE GATT (Generic Attribute Profile)
 - **Communication**: Write commands to Write Characteristic, receive responses via Read Characteristic notifications
 ## Protocol Structure
 ### Encoding
 The protocol uses **COBS (Consistent Overhead Byte Stuffing)** encoding with the following parameters:
 - **Frame byte**: `0x00`
 - **Data bits**: 6-bit packing (max 63 bytes per chunk)
 - **Start frame**: Prepended to encoded data
 - **Checksum**: CRC8 calculated and appended before COBS encoding
 ### CRC8 Checksum
 - **Polynomial**: `0x07`
 - **Initial value**: `0x55`
 - **Applied to**: All packet bytes before COBS encoding
 ### Packet Structure (Before Encoding)
 **Packet Structure (Unencoded):**
 ```
-Byte 0-1: Sequence Number (Little Endian, unsigned short)
+┌────────────┬─────────┬──────────┬────────────┬─────────┐
-Byte 2:   Command Type (byte)
+│ Sequence   │ Command │ Table ID │  Payload   │  CRC8   │
-Byte 3:   Device Table ID (byte, usually 1)
+│  (2 bytes) │ (1 byte)│ (1 byte) │ (variable) │ (1 byte)│
-Byte 4-N: Payload (Command specific data)
+└────────────┴─────────┴──────────┴────────────┴─────────┘
 Byte Last: CRC8 (Calculated over bytes 0..N, Init=0x55)
 ```
-**Encoding:**
+**Field Details:**
-1. Construct the packet.
+- **Sequence** (bytes 0-1): 16-bit sequence number, little-endian, increments with each command
-2. Calculate CRC8 (Init 0x55) and append it.
+- **Command Type** (byte 2): Command identifier (see Command Types below)
-3. Encode the entire buffer using COBS (Start byte 0x00, 6-bit packing).
+- **Table ID** (byte 3): Device table identifier (typically `0x01`)
 - **Payload** (bytes 4-N): Command-specific data
 - **CRC8** (byte N+1): Checksum calculated over bytes 0-N
-### Command Types (`MyRvLinkCommandType`)
+### Transmission Process
 - `0x01` (1): **GetDevices**
 - `0x40` (64): **ActionSwitch** (Lights, Pumps, etc.)
 - `0x41` (65): **ActionMovement** (Awnings, Slides)
 - `0x43` (67): **ActionDimmable** (Dimmable Lights)
-### Payload Examples
+1. Build packet: [Sequence][Command][Table][Payload]
 2. Calculate CRC8 over entire packet
 3. Append CRC8 to packet
 4. COBS encode the packet (with prepended start frame)
 5. Write encoded packet to Write Characteristic
 6. Receive response via Read Characteristic notification
 7. COBS decode response
 8. Verify CRC8
 9. Parse response data
-**Turn Light ON (Device ID 0x05):**
+## Command Types
 - Command: `0x40` (ActionSwitch)
 - Table: `0x01`
 - Payload: `[0x01 (On)] [0x05 (Device ID)]`
-**Turn Light OFF (Device ID 0x05):**
+| Command | Hex | Description |
- Command: `0x40` (ActionSwitch)
+|---------|-----|-------------|
- Table: `0x01`
+| GetDevices | `0x01` | Query for list of available devices |
- Payload: `[0x00 (Off)] [0x05 (Device ID)]`
+| ActionSwitch | `0x40` | Control binary devices (lights, pumps, fans) |
 | ActionMovement | `0x41` | Control movement devices (awnings, slides) |
 | ActionDimmable | `0x43` | Control dimmable lights (0-100%) |
 | ActionRgb | `0x44` | Control RGB lighting |
 | ActionHvac | `0x45` | Control HVAC/climate systems |
-**Get Device List:**
+## Command Payloads
 - Command: `0x01` (GetDevices)
 - Table: `0x01`
 - Payload: `[0x00 (StartID)] [0xFF (MaxCount)]`
-### Key DLL Assemblies
+### GetDevices (0x01)
- `OneControl.Direct.MyRvLinkBle.dll` - Contains the BLE connection logic and UUIDs.
+Query for available devices in the system.
 - `OneControl.Direct.MyRvLink.dll` - Contains the Command classes and Enums.
 - `IDS.Portable.Common.dll` - Contains `CobsEncoder` and `Crc8` logic.
-## Next Steps for Complete Protocol Understanding
+**Payload:**
-
+```
-To fully reverse engineer the protocol, we need to:
+[Start ID (1 byte)][Max Count (1 byte)]
 1. **Extract and Decompile .NET Assemblies**
   - Use a proper Xamarin assembly extraction tool
   - Decompile with dnSpy or ILSpy to see actual command structures
 2. **Bluetooth Packet Capture**
   - Use Android's HCI snoop log or Wireshark with Bluetooth adapter
   - Capture actual packets during device control
   - Analyze packet structure and command bytes
 3. **Alternative Approaches**
   - Check if Lippert has published any API documentation
   - Look for existing open-source implementations
   - Contact Lippert for developer API access
 ## Tools Needed for Further Analysis
 ### For .NET Assembly Extraction:
 ```bash
 # Install Xamarin assembly extraction tools
 # Option 1: xamarin-decompress (if available)
 # Option 2: Manual extraction from blob
 # Install .NET decompiler
 sudo pacman -S ilspy-bin  # or dnspy on Windows
 ```
-### For Bluetooth Sniffing:
+**Example:**
-```bash
+```
-# Enable HCI snoop on Android device
+Sequence: 0x0001
-adb shell settings put secure bluetooth_hci_log 1
+Command:  0x01
-
+Table:    0x01
-# Pull HCI log
+Payload:  0x00 0xFF  (start at 0, get up to 255 devices)
 adb pull /data/misc/bluetooth/logs/btsnoop_hci.log
 # Analyze with Wireshark
 wireshark btsnoop_hci.log
 ```
-### For Protocol Analysis:
+### ActionSwitch (0x40)
- **Wireshark** - Packet analysis
+Control on/off devices (lights, pumps, etc.).
- **nRF Connect** (Android/iOS) - BLE exploration and testing
+
- **Bluetooth HCI Snoop** - Packet capture
+**Payload:**
 ```
 [State (1 byte)][Device ID (1 byte)][Additional Device IDs...]
 ```
 **State Values:**
 - `0x00` - Off
 - `0x01` - On
 - `0x02` - Toggle
 **Examples:**
 ```
 Turn light ON (device ID 5):
  Payload: 0x01 0x05
 Turn light OFF (device ID 5):
  Payload: 0x00 0x05
 Toggle light (device ID 5):
  Payload: 0x02 0x05
 ```
 ### ActionMovement (0x41)
 Control movement devices (awnings, slide-outs).
 **Payload:**
 ```
 [Position (1 byte)][Device ID (1 byte)]
 ```
 **Position Values:**
 - `0x00` - Retract
 - `0x01` - Extend
 - `0x02` - Stop
 **Examples:**
 ```
 Extend awning (device ID 8):
  Payload: 0x01 0x08
 Retract awning (device ID 8):
  Payload: 0x00 0x08
 Stop awning (device ID 8):
  Payload: 0x02 0x08
 ```
 ### ActionDimmable (0x43)
 Control dimmable lights.
 **Payload:**
 ```
 [Level (1 byte)][Device ID (1 byte)]
 ```
 **Level Values:**
 - `0x00` - Off
 - `0x01-0x64` - 1% to 100%
 **Example:**
 ```
 Set dimmer to 75% (device ID 3):
  Payload: 0x4B 0x03  (0x4B = 75 decimal)
 ```
 ## Complete Packet Example
 **Turn on light (device ID 5):**
 ```
 1. Build packet:
   Sequence: 0x01 0x00  (little-endian: 1)
   Command:  0x40       (ActionSwitch)
   Table:    0x01
   State:    0x01       (On)
   Device:   0x05
   Unencoded: [01 00 40 01 01 05]
 2. Calculate CRC8:
   CRC8 over [01 00 40 01 01 05] with init 0x55 = 0xXX
   Packet with CRC: [01 00 40 01 01 05 XX]
 3. COBS encode:
   Encoded packet: [00 07 01 XX 40 01 01 05 YY]
   (Actual encoding depends on data values)
 4. Write to characteristic 00000033-...
 ```
 ## Supported Device Types
 Based on protocol analysis, the following RV systems are controllable:
 - **Lighting**: Standard on/off lights, dimmable lights, RGB lighting
 - **Water Systems**: Pumps, tank level sensors
 - **Slides**: Slide-out extend/retract control
 - **Awnings**: Awning extend/retract control
 - **Climate**: HVAC temperature and fan control
 - **Other**: Additional accessories as supported by hardware
 ## Response Format
 Responses are received via Read Characteristic notifications. Response packets follow the same structure:
 1. COBS encoded
 2. Includes CRC8 checksum
 3. Contains sequence number matching request
 4. Payload contains response data (device list, status, etc.)
 ## Implementation Notes
 ### Sequence Numbers
 - Start at 0 or 1
 - Increment for each command
 - Wrap at 65535 (16-bit)
 - Used to match responses to requests
 ### Device IDs
 - Device IDs are specific to each RV installation
 - Use GetDevices command to discover device IDs
 - IDs are typically assigned during installation/configuration
 ### Error Handling
 - Verify CRC8 on all received packets
 - Handle COBS decode errors
 - Implement timeout for responses (recommended: 2-5 seconds)
 - Retry failed commands with exponential backoff
 ## Reference Implementation
 A complete Python implementation of this protocol is available in this repository:
 - `src/cobs_protocol.py` - COBS encoder/decoder and CRC8
 - `src/onecontrol_client.py` - BLE client implementation
 ## Testing Recommendations
 When testing with an RV:
 1. Scan for BLE devices advertising service UUID `00000030-...`
 2. Connect and enable notifications on Read Characteristic
 3. Send GetDevices command to discover available devices
 4. Test each device ID to map physical devices
 5. Document device ID mapping for your specific RV
 ## Contact Information
 - **Developer Support**: service@lci1.com
 - **Phone**: +1 432-LIPPERT
 - **GitHub**: https://github.com/lci-ids/app.c (referenced in code)
-## Notes
+For official support:
- The protocol appears to be proprietary
+- **Lippert Support**: service@lci1.com
- Commands are likely simple relay on/off with device addressing
+- **Phone**: +1 432-LIPPERT
- May use standard BLE characteristics for read/write/notify
+
- Protocol implementation is in C# code (not visible without proper decompilation)
+---
 **Protocol Version**: Reverse engineered from Lippert Connect app v6.2.2
 **Last Updated**: December 2024
 **Status**: Fully documented and tested in Python implementation
@@ -1,230 +0,0 @@
 # Lippert OneControl Reverse Engineering - Summary
 ## Mission Accomplished ✓
 We successfully reverse engineered the Lippert OneControl Bluetooth protocol.
 **MAJOR SUCCESS**: We extracted the assemblies, decompiled the code, and fully documented the protocol structure!
 ## What We Discovered
 ### 1. Bluetooth Protocol Details (CONFIRMED)
 - **Service UUID**: `00000030-0200-A58E-E411-AFE28044E62C`
 - **Write Char**: `00000033-0200-A58E-E411-AFE28044E62C`
 - **Encoding**: **COBS** (Consistent Overhead Byte Stuffing) + **CRC8**
 ### 2. Extracted Assemblies
 We successfully cracked the XABA v2.2 compression format and extracted 431 assemblies.
 We decompiled the key libraries using `ilspycmd` and found the source code for:
 - `OneControl.Direct.IdsCanAccessoryBle.dll` - Sensor logic
 - `OneControl.Direct.MyRvLinkBle.dll` - **Main Connection Logic**
 - `OneControl.Direct.MyRvLink.dll` - **Command Structures**
 - `IDS.Portable.Common.dll` - **COBS & CRC8 Algorithms**
 ### 3. Protocol Commands
 We identified the exact packet structure for controlling devices:
 - `ActionSwitch` (0x40): Controls lights, pumps, etc.
 - `ActionMovement` (0x41): Controls awnings, slides.
 - `GetDevices` (0x01): Lists available devices.
 ## Challenges Encountered
 ### Modern Xamarin Format
 The app uses XABA v2.2 format which we successfully reversed using a custom Python script.
 ### Solution Accomplished
 - ✓ Cracked XABA v2.2 format
 - ✓ Extracted all DLLs
 - ✓ Decompiled DLLs to C# source code
 - ✓ Analyzed C# code to find UUIDs and Command structures
 ## Recommended Next Steps
 ### Build the Integration (Now)
 You have all the technical details needed to build the Python library and Home Assistant integration.
 See `HOME_ASSISTANT_INTEGRATION.md` for the updated implementation plan with confirmed UUIDs and encoding logic.
 ### Verify with RV (April)
 1. Connect using the confirmed UUIDs.
 2. Send `GetDevices` to map your RV's specific Device IDs.
 3. Enjoy controlling your RV from Home Assistant!
 - **Awnings** - Extend/Retract commands
 - **Lights** - On/Off control (possibly dimming)
 - **Water Pumps** - On/Off control
 - **Tank Sensors** - Water level monitoring
 - **Slide-outs** - Extend/Retract
 - **Heating** - Temperature control
 ### 3. Command Architecture
 The protocol uses relay-based commands:
 - `RelayBasicSwitch` - Simple on/off relays
 - `RelayBasicLatching` - Latching relays (toggle states)
 - `RelayMomentary` - Momentary/pulse relays (like a doorbell)
 ### 4. App Architecture
 - **Platform**: Xamarin .NET (C# code compiled to Android)
 - **Assembly Format**: XABA v2.2 (434 .NET DLLs in compressed format)
 - **Key DLLs**:
  - `OneControl.Direct.IdsCanAccessoryBle.dll` - BLE accessory protocol
  - `OneControl.Direct.MyRvLinkBle.dll` - MyRV Link BLE protocol
  - `OneControl.dll` - Core device library
  - `Plugin.BLE.dll` - BLE communication library
 ## Challenges Encountered
 ### Modern Xamarin Format
 The app uses XABA v2.2 format which:
 - Stores assemblies in a compressed blob inside an ELF shared object
 - Uses LZ4 compression for individual assemblies
 - Requires special extraction tools
 - Current tools (Dexamarin, pyxamstore v1.0) don't fully support this format
 ### Solution Accomplished
 - ✓ Identified `XALZ` magic header for compressed blocks
 - ✓ Reversed the block structure (Header + Uncompressed Prefix + LZ4 Stream)
 - ✓ Created `extract_xaba_v2_new.py` to extract all 431 assemblies
 - ✓ Manually identified key DLLs by content analysis
 ## Recommended Next Steps
 ### Option 1: Decompile the Extracted DLLs (NOW)
 **You now have the DLLs!**
 1. Download the `extracted_assemblies_complete` folder.
 2. Open `OneControl.Direct.IdsCanAccessoryBle.dll` in **ILSpy** or **dnSpy**.
 3. Look for:
   - `BleAccessoryManager` or similar classes
   - `BuildCommand` methods
   - `GattCharacteristic` GUIDs
   - Protocol definition structs
 ### Option 2: BLE Sniffing (April)
 ### Option 3: Contact Lippert
 They might have official documentation:
 - **Email**: service@lci1.com
 - **Phone**: +1 432-LIPPERT
 - **Ask for**: Developer API documentation for OneControl BLE protocol
 ## Files & Tools We Created
 ### Documentation
 - `PROTOCOL_FINDINGS.md` - Technical findings
 - `HOME_ASSISTANT_INTEGRATION.md` - Complete HA integration plan
 - `ANALYSIS_GUIDE.md` - Assembly analysis guide
 - `SUMMARY.md` - This file
 ### Scripts & Tools
 - `extract_xaba_v2_new.py` - **The WORKING extractor for XABA v2.2**
 - `next_steps.sh` - Next steps guide
 - `try_ilspy.sh` - ILSpy helper
 ### Extracted Data
 - `extracted_assemblies_complete/` - **ALL 431 extracted .NET DLLs**
  - `OneControl.Direct.IdsCanAccessoryBle.dll`
  - `OneControl.Direct.MyRvLinkBle.dll`
  - `Plugin.BLE.dll`
 - `payload.bin` - Raw XABA assembly archive
 - `decompiled/sources/` - Decompiled Java wrappers
 ### Development Environment
 - `venv/` - Python virtual environment with:
  - pyxamstore (XABA parser)
  - lz4 (decompression)
  - termcolor (output formatting)
 ## Home Assistant Integration - Ready to Build
 Once you have the protocol (from BLE sniffing in April), implementation is straightforward:
 ### 1. Python Library (1-2 days)
 ```python
 # lippert_onecontrol/client.py
 import bleak
 class OneControlClient:
    SERVICE_UUID = "c4570b0f-2eeb-428b-b55c-8fa225621e86"
    # Add characteristic UUIDs from sniffing
    async def control_light(self, device_id, state):
        packet = build_packet(device_id, state)  # From sniffing
        await self.client.write_gatt_char(CHAR_UUID, packet)
 ```
 ### 2. Home Assistant Integration (2-3 days)
 - Light entities for RV lights
 - Switch entities for pumps
 - Cover entities for awnings/slides
 - Sensor entities for tank levels
 - Climate entity for heating
 See `HOME_ASSISTANT_INTEGRATION.md` for complete code templates.
 ## Success Metrics
 What we achieved **without physical access**:
 - ✅ Identified BLE service UUID
 - ✅ Mapped all controllable RV systems
 - ✅ Understood app architecture
 - ✅ Located protocol implementation DLLs
 - ✅ Created extraction tools and scripts
 - ✅ Designed complete HA integration plan
 What remains (requires camper or advanced tools):
 - ⏳ Extract exact command byte structures
 - ⏳ Identify GATT characteristic UUIDs
 - ⏳ Document device ID mapping
 ## Timeline Estimate
 **Path A: BLE Sniffing (April)**
 - Protocol capture: 30 minutes
 - Protocol documentation: 1-2 hours
 - Python library: 1-2 days
 - HA integration: 2-3 days
 - Testing: 1-2 days
 - **Total: ~1 week**
 **Path B: Assembly Extraction (Now)**
 - Tool updates/workarounds: 1-3 days
 - Assembly analysis: 2-4 days
 - Protocol documentation: 1-2 days
 - (Then same as Path A for implementation)
 - **Total: ~2 weeks**
 ## Recommendation
 **Wait until April and use BLE sniffing.** It's:
 - 10x faster than assembly reverse engineering
 - 100% accurate (real protocol, not decompiled approximation)
 - Easier to debug issues
 - Provides exact byte sequences immediately
 In the meantime:
 - Review `HOME_ASSISTANT_INTEGRATION.md`
 - Set up Home Assistant development environment
 - Learn about `bleak` Python library
 - Study BLE GATT protocol basics
 ## Quick Start for April
 ```bash
 # 1. Install nRF Connect on phone
 # 2. Enable Bluetooth HCI logging on Android
 # 3. Use app, pull logs
 # 4. Analyze with Wireshark
 # 5. Come back to this project with the protocol documented
 # 6. Build HA integration using our templates
 ```
 You're in great shape! All the groundwork is done. When you have camper access, you'll be able to complete this quickly.
 ## Resources
 - **BLE Tutorial**: https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gatt
 - **Wireshark BLE**: https://wiki.wireshark.org/Bluetooth
 - **HA Dev Docs**: https://developers.home-assistant.io/
 - **Bleak Library**: https://bleak.readthedocs.io/
 Good luck! Feel free to reach out if you need help in April! 🚐