I want a rule "if lock was unlocked via code do A, but if unlocked physically do B". Searching yields a dozen or so threads where this has been asked . It appears nobody has been able to solve it using the rule engine alone, (one implies WebCore can't do it either). One thread proposed a solution, but that involved coding a custom app. I had what I thought was a genius idea, but it failed spectacularly. However am looking for advice to see if this idea could work with some changes.
If a lock is unlocked physically only one trigger event is sent, the lock status changes. If the lock was unlocked via code, two events are sent: lock status changed and the lcm code was used. My idea was to have one rule that fires if the Lock Code Manager reports a code was used that sets a global boolean. A second rule fires when the door is unlocked. This rule has a 1 second delay (to allow time for the first rule to process) then checks to see if that boolean was set. By all appearances, the rule engine detects the race condition and aborts processing both rules, because I don't even get the test events logged. Any ideas if this could work?
Rule 5.0 (just released) added a feature where the a new, built-in %text% variable contains the event description. For some locks, this may say things like "Front Door Lock unlocked [physical]", so you could assign %text% to an actual variable, then do a "contains" operation on that variable to search for "[physical]" (or "[digital]") and act accordingly on that result. This, of course, also assumes you don't do something odd like name your lock "Front Door [digital]," in which case all bets are off.
But the first question I'd have is whether your lock reliably reports the above. If not, all bets are still off. It should also be noted that if only cared about lock codes, you could trigger on "Lock Code" instead of "Lock," but since it sounds like you want something on phyiscal unlocks, too, you'll probably need something like the above, so I'd ignore this idea--but it sounds like you thought of it, too!
I'm not sure where your "race condition" problem came into the picture, but I'm guessing it was with that latter idea? Rule Machine shouldn't have given up--if both trigger events happened at the same time or nearly so, both should have triggered, just not necessarily in a guaranteed order. But if that's only something you were doing for the above reason, maybe this new Rule 5.0 feature will help? I didn't really spell out how to do it, but that's the general idea, so let me know if you want something more specific!
Yup I do certain things if my door is unlocked (always) and do additional things specific to the lock code detected and I donāt have any issues when both executing.
Thanks. Your suggestion of using %text% solved the problem, quite nicely actually. However, per both your and Steve's comments below my original idea of using the 2 rules should have worked, and now that has me curious as to why it didn't.
You could try turning on logging for the rules if you hadn't already to see what the rules think should be happening, but if you made me guess: Z-Wave locks are notoriously problematic for some people, and it's possible that neither the physical nor digital events were making their way back from the device to the hub, so nothing was happening there at all. (This could be easily verified from the "Events" button on the device page.) Again, just a guess, but nothing that hasn't happened to anyone before!
Otherwise, sometimes there can be an oddity with a specific app/rule, and going in and hitting "Done" will sort of re-initialize it, including re-subscribing to device events if that subscription got lost for some reason. Creating them new like you might be doing now would, of course, also have the same effect.
You've already solved the problem, but responding to your last point, it appears to be a combination of both. Parsing through the events, there is almost certainly a case where the events subscription was lost, as I had the 2 event setup working briefly before, it stopped working, but a quick test today revealed its working now (but I'm not going to use this, your solution with the reserved variable test is IMHO a better idea). Also, a parse of the device events reveals their are missed events from when the lock was locked or unlocked with a key (but every time it was locked or unlocked by turning the knob or electronically is correctly logged). It almost appears if the key is just enough to sometimes mess with the signal transmission It is a Kwickset lock and some searches on these forums seems to indicate I'm not the only one wondering if the radio/antennae
on a Kwickset lock is weak.
It is a Kwickset lock and some searches on these forums seems to indicate I'm not the only one wondering if the radio/antennae
