larryllix Posted April 7, 2020 Posted April 7, 2020 10 hours ago, kclenden said: @larryllix You may be right, but your test is not an apples to apples test. Your test uses two variables for which the ISY knows everything because it created them. The OP is using a node that was not created by the ISY and comparing it to precision represented by trailing zeros after the decimal point. I can easily see why the ISY would handle your variables differently than it handles the OP's comparison. A problem with that conclusion is that the OP says that if the node value is first put into a variable, and then the variable is used in the IF the programs run correctly. The ISY seem to be able to understand the node value well enough to put it into a variable, but not understand it well enough to use the node in a direct comparison. One possible explanation for that is that the ISY takes a zero (whose precision it doesn't fully know) and forces it into the precision of the variable it is being assigned to, while doing something different when using the node in a direct IF comparison. I'm sure there are other explanations, but only @Michel Kohanim or @Chris Jahn can tell us. Yes. That was my point. It doesn't happen with ISY arithmetic. It appears the NS pulldown menu with the value groupings are not being substituted into ISY's arithmetic capabilities properly. This suggests that the NS substitution table is incorrect, not ISY arithmetic processing. I don't use this particular NS, but the ones I have tried (including NodeLink), and logical deduction, tells me the pulldown menus do not deal with actual displayed values, but rather only a numerical representation of each value or group of values. I have written ISY programs utilising this fact where say an ecobee climate style is represented by 0 - 5 but the human sees. 'Away' ,'Home', ''Sleep', etc.. eg. If stat mode > 0 would include 'Sleep', 'Home', 'Wee Hours', Extreme Cold' etc.. IMHO this is the case of this, and all, NS/device pulldown values also. The OP is dealing with 0.000-0.400, represented as value 0, 0.401 - 0.500 as value 1, 0.501 - 0.550 as value 2, and so on. Where the actual value substitution is made is unknown to us, but IMHO is where the bug is happening. Other NS users have not reported this.
Chris Jahn Posted April 7, 2020 Posted April 7, 2020 Hi Guys, I took a look at the code that compares the event value with the value in the condition. If the precision (number of decimal places) of the event value is different than the precision of the condition value then it uses the smaller precision for both values to do the comparison. Therefore in the following condition with 0.400 (precision = 3), if the event value is 0 (precision = 0) then the 0.400 gets converted to precision 0, thus 0.400 becomes 0. In this case the condition will result in true. 'DarkSky / Forecast 0' Rain Today >= 0.400 Inches I'm looking at changing it now to always use the precision of the value in the condition rather than the smaller of the two precisions. 1
Recommended Posts