I considered that. But as long as I can make it work by leaving the switches on a little longer it is fine. Time here is not an issue. It's just controlled by a dashboard I created for a neighbor. She will have several minutes if needed, so a few seconds is immaterial. That's assuming she remembers to hit the button before opening the door. But you can't fix something like that.
Rules are free. Personally, I would never do it the way you're doing it. Consolidating things into a single more complex rule is never the way to go. KISS.
I understand what you are saying. But to me it helps to keep things sorta together so if I have to change or troubleshoot I only have to look in one place. And this rule is not that complicated.
I thought it would be nice to be able to say IF %device% = whatever it would have worked to start with. Let me explain.
I had it in my mind, wrongly, that the rule action would see the state of a device when that device was the trigger. (This thinking comes from my PLC days). But the rule looks at the device state when the IF is executed. And that is what threw me off at first. Once I realized it, it made more sense as to what was happening.
%device% always represents the last event device. So you could use this for a string comparison. Put some Log actions in your rule to see exactly what is going on. Those are in the Send Message section of the Actions.
I'm not seeing how to put %device% in a string comparison. Probably there, but I don't find it.
The rule is working ok now. So it's not really an issue. What I finally realized that this is what goes on:
Device1 turns on.
Rule triggers.
IF statement checks Device1 to see if on. (Again I wrongly assumed it would use the value from the trigger, rather than checking again).
In my case with the originaly 1 second off time on the switch, Device1 actually went off between the trigger and the IF check, which caused the problem.
As mentioned by others, the execution should be fast enuf so that doesn't happen. So I agree there is still something slowing my hub down. I did remove an orphaned device yesterday that I found. It was from HUB Connect, which I am not using now. And maybe that was causing part of the problem. Gonna do some time checking later today.
To use %device%, first set a String Variable to %device%. Then you can use that variable in a comparison.
Well apparently removing that orphaned device made a big difference. Here is the log on my test rule before the device was removed:
Here is the log after the device removed:
Big difference in execution time. I never saw anything in the logs about that device producing errors or anything to indicate it was eating up time. Same thing when I had the Echo Speaks devices that didn't show any errors but were doing so anyway.
Been using this rule as a test of my hub speed. I have made no changes to anything lately, no new devices, etc. But the hub has slowed down to the point where this rule no longer works. I reboot the hub and everything is fine again.
I can find no errors in the logs or anything out of the ordinary.
