Skip to content

Latest commit

 

History

History
153 lines (112 loc) · 7.24 KB

H5080.md

File metadata and controls

153 lines (112 loc) · 7.24 KB

H5080 - Bluetooth/Wifi Smart Plug

Contributors


reydanro

Implemented Packets

  • Read state
  • Change state
  • Firmware version
  • Hardware version
  • Update timer settings
  • Update auto-on
  • Update auto-off

Check the Products/H5080 folder for a set of example scripts to get you started communicating with the device.

Communication protocol

Packets exchanged between a client and the smart plug devicce follow a command/response protocol.

The device exposes 2 characteristics, one to write data and one to listen for responses.

Type UUID Description
Characteristic 00010203-0405-0607-0809-0a0b0c0d2b11 Send commands
Characteristic 00010203-0405-0607-0809-0a0b0c0d2b10 Receive responses

The UUIDs seem to be constant across multiple devices but you can also infer these after establishing the bluetooth connection by inspect the list of characteristics and their individual properties:

  • The send characteristic will expose [read, write-without-response] properties
  • The receive characteristic will expose [read, notify] properties

The device can also send a response packet without an explicit command, for example if it changes its on/off state when the user presses the physical button.

How packets work

All packets are 20 bytes long and follow this structure

IDENTIFIER  PAYLOAD[] CHECKSUM
   2 bytes   17bytes   1byte

The CHECKSUM byte is the result of an XOR operation of other 19 bytes in that packet.

If PAYLOAD has less than 17 bytes of useful information the the rest of bytes will be padded with 0

Here is an example of a packet: aa07 03312e30322e3030000000000000000000 9d

  • aa07 is the identifier
  • 03312e30322e3030000000000000000000 is the payload. This happens to translate into the firmware version string 1.02.00, but other payloads could be just plain numbers and not ascii strings.
  • 9d is the checksum XOR

Authentication

Before sending any commands that are intended to change the state of the device you need to send an authentication packet (33B2). This makes the device accept commands for that specific connection.

The authentication key is a constant string unique to each device. It does not seem to be generated from any other data so we can assume it's a random value assigned during manufacturing. The key seems to be persisted for that specific device so you should store it for future use.

Obtaining the authentication key

To obtain the authentication key for a device you must go through a pairing process with the device. You send 33B2 packets in a loop and inspect its response. In parallel, you should instruct the user to press the physical button on the smart plug. Once a user presses the button, the next response message will dontain the correct authentication key:

  1. Connect the BT client to the device
  2. Start listening for notifications on the receive characteristic
  3. Send a AAB1 packet (see below) and wait for the AAB1 response to arrive. You should also instruct the user to press the physical
  4. Inspect the response payload
  • If the first byte of payload is 0x00 - this means the rest of the payload is some randomly generated number and shouldn’t be used. Instruct the user to press the physical button on the device.
  • If the first byte of the payload is 0x01 - this means the rest of the payload is the correct authentication key and should be extracted and stored for future use. The device will send this response when the user presses the physical button on the device during this pairing process.
  • Repeat steps 3 and 4 until the user presses the physical button on the devices.

On/Off state

You can inspect the state of the smart plug in 2 ways:

  • Connection-less
    • This is a far cheaper way to obtain the state as it does not rely on you setting up an actual bluetooth connection
    • The device will send the current on/off state as part of the advertisement data
  • Connection-based
    • Once you establish a connection, the device will stop broadcasting its advertisement data so in order to read the latest state you will need to use the command/response protocol to check this.

Connection-less From the advertisement data, inspect the manufacturer data field. The last byte in that data array will be a boolean flag describing the current state (0x00 for off, 0x01 for on).

Connection-based Send an AA01 packet and wait for an AA01 response. The first byte in the payload will be a boolean flag with the current state.

Packets

Get device on/off state (AA01)

Send: aa01 0000000000000000000000000000000000 ab
Recv: aa01 0100000000000000000000000000000000 aa (if on)
      aa01 0000000000000000000000000000000000 ab (if off)

Get device firmware version (AA06, AA20, AA21)

There seem to be multiple packet identifiers that return the firmware version. Not sure what their purpose is, maybe it's some backwards compatibility thing

Send: aa06 0000000000000000000000000000000000 ac
Recv: aa06 312e30302e323100000000000000000000 9e
            1 . 0 0 . 2 1

Get device hardware version (AA07)

Send: aa07 0300000000000000000000000000000000 ae
Recv: aa07 03312e30322e3030000000000000000000 9d
              1 . 0 2 . 0 0

Get authentication key (AAB1)

Send: aab1 0000000000000000000000000000000000 1b
Recv: 
      aab1 00 687ea542cc1d267e0000000000000000 63 (invalid key)
      aab1 01 0db6be06253334300000000000000000    (valid key)

To determine if the response has a valid or invalid key you must inspect the first byte of the payload. If it's 0x01 then the response has a valid key.

The authentication key will be in the payload and starts with the second byte in the payload. In the example above, 0db6be06253334300000000000000000 is the valid key.

Authentication current connection (33B2)

Send: 33b2 0db6be0625333430000000000000000000 97
Recv: 33b2 0000000000000000000000000000000000 81 (if key is correct)

The send message contains the authentication key in the payload section. If the key is less than the expected size of payload (17 bytes) then you should pad it with 0x00 at the end.

If the authentication key is incorrect, there will be no response received from the device.

Set the on/off state (3301)

Turn On
Send: 3301 ff00000000000000000000000000000000 cd
Recv: 3301 0000000000000000000000000000000000 32

Turn Off
Send: 3301 f000000000000000000000000000000000 c2
Recv: 3301 0000000000000000000000000000000000 32

You must go throuogh the authentication flow before you send any of these on/off messages. Otherwise, you will not receive a response if you send a 3301 message.

Other messages

There is more functionality of H5080 device that hasn't been mapped yet. The device is capable of maintaining its own schedule to turn on or off and it's able to have auto-on and auto-off features after a timer expires. There are probably more messages to read and write this configuration, as well as possibly synchronizing the time so that the schedule could be applied.