Hmmm… an unfortunate side effect!
Perhaps try removing the double change in the code and replacing with
sendEvent(name:"webCoREPush", value: "$dateStamp")
That way it will only change once, to something unique.
Or add an extra condition to ignore the second event:
On event from Zipato Switch’s webCorePush
DO
IF
previousAge([Zipato Switch : webCorePush]) is greater than 2000
THEN
Do stuff
The above will not fire for the second event if it occurs within 2 seconds
Sure.
But for my own edification, what’s actually going on here? Somewhere the event is getting ignored presumably because the state didn’t change. Any idea where that is happening?
It’s a custom attribute, so state is not being changed at the DTH side… nothing you can do to change that from webCoRE.
Yea, I figured there are three possible actors; DH, Smartthings platform, and WebCoRE.
So I see the DH sets the value in each case, so I’m guessing that means that the Smartthings platform is deciding that since the state didn’t change that no event needs to propogate?
Does that sound right?
If that’s the case I’ll probably just add some new custom property to record the timestamp of the last interaction (like what you have above) and call it a day.
Yes, would appear so. If you were trying to send a zwave command it would propagate, but not when updating an attribute.
You could potentially try the following, might force it to propagate through to webCoRE???
,isStateChange: true
sendEvent(name:"webCoREPush", value: pushNotifications?"Yes":"No",isStateChange: true)
Worth a shot if above fails.
Oh Cool. I assume I can add that to the property (switch) that I ultimately want to trigger off of?
You’ve lost me now lol… just try it out and see what happens with various combinations.
In theory ‘isStateChange’ should default to true when not stated, but I found it helped with a few of my handlers.
Yea, sorry. The switch (there is an event named switch) state is the thing I care about