Yah ... I am not the one to argue that point. 
Not sure about that. He's got so many drivers to write that he was probably like "just live with it for a while".
so is there anything special I need to do to get only one message to play per activity? I've now managed to overthink it.
As you can see, with the generic zigbee lock driver and a kwikset lock, the unlock command contains which code # as well as the actual code in the msg.payload.data field:
Are you using the websocket or webhook node-red node connectivity method? I do know that there are different fields reported to node-red between the two.
My example above uses the webhook method (I only use webhook on all my production hubs as it is simply more reliable, and 100% supported).
Websocket reports less stuff, and in different formats, so if using websocket it might be worth switching to the supported webhook method and seeing if the results differ.
For the record, you can use both at the same time - just make 2 config nodes and set one up one way, and the other the other way.
No idea. The thought came to me when I wondered if the door had locked after my parents left and realized that there's not an announcement for auto lock and realized why I hadn't done it. In RM I had separate announcements and it drove me crazy, so I delayed setting that up until I could consult with someone that can make a problem like this look "trivialL. I'm so glad someone can.
Don't underestimate how much I appreciate you guys.
OH ... I'll check
Webhook
Weird, I guess it is a driver difference then.
As an example of webhook vs websocket differences, on websocket here is what I get on an unlock on the exact same lock. Note, no code info at all. Which, again for others, is why I strongly recommend using webhook by default, and websocket only if you have a specific reason to (and even then only on the specific devices you have the need for it on)
I assume that means if you look on the device events in hubitat that the lock/unlock events don't have description text there either?
Here is what mine look like. Note that the unlocked event text has the code used in it:
Being able to key on the description of the "lock" messages would certainly simplify the task. No requirement to even monitor the "lastCodeName" for the alert.
Yes, that would make this trivial.
Otherwise, just drop the requirement for reporting the code used?
What is on the advanced tab? That is really the main way to tell if you are using websocket.
But there are different people coming in and out at different times so I'd like to know who is here. Especially when I'm not. I thoguth that was the only way to do that?
1 Like
Fair enough.
Well, you may be able to use the event TYPE (digital or physical). If the event=physical is only done on manual lock/unlock use (you would need to verify that) then use locked/unlocked + type=physical to go to the function node for manual events.
Then use the lastcodeused event only for code based events (assuming that all of those lock/unlock are of type digital)?
But again, you only get the physical vs digital info if you are using webhook - it is not in the websocket event types.
um .. my gears are turning. Then could I just use boolean and not put this in a function at all? Cuz I'm terrible with functions and the syntax.
Well, you have to build that alexa payload somewhere... Could definitely be done w/switch + change nodes, though, instead of a function node.
But first you need to get the events showing all the data. I don't see a "type" in the events you posted above, which still makes me thing you are using websocket.
I believe (didn't double check though) that every webhook event should have a msg.payload.type field (evenn if it is blank).
The easiest place to tell for certain is in the node-red config node (where you were earlier) on the advanced tab (note the "use websocket" option):
OHHHH ... yep. Will I break things if I uncheck it? Someone told me to check that box. Being a total noob, I did.
Maybe / maybe not. Usually not, but...
The other thing you can do is setup a second config node, and set it up w/webhook. You can have multiple config nodes pointing to the same hub. I do this when testing websocket all the time (and then I delete the extra config node when done).
nah ... I'll uncheck it
why the heck not? Need a little color in my life from time to time.
2 Likes
