Let's Control It

I over-estimated what the rules parser was capable of and found an interesting effect that could cause problems if one were to make a mistake by leaving out an else or endif... this doesn't feel like intentional behaviour and isn't logical, so it may need some work to stop it happening.

I wrote:

on Rules#Timer=1 do
if [dummy#var1] = 1
7dt,1
TaskValueSet,12,1,2
endif
if [dummy#var1] = 2
7dt,2
TaskValueSet,12,1,1
endif
endon

I expected, logically, the display to alternate between showing "1" and "2" each time the timer event occurred.

However, what happens in fact is that each time the event occurs with dummy#var1 = 1, the display shows "1" very briefly and then stops on "2". The code execution is falling through from the first "if" clause and executing the code inside the second "if" clause.

I get that the rules are very simple logic and the intended coding would be to nest the second "if" in an "else" section of the first "if" - although that will produce some very ugly code in an application like mine where there are 7 different display values to cycle through - but the problem here is that the parser fell through and executed code that shouldn't have been executed. That could happen easily if someone missed an "else" or "endif" in otherwise valid code.

Could the parser be amended so that it gives an error or ignores the second "if" clause (or better still, processes it properly)?

We'll make an code valuator in future releases where we can use JavaScript to parse through the code to make sure errors are detected. We're not there yet but it's on the to-do list.

Great idea

Cracked it

I thought that my logic block was too much for the parser, but in fact it was partly my logic at fault... incrementing the counter in each "if" block was silly because the next block then had the right conditions to run. With multiple "if" blocks, that's not clever. D'oh!

So, here's how I cycle through a number of sensor values in a timed event:

On Rules#Timer=1 do
if [MyVars#cycle] = 1
7dt,[BME280_1#Temperature]
endif
if [MyVars#cycle] = 2
7dn,[BME280_1#Humidity]
endif
if [MyVars#cycle] = 3
7dt,[AM2302_1#Temperature]
endif
if [MyVars#cycle] = 4
7dt,[DS18_D6_1#Temperature]
endif // [MyVars#cycle] = 5
if [MyVars#cycle] = 5
7dn,[BH1750_Lux1#Lux]
endif

TaskValueSet 12,1,[MyVars#cycle]+1
if [MyVars#cycle]=6
TaskValueSet 12,1,1
endif

timerSet,1,5
endon

I'm very pleased to say that the parser does cope with those separate "if" blocks nicely If I try to take the alternative approach and nest each "if" in the "else" clause of the previous "if", it doesn't play nicely. Fortunately, in this case, separate "if" blocks makes for cleaner code anyway.

Always something to learn...!

A nice addition for cases like this would be a 'switch' statement, although it may be too much for the current parser.

Also and 'exit' or 'break' statement would help make some rules cleaner to read.