David Sanner - This likely has already been dis...
This likely has already been discussed but I've been working with zones & notifications and it seems only numerical ranges are used to evaluate zone states. Just wondering, does it make sense to also do simple boolean checks for zone states? Null value check? Both could be useful for zones & notifications especially with relays and digital switching but also other inputs/plugins.
Work around has been to try and use 1/0 and then evaluate -.1 to .1 for false, .9 to 1.1 for true (guess I should know if it lower range <= or < and upper are >= or just >) but some plugins and inputs set the path value to true/false.
Or is it possible to evaluate zones base on a boolean and if not does it make sense to add that ability or just try and stick w/ 1 & 0 where possible? Thanks.
3 Replies
so in essence this would mean mapping string values to notification states? sounds very doable
I would think as a base level all regular data types should be matchable, that includes boolean, and null/undefined should also be.
Adding custom string matching would be the next level.
null is pretty important because it's likely to signal a failure of some kind.
String values could work, would handle all sorts of plugin values & other binaries like on/off.
Straight matching isn't that much more cpu intensive than numerical comparison (regex looks to be 10-100x more costly if that's an issue but doesn't seem needed unless pulling a value from json value). Maybe just add a string field on the Data Browser Zone Edit interface... (next to Lower/Upper values)?
Straight matching isn't that much more cpu intensive than numerical comparison (regex looks to be 10-100x more costly if that's an issue but doesn't seem needed unless pulling a value from json value). Maybe just add a string field on the Data Browser Zone Edit interface... (next to Lower/Upper values)?