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
USUALLY it is fine. But since the message structures are slightly different (depends on the device) it could break things.
Most of the most commonly used message structure is the same, though, so should be OK/mostly OK.
1 Like
I just LOL'd
I ... unchecked it. I'm going to walk around the house and see if I've broken anything. Most of my flows are on the less complicated side simply because I don't know how to complicate things yet.... yet.
Well, it isn't brain surgery. If it breaks a lot, you can always just re-check it. 
1 Like
seems ok after restarting node red. I was needing something to tinker with later anyway. so, moving on. I should check my lock messages again now?
I would. Should look a little different (should match the hubitat device event, plus have a few extra fields like type).
checking ... stand by
Seems it might have broken some communications here. Locks don't report to nodered. I'll be a few minutes to see if this sorts out.
