Modulo, recursive function/while loop
I was trying to find a way to implement the modulo function and I attempted to do it with a Repeat loop and subtraction. I'm not sure whether the Repeat puzzle piece is intended to support a condition (making it like a while loop), but that's irrelevant right now because it clearly doesn't work at all.
But then I stumbled on a way to do it with a rule that acts essentially as a recursive function. First create a virtual meter to hold the values. Actually you only need two: remainder and divisor. You initialise the remainder to the dividend. Then you create a rule that is triggered by a change to the remainder value when that values exceeds the divisor. The rule itself modifies the remainder and thus the condition that triggers it, invoking itself repeatedly until you get the remainder.
In the rule that triggers the modulo rule, you need to use "refresh all" to see the result.
If you wanted to make a rule that acted as a "while" loop, you could set a condition, e.g. continue > 0, and keep incrementing "continue" until you wanted to stop the loop, whereon you'd set it to 0.
I like this idea 
Dave,the repeat puzzle is not working again. At least for me. Every items I have in any rules inside the repeat puzzle only executes once.
Dave,the repeat puzzle is not working again. At least for me. Every items I have in any rules inside the repeat puzzle only executes once.
Nope, it isn't working. That's why I ended up doing this :-)
Nope, it isn't working. That's why I ended up doing this :-)
Dave, shame I'm not a programmer to be able to understand where I would be able to utilize this. It is just simply top of my head...
Dave, shame I'm not a programmer to be able to understand where I would be able to utilize this. It is just simply top of my head...
Say that you can't achieve the kind of scheduling you want with the Zipabox scheduler (or you find it unreliable) and you want to implement your own scheduler. So you want to do something every 10 minutes, say, or every 20 minutes. You need to know whether the minutes past the hour are exactly divisible by 10, or 20. The modulo function works that out for you.
Say that you can't achieve the kind of scheduling you want with the Zipabox scheduler (or you find it unreliable) and you want to implement your own scheduler. So you want to do something every 10 minutes, say, or every 20 minutes. You need to know whether the minutes past the hour are exactly divisible by 10, or 20. The modulo function works that out for you.
Updated version. It seems like you have to insert a delay to ensure that the virtual meter's state is up to date.
Updated version. It seems like you have to insert a delay to ensure that the virtual meter's state is up to date.
clever! A wait might be smart, so that the recusiveness doesn't overload the poor thing? I guess the reason you suddenly have to use wait might be changes that the Zipato team has done to firmware to prevent reboots.
clever! A wait might be smart, so that the recusiveness doesn't overload the poor thing? I guess the reason you suddenly have to use wait might be changes that the Zipato team has done to firmware to prevent reboots.
It's something to do with the time it takes the meter states to propagate. Say the meter value is changed to 10 in the modulo rule, and this again triggers this modulo rule. The previous invocation of the rule sees the value 10, but (my tests seem to suggest) the new invocation does *not* see 10 immediately, but instead sees the previous value. I'm not sure about this explanation, but it seems that without the wait, the rule regularly misfires.
It's something to do with the time it takes the meter states to propagate. Say the meter value is changed to 10 in the modulo rule, and this again triggers this modulo rule. The previous invocation of the rule sees the value 10, but (my tests seem to suggest) the new invocation does *not* see 10 immediately, but instead sees the previous value. I'm not sure about this explanation, but it seems that without the wait, the rule regularly misfires.
That's also why I added the second check of the values, just in case the rule gets triggered by a "stale" remainder value. I don't know if it's strictly necessary, but you don't lose much by including it.
That's also why I added the second check of the values, just in case the rule gets triggered by a "stale" remainder value. I don't know if it's strictly necessary, but you don't lose much by including it.
Replies have been locked on this page!