Rule machine - as per the app developer, this app is no longer available for new installs, distribution, or support

To find out if my device uses that capability code

It will be in the device type that is assigned to that device. You have to look in the IDE.

Ok, I’m on my phone and didn’t see it. I’ll look when I get on my computer.

Do we only need to update Rule Machines and not rules by copying/pasting the code over the old one in our smart apps on ide? And that will still keep our existing rules we have setup on our phone app?

Just copy and paste Rule in the IDE, and hit Save. Don’t Publish it. Your rules should still be OK.

A quick question the specifics of how “Turn off these devices after a delay” works:

What happens if the Rule turns True, then before the timer completes it turns False? Does the timer turn off, or continue the original countdown to turn off the switch? I believe the current set-up stops the count down if the rule evaluates False and resets the timer waiting for a new True, but want to confirm that is the intent.

I personally would like to have a selection for each of these types of handling. Ex: 1) click a box to countdown and turn off the switch X minutes after the first time the rule is True regardless of what happens next and, 2) click a different box to stop the timer if the rule evaluates False before the countdown completes. It would then be as if the rule never fired, and the process would start all over again from the original X minutes if the rule fired True again. But if I could only have one type of handling, I would choose (2).

1 Like

Bruce this is clearly an amazing app. Very powerful.

I see you added “Turn off these switches after a delay”

Which is needed. But I wonder:

Can the app benefit from a general delay OPTION you can alternatively add to any action you define?

My example:
When a door is found to be unlocked, I want to lock it after a 15 minute delay. Or 30 minutes for a different door lock.

So instead of restricting the delay to a switch device. Is it possible to add a delay option to any given action the rule machine can take as a result of an evaluation? Perhaps a slider switch in the app to turn on a delay for that action, which adds a line specify the delay period?

I can accomplish what I want with your app, if I combine it with the timer app maxwell created then create two rules with your app, but it seems like the universal delay would be beneficial to all.

Thoughts?

2 Likes

I tried the turn off after delay and it seemed to execute after the first trigger. In other words, if the rule turns true again after the delay count starts, the original delay time does not reset each time the rule turns true. This is not how apps like bright after dark and other similar apps work. I found out the hard way when I converted over to rule machine and had to go back to bright after dark.

Right now, once the timer is launched it’s going to turn off whatever when it runs out. There is no linkage to the rule proving false while the timer is still running. I understand your request. Let me think about it. I have an overarching desire to keep things simple.

1 Like

It should restart the timer, if the rule went false and then true again. Evidently, this needs some attention if that’s not happening.

Good question, worthy of some thought! Interesting idea.

3 Likes

I think what he is saying is this: you have turn X switch after Y minutes. Lets say after Y starts countdown, and the rule turns false, and then true again before Y finishes the countdown, it doesn’t count down again for the second true condition.

Wow, how did I miss this?!! Great job, Bruce!

Question: Is there any difference (efficiency or otherwise) between ORing two conditions in the main rule versus a subrule?
e.g., condition <= x OR condition >= y versus (condition <= x OR condition >= y)

I installed this SmartApp tonight in hopes that I could create a rule based upon a current running Logitech Harmony state. However, I don’t see a way to do this even with virtual switching because the Harmony app doesn’t expose devices or their states, let alone the hubs reported state… I noticed that a couple of people in this thread have run into the same issue or researched the problem before; I am hoping that someone can point me in the right direction.

As a hypothetical example, I would like to create a rule that would only run given certain circumstances (harmony states):

IF [Harmony Activity == ‘Watch TV’ AND Motion Sensor == ‘active’]
THEN [Turn light in room on]
ELSE [IGNORE]

It is really disappointing to me that the official Harmony Smart app lacks properties/methods to easily expose these basic states so that you could easily integrate this functionality into your rules engine. I hate to say this, but a couple of talented Vera (LUA) programmers have figured out how to expose logitech hub state as well as individual device state without the grief (or SmartLab status) that the SmartThings Groovy model seems to create!?

Bravenel, this is exceptional work on your part, thanks for the time and effort! Somebody please tell me that I am missing a very simple way to accomplish this task…

I checked out the “Dimmer Level” as a condition, and it works.

Everyone should be aware however, that when a dimmer is on and at a level, and then the switch is set to turn off, that the dimmer retains the level of the dimmer setting even though the light is off. So if you want to set a condition that says: if the dimmer is < X, where X was the last dimmer setting when the light was on, a rule based on this condition won’t trigger when the light is off (if it was turned off and not dimmer to zero) because the dimmer setting is still at X (even though the light is off).

Also currently the only way to delay a light off is to use the “Turn off these devices after a delay”, which switches the light off but retains the dimmer setting at the old level. So using the logic above creates a little bit of an issue in using the dimmer level as a condition.

This would still exist, but be alleviated a bit if everything had a delay timer as requested by others since one could delay then set the dimmer to zero instead of delay then turn switch off.

My experience in live testing is that if the rule fires True, the countdown timer starts. If that rule turns False before the countdown timer ends, the timer continues to count down and trigger the switch off. However, if the rule fires True, then False, and True again all within the countdown time, the countdown timer restarts with the full time and turns the switch off at the end of that countdown. (ie there is no way to stop the countdown and the switch must eventually turn off, but the timer can be restarted during the process if the condition goes False and True again within the original time)

Not a bit of difference…

1 Like

Ok, understand the desire to keep it simple. However, by not deactivating the counter on False, I get the following behavior with timer set to X:

  1. I enter the room, a rule triggers True and the lights turn on. If I leave the room, a separate rule delays X and turns the lights off. (this works for me)

  2. I enter the room, a rule triggers True and the lights turn on. If I leave the room, re-enter the room, and leave the room again all before X time, the timer resets to a new X upon my last leave and the lights turn off after that. (This works for me)

  3. I enter the room, a rule triggers True and the lights turn on. If I leave the room, re-enter the room and stay in there until the original X time runs out, the lights turn off while I am in the room. (This behavior is difficult to deal with)

So if I could select to have the timer deactivate completely when it turns False, then wait for a new True, the behavior in (3) would not occur. This is why I am asking for it. Or I suppose I could remain completely still prior to every X minutes once any period of stillness has occurred. I think this would also fix the issue :smile:

1 Like

Because there is an official SmartThings/harmony integration, which is there is not for Vera, there are already two simple ways to accomplish this task. I don’t want to hijack this thread, I will give you the links to a harmony topic where you can ask any follow-up questions.

Method one: just include the SmartThings device in the harmony activity

Because the Harmony/SmartThings official integration is Two way, you can already add any device controlled by SmartThings to a harmony activity as a home control device. So you can already just have say a “watch movie activity” which is triggered by your motion sensor also turn your living room lights to dim and turn your hallway light on right in that harmony activity.

So SmartThings sensor turns on Harmony activity which turns on SmartThings light. Two way integration in a single Harmony activity. This requires no custom code at all, it’s just selections from the drop-down boxes in the harmony app. :sunglasses:

Or you could have a “good night activity” in harmony that shuts off your home entertainment system, locks the door, and turns off some lights.

Method two: include a virtual switch in the Harmony activity, and on the SmartThings side have a restricted routine or a smart app subscribe to that switch going on

This is how you would manage something like the “watch movie” activity coming on but only, say, after 6 PM and then have other things happen. That is, anytime you turned on The “watch movie activity” the virtual switch would come on, but you would set up the routine or the smart app to not run unless other conditions were also true. So that’s how you would keep from resetting lights during the daytime.

As I said, both of these are already available. Which one to use just depends on the needs for the specific use case.

Here’s the FAQ on the Harmony/smartthings integration. You could also create your own topic under projects if you want to brainstorm a specific set up. :sunglasses:

As far as using rule machine with it, if you need that, the second method would probably be more appropriate. And you would just trigger from the virtual switch Being turned on.

@bravenel - I shot a pull request your way that may fix this (at least it does for my specific case). The logic may need to be tweaked a bit, but I think it’s on the right track.

Thanks.