Update TZE200_b6wax7g0 moes.ts

[loodvin]

increased accuracy on both devices

[Koenkk]

Thanks!

[srett]

@loodvin Does this actually work for you? If so, maybe there are different firmware versions of this device around after all, because mine don't accept .5 increases.

When I go from 17 to 17.5, the TRV will jump to 18 and after a second or two, this is reflected in zigbee2mqtt.
When I go from 18 to 17.5, the TRV stays at 18 and zigbee2mqtt never updates the state.

[loodvin]

@loodvin Does this actually work for you? If so, maybe there are different firmware versions of this device around after all, because mine don't accept .5 increases.

When I go from 17 to 17.5, the TRV will jump to 18 and after a second or two, this is reflected in zigbee2mqtt. When I go from 18 to 17.5, the TRV stays at 18 and zigbee2mqtt never updates the state.

I honestly can't check. It seems that on the device itself you can set it within the 0.5 limit. I don't have a test stand.

[loodvin]

I'll test it tomorrow and write back

[loodvin]

@srett I have the same as you, but I remember exactly that the accuracy of the device is within 0.5, so I made the changes.
Please check for yourself, I don't have access to my thermostat now.
Most likely, integers because

[srett]

@loodvin yes, on the device it's .5 steps, but I remember even when I still used ZHA it could only do whole steps via zigbee, and when I researched it, someone somewhere said it's limited by the zigbee implementation of the device.
What I don't know if whether it could do .5 steps if you'd use the official Tuya hub and app.

Still, I'll dabble around in legacy.ts later today to see if it's possible to get this to do .5 somehow...

[srett]

Indeed, it's sent as an int (4 bytes), so removing the Math.round call would break further down when calling convertDecimalValueTo4ByteHexArray as that one hilariously breaks when passed a non-integer value.
So this commit should be reverted, sadly no way to support .5 steps :-(

I wonder if it would make sense trying to catch these cases more generally to prevent accidents like this. For example removing the Math.round calls in call sites like the aforementioned moesS_thermostat_current_heating_setpoint and instead moving it directly into setDataPointValue, and printing a warning if the passed value was not integer already.
Of course this has to be done carefully, as some call sites might be actually handling float values and then call round for good reason, but many call sites, just like moesS_thermostat_current_heating_setpoint, seem to only call it as a safety measure in case their call sites improperly pass floating point values. @Koenkk any thoughts on this?

[loodvin]

I completely agree. Yesterday I got errors with non-integer numbers.