You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is provision for zwave values to have min/max values, which we store in
the config file. In some cases, we can get these from the device, in other
cases, determined experimentally.
However, these are not enforced anywhere, so it is possible for example, to set
a completely bogus value in openzwave (e.g, a thermostat set point), which it
will hold onto until it gets an update from the device.
Enforcing these in most cases is easy - consider min and max of 0 as unknown,
and refuse otherwise.
The problem here is for thermostats, which typically have the option of
reporting in C and F, which will naturally have different ranges.
Original issue reported on code.google.com by [email protected] on 17 Oct 2011 at 10:33
The text was updated successfully, but these errors were encountered:
Ok. You should implement the checks in the Value classes, and throw exceptions on failures....
You should also deal with cases where no min/max value has been specified, in which case, disable the actual checking.
Final Gotcha - Should we accept values outside of the range if they are sent via the device rather than via a OZW enabled application... it would be harder to implement, but probably needs some real world testing. (eg, the older Aeon Labs MultiSensor would sometimes send temp values that were obviously wrong (like the temp of the sun type values). More often than not, this was when polling was enabled for the temp value, so if you have a older one, you should be able to reproduce. )
Original issue reported on code.google.com by
[email protected]
on 17 Oct 2011 at 10:33The text was updated successfully, but these errors were encountered: