W100 zigbee firmware inconsistencies

Aqara Products
, , ,
1

Hi

The W100 could be a great product but it has some issues that need to be solved with the Zigbee firmware update asap.

  • in thermostat mode, the W100 allows 0.5° steps. But the zigbee endpoint handling the PMTSD frame containing this value only send and receive plain integer value. This is a big issue that need to be adressed on a firmware update.
  • we should be able to set the thermostat mode precision. My HVAC here use 0.1° precision, I’d like to be able to use 0.1° steps from the W100
  • there’s no calibration feature exposed calibrate for Temperature and Humidity sensor. I see 0.8° difference between my lab calibrated temperature sensor and the W100. Any T°/Hum sensor needs a way to be calibrated as they will drift over time. Most cheap zigbee sensors on the market have this as it’s mandatory.

Are the moderators here forwarding issues and features request to aqara development team ?
I’ve tried to contact technical support, but they don’t even understand what I’m talking about…

12 Likes
2

Hello, welcome to the forum. These settings are in W100. Sensitivity can be set from 0.2 °C, polling period (external display 0.5 seconds, data exchange period with the gateway 10 seconds. I made a description of these settings in this topic.
W100 Explanation of the temperature sampling setting для то

Note, the W100 is a thermometer, not a thermostat. It can be used as a remote control and monitor for the W500, W600 and E1.

6 Likes
3

I know it’s not a thermostat, but it can be used to control a thermostat.
I shouldn’t have to explain that :slight_smile:
That’s what I mean , the w100 in zigbee firmware has 2 modes, normal mode and thermostat mode.
In thermostat mode, it then display the middle line with HVAC info ( heat/cool/… and Fan mode ) , then the hardware buttons are only used for thermostat mode ( no more zigbee Actions ) .
When pushing the up/down button, it then increase/lower by 0.5° step the virtual thermostat setpoint. And then send the value using a PMTSD frame like this:

YYYY-MM-DD HH:mm:ss_Px_Mx_Tx_Sx_Dx

Tx is the temperature setpoint sent, and it’s always only a float value.
( If the w100 is set to 19.5 °C, it then only send on the PMTSD T19 instead of T19.5.

And same on the other side, if the thermostat ( the real one ) send T19.5, W100 will only get 19° and skip the float.

This has nothing to do with calibration.
The zigbee firmware should have an endpoint to set an offset to the temperature and humidity value.
There’s no other way to do it.

1 Like
4

We can’t correct our post, strange thinbg.
I meant “and it’s always only a INTEGER value.”

1 Like
5

Hello, now I understand what you asked.
Regarding 0.5 °C, Aqara currently operates only with these settings (unfortunately).
Regarding the thermostat mode, I cannot say for sure that the temperature is set without being tied to an external thermostat (I have not checked this). I will do some research when I get home.
At one time, we raised a whole topic on the issue of a virtual thermostat so that temperatures can be set directly in automation from W100

2 Likes
6

The site’s policy is for new users, over time these restrictions are removed.

3 Likes
7

I use it already with an external thermostat. I had to reverse how it work internally first. That’s how I’ve found this flaw.

The most important problem here, is the W100 sending only integer values instead of float. We can live with just a 0.5° precision, but this integer vs float issue is really troublesome.

Also the calibration in any good T°/Hum sensor have a way to set an offset, it’s a mandatory feature or the device will be good for trashbin after few monthes when it drifted too much to be acceptable.
All sensors on the market drifts over time, + factory calibration is not always good.

4 Likes
8

It really could be great if this could be fixed

1 Like
9

I’m adding a bit of technical info of what has been learnt from this device to document the issue:

The Aqara W100 uses a proprietary Lumi cluster (cluster ID: 64704 or 0xFCD0, called manuSpecificLumi) to communicate specific data that isn’t covered by standard Zigbee clusters. All thermostat mode logic and the PMTSD protocol are handled through this cluster.

The key attribute: 65522 (0xFFF2)

All thermostat mode communication goes through attribute 65522 (0xFFF2) of the manuSpecificLumi cluster. This attribute carries binary data (type 65 or 0x41) containing frames encoded according to various Aqara protocols.

1. Thermostat Mode Activation/Deactivation

Activation (thermostat_mode = ON)

Frame sent to attribute 65522:
aa 71 32 44 [random] [random] 02 41 2f 68 91 [random] [random] 18 
[device_MAC_8_bytes] 00 00 [hub_MAC_6_bytes] 08 00 08 44 15 0a 01 09 
e7 a9 ba e8 b0 83 e5 8a 9f 00 00 00 00 00 01 01 2a 40

Key components:

  • Header: aa 71 32 44 - Protocol identifier
  • Device MAC: 8 bytes representing the W100’s IEEE address
  • Hub MAC: 6 bytes (hardcoded: 54ef4480711a)
  • Signature: 08 00 08 44 - Marks the start of the encrypted payload
  • Encrypted payload: Contains Chinese characters and activation commands

Effect:

  • The middle line on the display becomes visible
  • Buttons send encrypted payloads instead of action events
  • The device enters “thermostat control” mode

Deactivation (thermostat_mode = OFF)

Frame sent to attribute 65522:
aa 71 1c 44 [random] [checksum] 04 41 19 68 91 [random] [random] 18 
[device_MAC_8_bytes] [padding_to_34_bytes]

Key components:

  • Different header: aa 71 1c 44 - Deactivation protocol
  • Shorter frame: Only 34 bytes total (vs ~60 for activation)
  • Device MAC: Required to target the specific device

Effect:

  • Middle line disappears from the display
  • Buttons return to sending standard action events (single, double, hold)
  • Exits thermostat mode

2. PMTSD Protocol - Thermostat Control Communication

PMTSD stands for the 5 parameters controlled: Power, Mode, Temperature, Speed, D(unknown/unused)

PMTSD Request from Device (08 00 08 44 sequence)

The W100 periodically sends a request via attribute 65522:

[variable_header] 08 00 08 44

The sequence 08 00 08 44 is the signature that indicates: “I’m requesting the current PMTSD state”

Converter response: When this signature is detected, Z2M must respond with the current PMTSD state.

PMTSD Frame Format (Z2M → W100)

When Z2M needs to send thermostat settings to the W100:

Frame structure sent to attribute 65522:
aa 71 1f 44 [counter] [checksum] 05 41 1c 00 00 
54 ef 44 80 71 1a 08 00 08 44 [length] [ASCII_PMTSD_string]

Key components:

  • Header: aa 71 1f 44 - PMTSD protocol identifier
  • Counter: Random byte (position 4)
  • Checksum: Sum of all bytes & 0xFF (position 5)
  • Hub signature: 54 ef 44 80 71 1a - Hardcoded hub identifier
  • PMTSD marker: 08 00 08 44 - Indicates PMTSD payload follows
  • Length: Single byte indicating the ASCII string length
  • ASCII payload: Example: P0_M1_T22_S0_D0

PMTSD Parameters Explained:

Parameter Name Values Description
P Power 0 = ON, 1 = OFF Controls whether the HVAC system is on or off
M Mode 0 = cool, 1 = heat, 2 = auto HVAC operating mode
T Temperature 5-30 (configurable range) Target temperature setpoint in °C
S Speed/Fan 0 = auto, 1 = low, 2 = medium, 3 = high Fan speed setting
D Unused 0 or 1 Unknown parameter (possibly wind direction or another feature)

Example: P0_M1_T22_S0_D0 means:

  • Power ON
  • Heat mode
  • Target temperature 22°C
  • Fan speed Auto
  • D parameter = 0

PMTSD Response from Device (W100 → Z2M)

When the user manually changes settings on the W100 display, it sends the new values:

[variable_header] 08 44 [length] [ASCII_PMTSD_string]

The Big issue is the inconsistencie of the device screen allowing to set 0.5° precision as temperature setpoint. But the protocol implemented only handle plain integer values.

A simple firmware update could solve this easily.

1 Like
10

Hi, thank you for the detailed description of the offer.
Hi @XianTangHE, please take this offer into consideration, thank you.

2 Likes
11

Thanks both @KipK76 to work on this.

@XianTangHE : can you update us please?

Setting the setpoint to 24.5 °C and reporting it as 24 seems awkward in 2025.

Device is generally slowly responding to key presses anyway.

We really hope getting a much better and improved firmware. When can we expect it?

Thank you!

3 Likes
12

hi, any input @XianTangHE ?

13

Hi
Thx for @KipK76 job !
It will be great to get an update to solve problems.

@XianTangHE : any news about a release date ?

Thx

14

Hi
I would like this change also
@XianTangHE: any new updates?

Thanks

15

But does that mean you have to press it ten times to raise it by 1 degree?

16

But does that mean you have to press it ten times to raise it by one degree?

17

Hi @XianTangHE
The precision to 0.1° on thermostat mode is not the main subject. I agree it make too much press and is not necessary.
Let’s only focus on the main problem here the PMTSD protocol only sending integer temperature setpoint while the screen allows to set 0.5° step.

And the other important point is the missing zigbee endpoint to calibrate the temperature sensor. ( set an offset )

Thanks

2 Likes
18

I’d love these features as well. I would buy 10 of these (W100) throughout my house, each room would have one as I have IR panels in each room, but the actual switching of the electricity is done in my electricity box using Shellys.

Agree with Kip on both features:

  • 0.5° is fine, even though I like to dial it in even more, e.g. 23.7°,
  • calibration would be great as then I can put it on an outside wall that is colder in the living room and on the warmer inner walls by the door in bedrooms and have them display the true temperature.
1 Like
19

@XianTangHE , please give a look to this post

That’s the main problem.

20

Hahah my wife always adjusts the temperature up or down by 0.5. I’ll tell her it’s a placebo

1 Like