min/max are not honored for Values

[GoogleCodeExporter]

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 pnau...@gmail.com on 17 Oct 2011 at 10:33

[GoogleCodeExporter]

Original comment by jus...@dynam.ac on 15 Oct 2014 at 2:59

• Added labels: Milestone-1.4

[bytedreamer]

@Fishwaldo I can take a look a this issue. It should be a good start for me to get fimilar with the code base. Thanks

[Fishwaldo]

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. )