Piston triggering Issue

lock
camera
ifttt
#1

1) Give a description of the problem
Using RBOY Lock DTH and triggering a IFTTT Maker Event to start WyzeCam recording but triggering more often than it should. RBOY told me to check WebCore as it works appropriately in Smartthings.

2) What is the expected behaviour?
When the Lock Code #1 is used, send the IFTTT Maker Event to trigger recording. This allows me to record a short video when someone uses the front door code.

3) What is happening/not happening?
When there is a programatic unlock (i.e. routine, piston, etc.) or the unlock code #1 is used it is triggering this piston. It should only occur when code #1 is used.

**4) Post a Green Snapshot of the piston!

LockRecord
LockRecord.png1178×484 92.5 KB

5) Attach logs after turning logging level to Full
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:35 AM: info [DTH] parse() - returning result=[[name:alarm, value:forced, descriptionText:Alarm mode forced, linkText:Front Door Lock, isStateChange:false, displayed:false]]
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:35 AM: trace ConfigurationReport ConfigurationReport(parameterNumber: 7, scaledConfigurationValue: 3, reserved11: 0, size: 1, configurationValue: [3])
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:32 AM: info [DTH] parse() - returning result=[[name:codeLength, value:4, descriptionText:Code length is 4, displayed:false, linkText:Front Door Lock, isStateChange:false]]
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:32 AM: trace [DTH] Executing ‘ConfigurationReport’ for device Front Door Lock with code length := 4
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:32 AM: trace ConfigurationReport ConfigurationReport(parameterNumber: 16, scaledConfigurationValue: 4, reserved11: 0, size: 1, configurationValue: [4])
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:30 AM: info [DTH] parse() - returning result=[name:lock, data:[lockName:Front Door Lock], value:unlocked, descriptionText:Unlocked, linkText:Front Door Lock, isStateChange:true, displayed:true]
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:30 AM: trace [DTH] Executing ‘zwaveEvent(DoorLockOperationReport)’ with cmd = DoorLockOperationReport(lockTimeoutMinutes: 254, doorLockMode: 0, insideDoorHandlesMode: 0, doorCondition: 2, outsideDoorHandlesMode: 0, lockTimeoutSeconds: 254)
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:28 AM: info [DTH] parse() - returning result=[[descriptionText:Is associated, linkText:Front Door Lock, isStateChange:false, displayed:false]]
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:28 AM: trace [DTH] Executing ‘zwaveEvent(physicalgraph.zwave.commands.associationv2.AssociationReport)’ with cmd = AssociationReport(reportsToFollow: 0, maxNodesSupported: 2, nodeId: [1], groupingIdentifier: 1)
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:22 AM: trace [DTH] Executing unlock() for device Front Door Lock
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:11 AM: trace Found Schlage
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:11 AM: trace Found Schlage
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:11 AM: trace Found Schlage
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:11 AM: debug Getting Sensitivity Level, current Alarm Mode forced
53ec4eb8-a0b9-4af7-9513-30d2cecaaa77 10:02:11 AM: debug Getting Alarm Level

#2

Haven’t done anything with locks so not 100% what is available.

Maybe just trigger the piston when the lock unlocks, then check to see which code was used

#3

Are you calling this piston from somewhere else? There is not a lightening bolt in the left margin, so it does not appear that this piston is triggered by Lock 1 unlocking. However, if this piston does trigger on Lock 1 unlocking, then this piston will execute each time the lock is unlocked, no matter how that was initiated.

#4

I think he took the screen shot in editing mode.

#5

You can turn your log level to Full right below the piston.

pic

Please Clear the old clutter, set Logging level to Full, and test your lock. All events and details will show right below the piston. (also, if you turn on Trace, then the numbers will match your log numbers)

#6

I think all programatic events default to lock #1. If you want to differentiate, try using lock #2 (code #2) for the one of interest.

#7

I have 4 codes set up on the lock and the trigger works right for the 2nd code using lock #2

#8

The ‘gets’ comparison should be looking for the lock attribute being ‘unlocked’ and the device index (derived from the ‘usedCode’ in the event data) being ‘1’.

The ‘usedCode’ should be available as as $args.usedCode and the ‘device index’ as $currentEventDeviceIndex so it would be useful to know what they are when things aren’t working as you feel they should. This might be revealed by a full log of the piston run as described by @WCmore, otherwise they could be ‘logged to console’.

I do have a concern that if ‘usedCode’ is an empty string (it shouldn’t be) or a null (perhaps more plausible), the ‘gets’ looks like it would give a positive match. It looks like if ‘usedCode’ is one of those two values, $currentEventDeviceIndex would be set to 0, so if it is, that might be where things are getting interesting.

Looking further into the code, it seems that the above might not actually be relevant because it rather looks like the index will probably be set to 1 earlier, which is pretty much what @guxdude said (just to be clear, it is webCoRE doing this and it seems inconsistent with the attempt to set $currentEventDeviceIndex to 0).

As I am getting increasingly tied in a knot (this is about my fifth significant update of this post), I am drifting to the conclusion that if you are interested in code #1 you probably need to see if $args.usedCode actually exists and is set to 1, or you might perhaps look to see if there is other diagnostic data such as $args.type (?) which might indicate whether the keypad was used.

#9

Yes, that was my experience as well. That is why I said if there is one in particular you are interested in, switch it to lock #2. If you want something different for each code, I suggest leaving #1 blank as it seems to be the default ‘lock’ for any other actions.

#10

I was able to use a separate code and worked fine, this only fails to act properly with lock codes 2 and over…