I have set up a dashboard to allow a neighbor to turn the alarm on/off. I used virtual switches for the dashboard. I then set up the following rule to set the mode from the dashboard if I had guest enabled. I couldn't get it to work and messed with it for some time before figureing it out. I had the virtual switches set to automatically turn off after 1 second. I had to lengthen that to 5 seconds to get the rule to work. The rule was triggering, but the conditions were always false. I had thought that if the rule triggered the conditions would have had the same state of the switches. I wouldn't have thought it would be so long after the trigger that the switch condition was no longer valid. Any thoughts?
As I have told you before, HSM is controlled by mode. But that is unrelated to the question here. The rule actions did not execute when the rule triggered until I lengthened the on time of the switches. That is not a problem in this case, I am just puzzled as to why.
I don't believe that it is unrelated since you say:
So, HSM would have to be tied to mode.
Hubitat should not take that long. Do you have logs?
What do you mean? Right now, all the switches are off, that's why they all read false.
The rule is evaluated when it is triggered. Not later unless you build in a delay. Again, if you turn logging on for the rule that would be a big help.
OK, let's start all over. Forget I said alarm. I set up a dashboard to allow a neighbor to control MODE.
The virtual switches were set up to automatically turn off after 1 sec. It would be almost impossible to show the rule with the switches on.
When one of the switches comes on, and it can be any of them. the rule is definitely triggered as shown in the log. The first condition of GUEST ENABLE is true. But the other conditions evaluated false according to the log, and the mode didn't change.
So I lengthened the on time of the virtual switches to 5 secs and it started working just like it should. I tried 2 seconds and that didn't work either.
My point was if the switch was on to trigger the rule it should have still been on to trigger the actions. They should have occured much faster than the 1 or 2 second switch turning off time.
Everything works ok, I was just puzzled about the execution of the switch state.
By the way, ALARM does not necessarily mean HSM. My alarm system doesn't rely on HSM.
I don't know what you mean by this. Switch state isn't an action, it's an attribute or a condition. You can execute a change to switch state (turning on or off) but you can't execute switch state.
That doesn't make any sense though...unless you have some type of delay to turning the switch on (not off) there is no reason why the rule would take 5 seconds to evaluate the conditions in the rule. That's why I asked to see the logs.
Sorry if my wording is not correct. I think my meaning was clear, or at least it would be to most people.
I agree, it doesn't make any sense.
If you look at the rule you see that the triggers are the same as the conditions in the actions. So if the rule triggers, and guest is on, then one of the conditions should execute. All I know is the rule did trigger as shown in the events of the rule. But the corresponding action or condition did not.
So the switch came on, and it wouldn't have made any difference if there was a delay or not as the rule only triggers when the switch comes on. But the corresponding action condition didn't work until I lengthened the time the switch stayed on. Apparently the rule goes back and checks the state of the switch during the condition, even tho it was on when the rule triggered, and the switch on time had timed out before the condition was evaluated. I just didn't see why it should work that way.
I don't see where posting a log would make that any clearer. To post a log now, I would have to change the times back, and re-test. I don't think it's necessary.
What is your specific question? Do you want to know why it took 5 seconds to execute? No way to know without the logs. Anything else is just speculation.
I think he's using the momentary switch feature so the switch toggles itself off after 5 seconds. When it was set to 1 second the rule didn't work as intended. As you point out the logs will show him his answer.
OK, here you go. The following will show you what I have been trying to tell you. I created a new rule to test so I didn't have to have my mode changing. This rule is a little simpler, but the same result.
As you can see the rule looks for either of 2 switches to come on to trigger the rule. Then in the actions it looks for which switch came on and do something based on that.
I have the switches set to automatically turn off. First try I used 1 second. Here is the log.
You can see that the action then executed just like it was supposed to.
So what I was saying was that between the time the rule was triggered and the time the condition was evaluated, if the switch on time was too short the rule action was false and thus did not execute.
I already knew that was what was happening and tried to explain that above. What my puzzlement was, I didn't expect that to happen as the execution of the whole thing should have been much faster.
It wasn't that I didn't know what was going on, it was the fact that I was surprised about the timing.
This rule worked with a 2 second switch on time whereas the other one needed even longer. But the other rule has more going on than this one. The idea is the same tho.
It works just fine. And the auto-off for both switches is 1 second. In your second try running the rule you can see that the rules evaluate in less than a second. WIth mine, it is less than 100 ms. So, I wonder why yours is taking so long. You should probably contact support. Is your hub slower in general?
A second between event generation and RM rule execution is MUCH slower than any of my 3 hubs are.
My guess is your hub is really busy/bogged down. Have you tried rebooting, then retesting to see if it is any different?
If not, you may need to start thinking about making changes to lower the overall load on the hub.... Eliminate user drivers and apps, fewer rules, split into multiple hubs, etc.
I've been down this road many times. My hub gets re-booted regularly. I have about 100 devices, a third of which are virtual. I only have 1 custom app which checks for weather alerts every 30 minutes. I have a couple custom drivers, Logitech Harmony and Fully Kiosk. I have nothing in logs or anything else.
I have always said execution should be in the millisecond range, not seconds. But it isn't and there doesn't appear to be any valid reason for such.
Other then turning off apps/devices to see what is causing the slowdown, the only other advice I would give is to contact support and work it through them.
Just know that their 1st recommendation will be to turn off user apps and drivers to see if it makes a difference.
At the time things were a lot worse. They discovered that Echo Speaks was logging an error about once per second. That never showed up in my logs so I never saw it. I deleted all the Echo speaks apps, drivers, devices, etc. and that cured the issue. Everything was working fast enuf that I really didn't notice any slowdowns that mattered. It wasn't until this rule acted up that the timing reared it's ugly head. When thing happen within a couple seconds I don't really notice it being slow. Most of what I do is control, not automation, so it's not as noticeable. At some point, it's working well enuf for my purposes to not spend time going any further. It's only when something doesn't work that it becomes an issue.
I'm not getting rid or any rules or devices just to gain a second. Not worth it.
