[Released] Rule 4.0


#264

I have a very simple rule with a Days of Week Schedule trigger of a specific time of day. The goal is for the actions to run once every day at that time. I had something similar under RM3 that worked, and I've now created under RM4 (repro'ed this under 2.1.2.117 and .115). No events are shown at all. The actions execute fine when triggered manually with Run Actions. What am I missing?


#267

Please post your app status page Settings section.


#273

@bravenel

Is this what you are looking for?

Scott


#275

I have struggled with how to construct more complex automations in RM 3 and earlier. Apart from a few frustrating hours with understanding the indenting and editing in RM 4, I think I have it. Many thanks for this update. :+1:


#276

Yes, and it looks correct to me. I just tested this, and get no error. Could you show the command definition line for what is being called by this custom action?

It would look something like this:

command "setStatusLED", ["number", "number", "number"]

And the method definition line:

def setStatusLED(a, b, c) {


#277
command "setStatusLed", [
      [name: "LED*", type: "NUMBER", range: 1..8, description: "1=LED 1 (bottom), 2=LED 2, 3=LED 3, 4=LED 4, 5=LED 5, 6=LED 6, 7=LED 7, 8=ALL"],
      [name: "Color*", type: "NUMBER", range: 0..7, description: "0=Off, 1=Red, 2=Green, 3=Blue, 4=Magenta, 5=Yellow, 6=Cyan, 7=White"],
      [name: "Blink?*", type: "NUMBER", range: 0..1, description: "0=No, 1=Yes", default: 0]
    ]

def setStatusLed(led, color, blink)

Let me change it to what you have and see if that helps.

Scott


#278

Don't bother. What you have is fine, and it works for RM-3. Not clear what's wrong.


#279

You have revealed a bug. Looking into it. There is no "allHandlertrue".

Update: bug found and fixed --> will be in next release.


#280

Yep, had the initial issue with RM-3 but you sqashed whatever was causing the issue.

The rule works in RM-4 but throws the error. I can't figure out why either.


#281

When you rebuilt it, did you delete the old one and start from scratch?


#282

@bravenel. Not sure if you commented to this. Wondering if you have a suggestion


#283

Yes, except I did not delete the RM 3 version.

Let me delete it again and make sure. I'll try it again.

As info, from the device details page if I enter the parameters in the command button, it works perfectly and throws no errors.

I'll delete the rule completely and rebuild and see what happens.


#284

You could put the current mode into a global variable in a rule that checks the variable before setting it.


#285

@bravenel

I deleted the RM-4 rule, paused the RM-3 rule, rebooted my hub, and rebuilt the RM-4 rule. All with same result.

Scott


#286

OK, I will look further... Could be I missed something. It looks like its calling the method first with one param, then two, then three. Hmmm.

Ah, found it. Next release. At least it works. In the next release it won't throw the errors.


#287

Awesome. Good job as always! Yeah, the rule worked, but my OCD did not like the red error messages :joy::joy:


#288

@bravenel

There's a bug with using lock-codes in RM4. The same automation created using RM3 works.

The relevant discussion is linked to below - I thought it was more likely you would see it here:


Simple door lock trigger
#289

OK, I'll look into it.

Update: Bug found and fixed --> next release.


Simple door lock trigger
#290

You guys are the best! Where do I send pizza? :slight_smile:


#291

perhaps it should be:

IF condition 1  (TRUE)
   IF sub-condition 1.1 (TRUE)
   THEN do action 1.1
   ELSE do action 1.2
   END-IF
END-IF
IF condition 2 (FALSE)
   IF sub-condition 2.1 (TRUE)
   THEN do action 2.1 
   END-IF
END-IF
IF condition 3 (TRUE)
   THEN do action 3.1
   ELSE do action 3.2
   END-IF
END-IF

Without the added endif for each condition, cond 2 and 3 would only be evaluated when cond 1 is true (as 2 and 3 would be under the con1 if .