It's basically the same thing. Select the device capability, then the device, and then you are presented with a drop-down with all of the possible command for that device.
No longer do you have to pre-build custom commands.
Oh how I wish I could get this to stop repeating and the log error is still there
I tried adding the stop in the repeat command, adding an else before the end repetition and even tried using stop repeating actions, nothing stops it
Rick
Ok, this one is triggered by A_V-Contact "changing" but since it's repeat is set to run from sunset -30 until sunrise, it's going to keep repeating regardless of A_V-Contact's state, and you will also get multiple repeats because every time A_V-Contact "changes" it will start a new repeat if it's "between sunset -30 and sunrise"
Sorry not following why this is wrong. This is the exact example that Bruce and others have talked about.
If a contact sensor is open between sunset and sunrise, send a notification, repeat every few mins until the contact sensor is closed
How would you do this then?
Rick
You didn't put anything in to stop the repetition. So, yes, it will repeat forever.
This is the correct flow for what you showed in your example, hopefully it will help you with other rules.
2 Likes
I was using the end repetition as noted in msg 196 and others above. I'll give it another shot as @halfrican.ak suggested
Rick
What you have to wrap your head around is:
The trigger is what causes the actions to be evaluated
The actions are what was the "conditions" and the "actions" from RM 3 and before. As a result if you have a trigger you need to define specific actions based on conditional statements some thing for the open/close, true/false. active/inactive, etc.... This is accomplished with IF-Then and Else.
@bravenel, I see the hotfix addressed the 0 bug in custom actions. However, it is still there:
I am trying to pass integers (numbers) into setStatusLed(6, 1, 1) or setStatusLed(6, 0, 0)
As info, it works perfectly as written in RM 3.0
Yes i get that, my issue was that I was using references from above (yes i have read this whole thread, many times) where it was specifically stated to not use stop repeating actions and to use end repetition and to not use Stop in the repeat command. Seems like we have come full circle and using all of them now... LOL
It's working now as intended with your latest example
Thank you
Rick
You wouldn't need the "stop repeating actions" if you structured the rule like this.
In this example the trigger is the door opening (not closing) and the conditional action is tied to the door being open and the time of day being sunset -30 to sunrise. The repeat is conditional upon the door being open, if it closes the repeat will stop as the condition is no longer true.
2 Likes
Correct me if I am wrong, but it looks like it was included inthe update released yesterday.
Right. Stop and end repeating do completely different things, and are both needed/not needed for different reasons.
End repeating marks the end of the block that should be repeated when the specified conditions for repeating are met.
Stop repeating stops a block that is already repeating from continuing to be repeated.
Good programming form is to always end a repeating block with End repeating.
You only need stop repeating if you need to manually stop a block that is already repeating. Can be because you set it to repeat forever, or repeat until a certain condition happens.
2 Likes
Wow, without having had time to touch 4.0 yet - this is brilliant! A more general way of constructing rules, with a nice IF-THEN-ELSE-presentation to easily "see" the logic. That was one of the things I loved with Webcore, being able to just look at the code and follow the logical steps.
Great work!
Beep > Centralite keypad does not appear as an action type. Is this a bug?
Thanks! I haven't messed with custom commands since the original Rule Machine so I didn't know they were gone.
Thanks to @ogiewon I was able to get a beep out of my keypad.
@bravenel Is there some reason that beep() is buried under motion in custom commands? Key pads are annunciators too. I would make more sense to add beep under that than in motion. I am not even sure why it is in custom commands instead of just as a device type under action. Also why not a parameter for the number of beeps?
As a basic user, I suffered many hours trying to figure this out. It needs to be more intuitive.
Thanks for Rules 4.0. I love it so far.
Did you rebuild this rule? The bug happened upon creating the parameters, not upon running them later.
I don't think I did. Can't honestly remember LOL. I'll rebuild the rule and see if that works. Thanks for the help!
OK, rebuilt the rule. Still throwing an error. Weird thing is that it still sets the indicator lights, but shows the error.
Here is the error:
Here is a snippet of the setStatusLed method from the driver:
The driver originally had: def setStatusLed(BigDecimal led, BigDecimal color, BigDecimal blink) but it made no difference.
Here is my rule. The parameter type is number:
Scott
