It was ":" screwing things up in the %now% field. Other variables work fine.
How are you going to parse the response from your Sonos?
Were you ever able to get his working as a GET? I asked you in another thread and you mentioned something about time. I'd love to have a solution to:
If you set the URL formatting yourself, it still doesn't send the request? That's a little surprising. I would have thought that would have worked. The only solution I cam up with is to change over to sending POST messages instead of GET. That way I could send anything I wanted in the field since they'll be quoted.
I want to go back to RULE 3.0. Not a fan of 4.0 so far. Thing is I updated the firmware last night and it looks like I no longer have the option to create a 3.0 rule. How do I do that?
Thoughts? and THANKS!!!
Revert to an earlier platform version. Create a clone master as described by @bravenel here:
Then update to 2.1.5. You will have a permanent clone master to create Rule 3.0 rules.
1 Like
Thank you.
I am really struggling with rule 4.0
I get the if then else...but I want 2 conditional actions after 1 condition.
Select Actions for Home Lights ON when lux<500
IF ( NOT Mode is Night(T) [TRUE]) THEN
ELSE-IF (Illuminance of Illumination Sensor(250) is < 500(T) [TRUE]) THEN
On: Lights@Night
ELSE-IF (Illuminance of Illumination Sensor(250) is > 550(F) [FALSE]) THEN Off: Lights@Night END-IF
I am not sure if this is actually correct. What is better to do this multiple conditions? I do skip 50 lux to avoid lights on and off all the time if around a treshold value..
I also have to say that the interface is very confusing and pretty unforgiving if a line is placed in a wrong space. No real way to move a condition or action.
Feedback is appreciated and hopefully I will get the hang of this 4.0.
You want to use a nested IF rather than ELSE-IF, I think. Something like this:
IF ( NOT Mode is Night) THEN
IF illumination < 500 THEN
turn on lights
ELSE
turn off lights
END-IF
END-IF
The ELSE could be an ELSE-IF, but it's not really necessary since that IF contains only 2 conditions.
thanks, there is a second condition..the illumination > 550. this rule above would only switch lights off at 500. Maybe the else must have the if added there?
Oh, got you. I misread your first post.
IF ( NOT Mode is Night) THEN
IF illumination < 500 THEN
turn on lights
ELSE-IF illumination > 550 THEN
turn off lights
END-IF
END-IF
1 Like
You could also do a simple condition rather than a nested.
IF (Mode is Night) Exit rule
IF (illumination < 500) THEN
turn on lights
ELSE-IF (illumination > 550) THEN
turn off lights
END-IF
1 Like
thanks for the feedback!
And suppose I want to add another condition in this formula..I ask to learn to understand:
IF ( NOT Mode is Night) THEN
IF illumination < 500 THEN
turn on lights
ELSE-IF illumination > 550 THEN
turn off lights
END-IF
END-IF
How could I add another one? Is the example below then correct?
IF ( NOT Mode is Night) THEN
IF illumination < 500 THEN
turn on lights
ELSE-IF illumination > 550 THEN
turn off lights
ELSE-IF (illumination > 1000) THEN
turn on THE robot (just a whatever comand linked to the same sensor)
END-IF
END-IF
Or must I do something extra...I get the feeling that 2 ELSE-IF is incorrect to use?
You can have as many ELSE-IFs as makes sense for your logic. However, notice in what you just posted that the first ELSE-IF will always take the second one out of action. You probably need a more complex condition, such as illumination > 550 AND illumination <= 1000. Also, what happens if illumination is 525?
Hmmmm the idea is that when illumination is greater then 500 but below 550 that nothing happens..light that is on stays on and light that is off stays off depending the lux progress? a kind of do nothing value range? The trigger is lux value changes so that should work.
But I should think in this way?
if condition = A then
if condition 2 = B then action B
else-if condition 3 = C then action C
else-if condition 4 =D then action D
end-if
end-if
A=true then it will go to check B and if true nothing will continue due the else-if (or even else) If B is false then checking condition C and false leads to checking D.
If I use another IF instead of ELSE-IF then it will just run all the IFs regardless true/false of the previous IF?
I know that by not being a programmer, I need to get the thought process more clear here. I understand the simple IF-THEN-ELSE but struggle with multiple IF and ELSE-IF.
I do appreciate the help and feedback 
Wait for event
The timeout in wait for event means the wait is over, and the rule acts as if the event for which it was waiting has occurred, right?
Is there a way to do this in the reverse? A wait for event is cancelled after a specific length of time, as HE acts as if the event did not occur?
Sort of, but you need to be prepared for the possibility that the event did occur. You can set the "timeout" on the wait, then the actions will proceed on either the event occurring or the timeout elapsing. You can use an IF following your Wait to determine whether the even you want happened or not (e.g., if waiting for a contact sensor to open, use the IF to check if it's open; if not, it's closed, so your event didn't happen).
I'm normally a Hubitat fanboy, but I've just spent the last 30 minutes trying to edit a simple rule and I've just got to rant. Please excuse me.
Conditions and triggers are the SAME THING. Or I should say, they ought to be. RM 4's inclusion of conditions as part of actions is just something I cannot get my head around. Since when is IF/THEN an action?
Please, oh please, in RM Future, completely separate constructing logic for a rule from the *actions" to be taken as a result of that logic.
Thanks for listening. I'll calm down shortly.
Conditions and triggers aren't the same (as you know), and I'm not sure it makes sense for them to be--see an example below. Rule 4.0 requires a different way of thinking compared to "classic" rules (or webCoRE if you're used to that), but the difference is clear when you consider that there's no reason you'd want everything you test as a conditional to be used as a trigger.
Consider this simple rule:
Triggers:
Contact Sensor X changed
Actions:
IF (Contact Sensor X is open AND Time between sunset and 6:00 AM) THEN
Cancel Delayed Actions
Set Dimmer X to 75%
ELSE
Delay 0:01:00 (cancelable)
Turn off Dimmer X
END-IF
You have "time between sunset and 6 AM" as part of a conditional, but Rule Machine has no way of knowing what you really want as a trigger. The way I have the rule above written, it will turn on light (or whatever) if the contact sensor is opened between sunset at 6 AM, then turn it off 1 minute after it's closed. It will not turn it on at sunset if it's already opened. It would if you added "Time is sunset" as a trigger. It also won't turn it off at 6 AM automatically under any circumstance; it could if you added "Time is 6:00 AM" as a trigger. As a human, I've decided what I want my rule to do, but using all of these conditions as triggers isn't one, and a computer can't read my mind to know which make more sense for what I really want to do.
WebCoRE makes a "best guess" and lets you know (with the lightning bolt icon) what it's doing, but the webCoRE editor is basically a giant Rule Machine "Actions" section that lets you explicitly add either "plain" conditionals or "trigger" conditionals. The "best guess" comes in if you only define "plain" conditionals. RM just makes you specify the triggers in a separate section (if you want to--and keep in mind a Rule can be called from another Rule so doesn't need any triggers at all).
IF THEN isn't an action per se--it's a conditional action and is basically there to help "direct traffic" in your Actions section so things you want to run do run and things you don't want to run don't. You need things between them (except with a simple conditional action--basically a shortcut for a one-line IF THEN ... END-IF). RM could try to guess your triggers from there, but I'm not sure that's a good idea--even if RM were redesigned to edit things like webCoRE, we'd have to choose two different types of conditionals depending on whether we intend them to trigger something or not, and then it's pretty much just a different way to do what we already do.
