Isn’t
fan is off TRUE
fan is on FALSE
The same thing? I’ve been trying to get
Fan is off FALSE or
Fan is on TRUE
been trying for hours and I can’t. My frustration level is a 10.
Help please, thank you
Don't focus so much on true and false. Code the conditions as you know they'll be. It is confusing at first, but if you learn not to look at the state display (TRUE or FALSE) and just code to the condition, you'll get the hang of it.
So, an easy one is:
IF (Fan is on) THEN
Do something
ELSE
Do something else
END-IF
If you post a screen grab of your rule, I can help walk you through it.
5 Likes
So if you want the wink relay to be on when the fan is on then you need this.
If fan is on
then
turn on relay
else
turn off relay
endif
2 Likes
Thank you, I got it with that
1 Like
Welcome. It has taken me a while to get the rules to work. Still working on the more complex ones. You'll get it.
2 Likes
That really did help me a lot. I made 4 new rules based on that one. Thanks again
1 Like
Here's why @corerootedxb & @razorwing are suggesting you not look at the TRUE/FALSE thing...
You look at that and can go crazy trying to "fix" the extra "TRUE", right? Two Trues, one false.. what is that fan DOING?? 
The IF-ELSE is the key. If-else only evaluates when the PRIOR If's and IF-Else fail.
It's saying both the Medium speed and the Slow speed meet the criteria (over their respective temperatures,) But the IF + IF-ELSE + IF-ELSE + ELSE gets evaluated in that order. Once a condition is found to match, it runs that portion.. so you, visually reading my Rule, would read top down and the first TRUE is what's going to run.. the 2nd TRUE could run but never gets evaluated.
The IF THEN fails because the temp isn't that High. The 2nd IF-ELSE runs because the temp is that high... so the fan speed is set, the outlet is turned on, and that's it, NOTHING else gets evaluated. The 2nd IF-ELSE is ignored, as is the ELSE.
Thus, when writing this, if you're including LIVE sensors, it could get quite confusing 
Once it's written, it's time to look at those TRUEs and FALSEs to determine what's actually happening.
5 Likes
Was there documentation of this? Was I a victim of “read the instructions, man”
Also, thank you for explaining
I'm not sure there is... IF-THEN-ELSE flow and execution is sort of basic programming logic across most any programming language, so I doubt they repeated it in the Hubitat documentation.
I'm not sure the explanation of (T)(F)[TRUE][FALSE] is documented either - although I admit I didn't go look for it before posting this.
2 Likes
https://docs.hubitat.com/index.php?title=Rule-4.0
A little hard to find, but the docs are there, however, they don't address the (T) TRUE stuff. But, most of us that have been using RM for awhile just know not to look at it (after we were told by others lol).
2 Likes
It was very confusing and frustrating. I spent 4 hours going in circles
1 Like
Yeah, most of us have been there. Be glad you came into RM4. It has evolved so much from RM1, the two aren't even in the same ball park. RM1 was way more complicated.
BTW, you don't HAVE to use RM for things. You can go the custom app route (if you want to learn Groovy, which is a pretty easy language to pick up) and you can go with something like Node-Red (huge learning curve initially, but after that, it's all drag and drop). You can also code in NodeJS as well.
Since you've figured out the Maker API, you've opened yourself up to all sorts of possibilities. But, don't get discouraged. You'll get the hang of it and this community is fantastic when it comes to support and keeping one's spirits up. 
Maker API and eventsocket + an external rule machine/logic solver are the future of Hubitat (in my myopic opinion).
I have been building a nifty Node-RED custom node library to make interfacing Node-RED with Hubitat easier. Still has a long way to go, though before I'll release it. And that solution won't ever be a simple drag/drop for the average consumer, as it takes more technical know-how than that.
Going through an external box has speed disadvantages, too... But as I've moved ~50% of my RM rules and custom apps to Node-RED, I will say I've killed my Node-RED server with bad or suboptimal logic exactly zero times. I can't say that about Hubitat.
1 Like
Same! I have one RM rule that I wanted to create and I thought it'd be dead simple; Check a JSON webservice to see if it's a public holiday (or a day off from a list) and if it isn't (and it's a weekday), turn on the bathroom lights at 6:00 AM for my wife to get ready for work. Sounds easy, right? Nope. I spent probably a good 3-4 hours trying various things and then finally threw my hands up and set it up in NodeRed. Took me all of 20 minutes to do it there. It uses the Event socket to capture when my early morning mode activates, calls the webservice, checks a list, and then turns on the bathroom lights group with the Maker API.
To be fair, I could have done the same logic in a custom Groovy app, but I really don't like my HE hub having to rely on Internet resources given the issues with it in the past. My home server (64gb RAM, quad SSDs, Core I7-9700K) can handle that and tons more.
[Edit] I'd love to test your NodeRed nodes once you get them done.
While the advice above is helpful, I'm not sure anyone directly stated this: the green and orange values displayed after conditions in Rule Machine are the current values of that device or the final result of some boolean algebra when combining multiple conditions. You can't change them (without changing the device), nor would it make sense to. It's meant to help you when writing a rule/condition. I do like to check them on occasion as I'm writing conditionals and rule actions to see if I'm missing any logic, but I do generally ignore them otherwise.
I'm not sure this is actually documented anywhere or if they thought it was intuitive enough that it didn't need to be (I'm not sure it is; I remember being momentarily confused when this feature was added), so hopefully this helps if it wasn't already clear.
1 Like
Yeah, I mentioned that either here or in another of @frmWink2Hubitat's threads. Can't remember (read: old age kicking in) 
My advise was basically the same. I didn't find any documentation of the (T) TRUE display though.
I think the single letter, (T) or (F) is the current value of the device. In other words, if your conditional is: Motion A OR Motion B AND Switch C You'd get three (T) or (F) (one for each) and then a [TRUE] or [FALSE] on the entire conditional.
As was clear from my reply above, I don't look at them while writing - at least half that reason is because they aren't visible when writing a rule in one pass. I find them entirely valuable when I'm debugging my Rule.
One Condition, two elements. Therefore two (F) and one [FALSE]
I think it's overconfidence on my part that I don't look at them.. I actually believe: I can write a Rule, correctly the first time. I don't know why I believe that.. there's no evidence to support it. 
That's how I understand it as well. I also don't look at them while writing, as I find the extra unwanted (to me) info distracting.
1 Like
Thank you. I “kinda” understand node red from home assistant
