Discrepancies in protobuf from latest Tesla One APK as of 6/14/2026

[Nexarian]

Hi @Matthew1471,

Thanks for all your help with pypowerwall. In turn, I wanted to help your work along. I have been running the Tesla One APK (v26.10.1) through Claude Opus 4.8 to verify the protobuf definitions, and I asked it to compare its analysis with your protobuf work here. It gave me some feedback to relay to you:

📨 To report to him — where he differs from 26.10.1 (APK-verified):

• CommonAPIGetSystemInfoResponse field numbers are off. He has system_update=4, device_type=5. 26.10.1 has no field 4, systemUpdate=5, deviceType=6, then complianceInformation=7, installedFirmwareSignature=8, offlineFirmwareSignature=9. (Verified in the bundle: uint32(42)=field 5 msg, uint32(48)=field 6 varint.)
• Two typos: firmare_version → firmware_version; qualifiying_time_remaining_s → qualifying_time_remaining_s (GridComplianceStatus).
  UpdateStatus is missing two values present in 26.10.1: UPDATE_STATUS_COMMITTING=5, UPDATE_STATUS_CHECKING=6.
• MessageEnvelope divergence (version/source): 26.10.1's payload is {common=4, energysitenet=10, authorization=12, filestore=15, graphql=16, supercharger=17} with reserved 7 and no teg/wc/neuriometer. His TEG API (TEGMessages, TEGAPI*, BackupEvent, ManualBackupEvent) has zero ts-proto defs in the 26.10.1 consumer bundle.
• 26.10.1 adds a large surface he lacks (FYI, newer, not errors): the GraphQL signed-query API, Supercharger*, EnergySiteNet*, FileStore*, LocalAuth*, Tcpdump/Register/RetrieveSite, ProxiedDevice, plus fields like NetworkInterface.deviceState/deviceStateReason, Participant.proxiedDevice, SystemUpdate.isSideloading.