No, one is fixed in a wall with screws and cannot be moved around, easily. The other is designed around ease of use and the ability to move it from one location to another.
There are 5 types: Rule, Trigger, Triggered Rule, Actions, Schedule.
You are referring to the aesthetic "appearance" and mobility of the device, it's irrelevant to the "functionality"
A cell phone and a landline BOTH have the exact same function regarding phone calls.
It wasn't one of those where you put the speaker at the top and the microphone at the bottom was it? 
Sorry..........
1 Like
But they are referred to as cell phones and landlines in conversation. Also is true in any documentation because while they both allow you to talk to other people, a cell phone is more complex than the old school landline was on the consumer end of things.
Thanks for helping to make the point about why it is better to make a distinction between outlets and smart plugs.
As are "outlets" and "plugs" One is a "fixed" device and one is able to be easily relocated.
Not when referring to phone calls. They operate identically when making phone calls......Just as outlets and plugs do is relation to being operated by an "smart" platform.
Your welcome, there is no difference in the functionality between an outlet and a plug.
On a slightly different note...
I have discovered that the 'Delay this action' button doesn't do what I expected.
The documentation states that Actions execute subsequently but not when using this button. If my actions are:
Action a
Action b --> after a delay of 0:00:30
Action c --> after a delay of 0:00:30
Action d --> after a delay of 0:00:05
I would expect:
Action 'a' at rule start
Action 'b' at start + 30
Action 'c' at start + 60
Action 'd' at start + 65
but what I get is:
Action 'a' at rule start
Action 'd' at start + 05
Action 'b' and c' both at start + 30
If this the desired functionality, can you change the button from 'Delay this action?' to 'Delay this action from rule start?' or something?
I realize that I can use the inline delay instead and this does work great and I am busy making this change in all my 50 rules but users shouldn't have to learn this the hard way.
And lest I be misunderstood, thanks again for all the great work you have invested in Rules Machine. Especially release 3.
Trying to please a huge group of users can be a thankless and never ending task. I should know. 
1 Like
But if I ask for your phone number, I don't care whether it's a cell or a landline. The use case of "call mpoole32" doesn't make a distinction. Similarly, the use case of "turn off the family room light" doesn't have a distinction between an outlet or plug. (or even a smartswitch or smartbulb. They all have capability of "Switch". They can be off or on.)
Virtually all smart home systems (including Hubitat) have converged on a similar set of ideas about what a "device" is to an end user. Generally, it can be looked at in 3 aspects:
- What "Capabilities" the device has
- What UI representation it is given
- How you name it
For example, I have a smartplug by my bedside, with a lamp plugged in. It has capability of "Switch". In various UIs, such as Hubitat dashboards or HomeKit, I can "represent" it as a switch or a lightbulb. I have given it the name "Nightstand Lamp". I have never found it useful to refer to it as the "Smart Plug in my bedroom" or to represent it as a small cylindrical device. UI Representation and Name can be different than capability, which is different than the physical form of this device that is hidden behind my nightstand.
Like any abstraction, these abstractions of capability, representation, and name aren't perfect. For example, a GE Fan Controller switch uses z-wave messages ("capability") as if it was a dimmer, with a percentage of full power. However, inside the physical switch, it uses its dimmer percentage to decide among 4 fixed speeds. That causes some "representations" to be confused on some systems. For example, Alexa refuses to understand "Alexa, set the fan to Medium". Alexa wants you to set it to 50%.
Additionally, some smarthome systems haven't allowed enough control over these 3 aspects. In SmartThings, "capability" and "representation" are tightly tied together. If you want a different representation for a device, you have to use a custom driver. Some systems don't even allow that.
Overall, I really like the balance Hubitat has. My device driver (combined with the physical device) determine the capabilities. Depending on the capabilities, I can then choose the UI representation I want (Tile type in dashboards. Or icon in HomeKit.). And I can name independently.
1 Like
Now that you've learned how it works, what good would changing the words do?
2 Likes
I assume you are saying this in jest??? 
But just in case, I'm suggesting this for all the users who AREN'T me as well as the future acceptance of Hubitat and Rules Machine as a platform.
Also, this might have been a bug.
2 Likes
Yep.
I'm not seeing words which if added to the UI would adequately explain this.
4 Likes
For what its worth, what you've described is exactly what I would have expected. Further; I'm glad it works this way.
-gk
The documentation for RM has had this added to the explanation of delayed actions;
It is important to realize that the delay assigned to an individual action affects only that action, and not subsequent actions. Any subsequent action is executed immediately after the delayed action starts its delay timer -- it doesn't wait for that delay timer to run. When that delay timer expires, the delayed action is executed (unless the delay was cancelled).
Full text of action delay documentation:
Delay per action and Delay (Pause) all actions
There are three types of delays included: 1. Each individual action can have its own delay, which for Rules may include a cancel-on-truth-change option. 2. All actions can be delayed, effectively pausing the action execution for some amount of time. 3. All actions can be delayed for a period of time that depends on the current mode (Delay Actions Per Mode).
These are further described below.
Delay per action
Each action you define can have an optional delay. These delays can be defined with hours, minutes, and seconds. Seconds can have decimal fractions, allowing millisecond resolution. In a Rule, delays can have the option to be cancelled in the event of a change of rule truth. It is important to realize that the delay assigned to an individual action affects only that action, and not subsequent actions. Any subsequent action is executed immediately after the delayed action starts its delay timer -- it doesn't wait for that delay timer to run. When that delay timer expires, the delayed action is executed (unless the delay was cancelled).
Delay all actions
It is also possible to delay all actions (also with optional cancel). The script of actions runs sequentially when the rule runs, with each action happening in order. Actions with delays start their timer, which can vary for each action, and the next action in order then runs. By using the Delay Actions action the entire script can be 'paused' by a delay. This feature can also be specified on a per mode basis, so that the time the script is paused varies according to the current mode.
1 Like
I am trying to understand the new RM3. I want to have my undercabinet lights go on if it is during the day and the illuminance is below 3500 (rainy day) and also to turn on the livingroom lights between 3:00pm and sunset-40 if it is the same rainy day and the illuminance is below 3500. But everyday I want both sets of these lights to come on between sunset-40 and 11:00. But when my Goodnight Routine runs, it turns off all the lights so I don't want this to turn them back on if it is before 11:00pm. This is what I have right now:
So, the Rule is always analyzed first, right? And it will go no further if it is False except to the Actions if False? Also, when I was adding the ELSE IF, I had to create the Condition again. Shouldn't it offer me the Conditions that I made at the beginning in the Conditions part? When I run this Rule, the undercabinet lights come on even though the illuminance is greater than 3500.
I would say yes to this.
Every time the illuminance changes, the rule will be evaluated and the actions for true or false will run depending on the value.
No. The conditions you defined at the start are the 'Define Rule' part of the rule not for the actions part of the rule. This gives you more scope for your actions.
I have one that turns lights off depending on the mode, the lights either turn off after a set or random delay.
This is it.
BTW I have virtual switches that turn on and off depending on lux levels so that the rules are not continually evaluated every time the lux level changes.
Doesn't it evaluate the Rule that turns the VS on or off though?
Yes. I use this VS in about 5 rules. This way the 5 rules only get evaluated for lux value when the VS turns on or off. The rule that turns that switch on or off is the only one evaluated when the lux level changes.
Also if I want to change the level of the 5 rules to say, 10, I only have to change the one rule not 5.
I'm pretty sure that a true action will only run once the rule status changes from false to true, and vice versa, the false action will only run if the rule changes from true to false......the illuminace isn't what is evaluated to run the rule, the true/false status is. I could be wrong though...
In other words if the rule is already false and the illuminace changes and still makes it false.....the rule will not fire the false actions again.
1 Like
That is a valid point! When I run this rule my undercabinet lights turned on. Can you see what I am doing wrong?
