I understand. You want to use Z2M, and currently, you’re missing our Endpoint. You want us to make this value available.
2 Likes
@XT-XianTang In fact we already use the aqara private cluster endpoint described in the post mentionned above.
But perhaps we’ve missed something to use 0.5° precision and I could chat with one of your developper ?
But if we can have a standard endpoint to set/get the thermostat mode setpoint with 0.5 step that would be even better and make it a really great product yes 
This said, then it would be interesting to have standard zigbee clusters for all the other features then instead of using only aqara private cluster to make it fully conform to zigbee 3.0 .
Thanks
edit:you could also add a new endpoint to set the thermostat precision. ( from 0.1 to 1 )
We could then use short press to navigate between precision points, and long press would jump by 1°C. But that’s another thing. Let’s start by the basics.
5 Likes
I would also appreciate this fix very much. I think the W100 has great potential and I can imagine (like many others) to use them for every room as wall thermostats to control e.g. E1 or W600, but currently the zigbee endpoints need a fix.
Calibration is one thing and changing the data type to float the other thing so that 0.5° changes actually do make a difference. Otherwise just set the step size to 1°.
Seems like the latest firmware 0.0.0_1640 introduced some “instability” with HA integration: [New device support]: Aqara Climate Sensor W100 X0028HPT89 · Issue #27262 · Koenkk/zigbee2mqtt · GitHub
@XT-XianTang - What did this firmware bring new/try to fix?
Not only Z2M or HA , but on any zigbee coordinator.
New firmware has a structural bug, the native msTemperatureMeasurement and msRelativeHumidity clusters publish now rounded value for temp and humity on a periodic timeframe ( but still publish on the same cluster float values too )
It makes the device completely useless now it overwrites corrects float values periodically giving glitches to measures.
[21:48:36] debug: zh:controller: Received payload: clusterID=1026, address=63750, endpoint=1,
frame={... "payload":[{"attrId":0,"dataType":41,"attrData":2269}] ...} ← **22.69**°C ✓
[21:48:54] debug: zh:controller: Received payload: clusterID=1026, address=63750, endpoint=1,
frame={... "payload":[{"attrId":0,"dataType":41,"attrData":2200}] ...} ← **22.00**°C ✗ (exact integer)
@XT-XianTang what is happening with this update ? Is the development team aware of this new issue ?
@XT-XianTang No response on the reply from KipK from Jan. 20th about the endpoints, now a broken firmware pushed to the W100.
Can you shed some light on both the decimal truncation of the setpoint in the PMTSD format and now the recent firmware 0.0.0_1640 also bugging out in regards to sending intermittent not truncated/truncated measurements for temperature and humidity? This last bug makes the device truly useless if one were to update (or receive it with that firmware version), the other is also not that nice to have to deal with (placebo 0.5 degree increments).
1 Like
The old W100 firmware only reported the temperature when it exceeded a threshold. However, when paired with other thermostat products, such as the W600 and E1, this could result in the W600 and E1 not receiving new data (because the W600 and E1 are also battery-powered products and have their own communication sleep intervals), leading to inaccurate temperature control. The new W100 firmware (version 1640) has added an additional reporting method: temperature change + a periodic report every 10 minutes. Moreover, when paired with other thermostat products, the control speed has been improved from the original 5 seconds to 2 seconds.
@XT-XianTang that doesn’t explain why it nows report randomly plain integer value ( 22°C ) instead of float value ( 22.1°C )
Look at this graph here:
Reported temperature & humidity oscillate between integer and float.
We can’t say that’s an improvement.
2 Likes
Are you telling us that you do not have any concept of synchronised communication windows, beacon intervals, or anything like that and in all future features where your products will need to communicate with one another both products simply have to randomly decide to wake up and communicate at the same interval? Don’t you literally have a hub in the ecosystem that could be at least used to mediate and establish reliable communication?
@XT-XianTang can we have proper answer to the subject
None of the answer you’ve provided was related to the issues we’ve posted here
We had literally no relevant answer to any point exposed on this thread.
I’m tired of this Brand.
You should be inspired by how SonOff is handling its community. They’re responsive, share technical informations with open source developpers, even publish commits on zigbee2mqtt to improve their device compatibility
While here we have someone that seems to not even understand English or always missing the point…
It’s over for me for this Brand. Aqara doesn’t respect it’s consumers, you’ve lost my consideration.
4 Likes
And then it suddenly stopped reporting anything. W100 connected to M3 via Zigbee. M3 connected to HA via Matter. All systems are running fine. The useless product saga continues.
It’s been quite frustrating the “flakiness” of some of Aqara products and lack of “open-transparent technical details” policy.
We have a firmware upgrade in this case and don’t have a clue/reason understanding of what changed, for what reasons, with what impacts (existing-working setups) - especially before hand.
There is much to “learn with other players” and communities out there.
@XT-XianTang @AqaraOfficial - Any expectation on a reasonable answer and reasonable solution/fix (firmware)?
3 Likes
@XT-XianTang and @AqaraOfficial - Any news soon?
@XT-XianTang and @AqaraOfficial - At least providing a way to revert the devices to old/previous firmware?