Protocol exploration (2)

Post date: Nov 9, 2019 8:19:07 PM

After a lot of capturing traffic, restarting the PowerChute service again and again, toggling the settings and comparing with the reported values, I was able to identify a lot of the message IDs:

• 0x00: Header with protocol info (16 bytes)
  • byte 0: unknown (always 0A on the units I checked, maybe protocol version?)
  • byte 1: msg size (always 16?)
  • byte 2: available IDs (always 127?)
• 0x40: Serial number (14 bytes)
• 0x41: UPS type name (part 1)
• 0x42: UPS type name (part 2)
• 0x43: UPS SKU (part 1)
• 0x44: UPS SKU (part 2)
• 0x45: Firmware version (part 1)
• 0x46: Firmware version (part 2)
• 0x47: Battery lifetime configuration (bytes 2 and 3)
• 0x48: Battery replacement SKU
• 0x49: UPS name
• 0x4b
  • Apparent power (bytes 0 and 1)
  • Real power (bytes 2 and 3)
• 0x4d: Outlet name
• 0x4e: Audible alarm setting (unclear yet)
• 0x6d: Battery related
  • Battery voltage (bytes 0 and 1)
  • Battery SOC (bytes 2 and 3)
  • Runtime (bytes 14 and 15)
• 0x6f
  • Temperature (bytes 0 and 1)
  • Voltage (bytes 6 and 7)
  • Current (bytes 8 and 9)
  • Frequency (bytes 10 and 11)
  • Apparent power used (bytes 12 and 13)
  • Real power used (bytes 14 and 15)
• 0x72: Outlet status (bytes 0 and 1)
• 0x7e: Part of challenge (to)
• 0x7f: Part of challenge (from)

As you can see from the last 2 IDs, I assume some kind of challenge is calculated by the host PC, then sent to the UPS as 'write' to message ID 0x7e, after which the UPS sends an updated 0x7f.

If there is no write-message from the PC, the UPS will simply stop responding. If there is, the UPS enters another state (lets call them MODE0 and MODE1) and only loops over a subset of the IDs infinitely.

Since a simple replay of the captured write message does not work, I figure that the written data to 0x7e is calculated from the data previously sent to the PC. However, only a few messages are actually different.