Better to rid your device of Zigbee support if you are not going to open up the clusters and/or fix firmware to include tenths of degrees precision in a way that does not require the Aqara hub. This is also my last Aqara product, I am glad that I did not purchase a multitude of these devices at once to use as room thermostat interfaces for the house. Really weird for an occupant to see 20.5 on the display but seeing the heating setpoint set to 20 instead. Not worth the money, will also modify my review on Dutch Tweakers.net site to advice others that are into Home Automation to stay away from this product when not using the Aqara hub.
@peterChengg +30 days go by and no firmware?! ![]()
Yeah it’s incredibly stupid.
Will we get a firmware with the correction any time soon @peterChengg?
Finally the “glitch” with temp/humidty readings in HA seems resolved with latest fw (1641).
Has the 0.5-degree issue been resolved?
@AqaraOfficial I’ve had over 3782 fights with my wife because she increases the temperature by 0.5 degrees, I tell her not to bother because Aqara firmware is broken and the 0.5 increments are ignored, but she disagrees. Then it always ends in a fight!
Help me please.
@peterChengg I agree with the others. Aqara advertises Zigbee support and lists Home Assistant as a compatible platform — it’s even printed on the box. It doesn’t make sense that the device’s own screen already handles 0.5° steps (storing, displaying, and adjusting the setpoint), yet the Zigbee/PMTSD frame that reaches Home Assistant truncates this to an integer before it even leaves the device. That proves it’s not a hardware limitation — it’s how the protocol frame is implemented. Please fix this from Aqara’s side.
The PMTSD is designed to support infrared air conditioning units.
Our IR library follows the standard AC infrared protocols used across the industry, where the temperature field is a 4-bit integer (1°C resolution).
When PTMSD data is transmitted, it is converted into infrared codes to control the air conditioner.
In fact, the device supports more than just PTMSD. PTMSD is only used when the device is paired with an infrared air conditioner.
If you have a W200, you will find that linking the W100 to the W200 enables 0.5°C control.
If you are able to make the air conditioner appear as a W200 and link the device to the W100 from another location, then you will be able to achieve 0.5°C control.
Regarding the fact that PTMSD cannot control to 0.5°C: in reality, the W100 simply does not display 0.5°C control when using PTMSD. However, this involves very complex logic for the W100, as it actually supports control via a wide variety of thermostats.
@peterChengg Thanks for the explanation, but with respect, that answer doesn’t really solve the problem for most of us here.
The PTMSD frame is specifically the protocol used for IR air conditioners — which is exactly the use case almost everyone in this thread is complaining about. Telling us to instead buy a W200 and bind the W100 to it isn’t a fix for IR-AC users, it’s a workaround that only applies if you’re controlling a Zigbee thermostat/valve, which most of us aren’t.
The underlying issue remains: the field is a 4-bit integer by design choice, not a hardware constraint — the W100 itself already stores, displays and lets users set 0.5°C steps internally before that value gets truncated for the PTMSD frame. So the fix has to happen in firmware: either widen that field to support half-degree resolution for IR control, or add a manufacturer-specific attribute that exposes the untruncated setpoint for platforms like Home Assistant/Zigbee2MQTT to read and act on, even if the on-device IR translation itself stays whole-degree.
Is Aqara actually planning a firmware update along those lines, or is “buy a W200” the final answer for IR-AC users?
This is a very difficult modification because the PTMSD isn’t just used by the W100—it’s also transmitted to the app and to the cloud.
If we modify the W100, other endpoints will likely not recognize this data, so this would constitute a major change.
I can discuss with the project team to see if there are alternative ways to help you achieve this. For example, could we support additional attributes to report the mode and set temperature, which could then be provided to the home automation (HA) system for control?
However, I can only offer suggestions to explore these options; whether they are implemented will depend on the project team’s internal evaluation. Since this would constitute separate support for the HA system—and cannot be used within the Aqara system—I’m not certain if such modifications would be accepted.
@peterChengg Yes, exactly, separate attributes for HA reporting would be perfect. We don’t need to modify PTMSD or break IR AC control; we just need HA to read the actual 0.5°C setpoint the W100 already maintains internally. This solves the issue for Zigbee integrations without touching your IR protocol. Can you escalate this to the project team as a potential firmware enhancement? I’d be happy to help test.
This is unacceptable. Your interface lets users select 0.5°C increments, then silently throws those adjustments away. How does something this basic make it through testing? And how is it still unresolved months after customers pointed it out?
I bought two W100s expecting working thermostat controllers, not a broken feature and a pile of excuses. Both are going back to Amazon today. You’ve wasted my time and lost my business. I won’t buy another Aqara product.
Waiting on HA compatibility to buy multiple W100 units
I bought five W100s and I’m honestly very disappointed to learn about this limitation.
Nowhere on the product page or in the manual does Aqara mention that temperature control for air conditioners is limited to 1°C steps. The product images even show temperatures like 26.5°C, which naturally makes you expect 0.5°C control.
How was I supposed to know about this before buying? Luckily, I managed to sell all of them.
I understand the explanation about standard IR protocols using 4-bit integers, but I’d suggest that your project team take a look at the open-source IRremoteESP8266 project, which already supports 0.5°C adjustments for certain AC protocols. This is just one example.
I’m not suggesting that Aqara needs to support every air conditioner. Why not start with popular brands and gradually expand the list based on user requests?
If you can’t fix this limitation, at least clearly mention it on the product page instead of leaving customers to find out about it on the forum.
I requested this feature here months ago, but still no update either. Very disappointing. Feature request: Full 0.5°C setpoint precision over Zigbee - #7 by jfehmer06
@peterChengg
We’ve used PTMSD on zigbee2mqtt/ha implementation because it’s what we could reverse engineer as no specs are shared from aqara.
Please post specs about the other protocol used for w200, or add some new endpoints for that in a new fw, and I’ll change the current implementation in z2m.
Thanks.
For example, could we support additional attributes to report the mode and set temperature, which could then be provided to the home automation (HA) system for control?
@peterChengg , sure that the option n:2 I propose just above.
New endpoints for set/get thermostat temperature is the way to go.
We don’t need to stick on PTMSD at all
I have 5 of these, trying to set integration and also discovered that the buttons let us set 0.5C increments but the value sent is an integer. This also works the other way - updating W100 with new target is also only read as integer.
I also vote for either a separate attribute or sharing what else can we read from or wtite to, to get 0.5C resolution work.