This has been reported earlier in this (very long) thread.
Many, maybe most, motion sensors go back inactive and then active again. Some, like yours, don't. So those need different logic.
I have both styles in my house, and have node-red flows for each style. I could share a flow example if you want.
OK. At least now I know I wasn't really doing anything wrong; I was just dealing with a different device behavior.
I was actually thinking that Node-RED probably deserves its own category by now 
This thread is pretty monstrous already. (And I wouldn't be surprised if this has already been suggested, too!)
Sure! Since I'm just getting started, I'm open to seeing alternative ways of doing things
Here you go. It is more or less the same as yours above.
This one uses an Ecolink motion sensor. Those stay active continuously if motion does not end within the timeout (which is a super long 4 minutes by default).
The basic idea is that you don't start the OFF timer until it goes inactive. And you STOP the delayed off timer if motion becomes active again.
It checks the current status of the lights, and doesn't try to turn them on/off if already on/off. Could also be done with a change node to set the msg.command, an RBE node, and a single command node. I find two separate paths cleaner/easier to read though.
It also will not allow the lights to turn off if the TV is turned on. Just ignore the "Roku TV Arcade" and next "on/off" node for your case.
Cool. Looks like I ended up with pretty much the same design. I realized after posting, that a couple of my node names probable weren't the best/clearest, so I changed them and re-organized things a little. Here's how my sequence looks now:
If your flows use the device nodes to get device status from HE to NR, you may have gone through some of the evolution that I have in how to use them. At first I used them strictly to get a single attributes status. This meant that when I cared about multiple statuses like a bulb’s switch state and a bulb’s brightness state, I had 2 separate nodes.
For playing roles in various flows this is often worthwhile, but if you are trying to collect a lot of data (for MQTT or Tables or InfluxDB), this can get quite tiresome and if you get it at NR startup/deploy it can really hammer your HE with requests. Thus, I was excited to start using the all entry for the attributes field of the node. This way I can get all the attribute information in one place.
The drawback I found however is that an all attributes device node sends 2 different formats of information depending if it was triggered or if an event occurred with the device. When triggered it sends an object containing an object for each of the device’s attributes. This is an example for my 2 attribute Floor Lamp Bulb:
Whereas an event triggered output has a payload with an object with details of the attribute that changed. Here is an example of the switch in that bulb changing:
Thus, to get all of this information, I had to set one node to not send events and have it triggerable via injection and set one node to send events but not to have it triggered. As a result a sample flow looked a bit like this:
And since I wanted to put all of the information into my database, I had to build 2 separate processes to handle the 2 types of inputs. The one getting the multi-object input as shown in the first image had to parse out N-number of individual inputs
So I decided what I really wanted was to be able always get single object status/event, but still have access to the multi-object if I ever wanted it. To do this I created a function node that pairs nicely with a device node that can be triggered manually, but that also sends events. Here is the flow from above with that function node:
If anyone is interested here is that function node ready to be imported:
[{"id":"18e80edf.fadfd1","type":"link out","z":"27566e75.091d22","name":"Do stuff with Multi-Attribute Objects","links":[],"x":820,"y":200,"wires":[],"l":true},{"id":"22cbbbf2.21e404","type":"link out","z":"27566e75.091d22","name":"Do stuff with Single Attribute Objects","links":[],"x":830,"y":160,"wires":[],"l":true},{"id":"719c2698.0d8118","type":"function","z":"27566e75.091d22","name":"Split 2 types of device node outputs","func":"var singleAttributeData = false\nvar foundType\nfor (let [key, value] of Object.entries(msg.payload)) {\n foundtype= typeof(value)\n if ((foundtype==\"string\")||(foundtype==\"number\")||(foundtype==\"boolean\")){\n singleAttributeData =true\n }\n}\nif (singleAttributeData){\n node.send([msg,null])\n} else\n{\n node.send([null,msg])\n //interate through the objects in the input\n for (let [key, value] of Object.entries(msg.payload))\n { \n msg.payload = value\n node.send([msg,null])\n node.done()\n \n }\n}\nreturn","outputs":2,"noerr":0,"x":480,"y":160,"wires":[["22cbbbf2.21e404"],["18e80edf.fadfd1"]]},{"id":"65749fae.88073","type":"link in","z":"27566e75.091d22","name":"Get Input from Device Node","links":[],"x":180,"y":160,"wires":[["719c2698.0d8118"]],"l":true}]
Not that anyone is waiting for it with bated breath, but I am also working to redo my earlier post where I shared a few function nodes that I might be helpful if you are sending HE info to MQTT or InfluxDB. I messed up the formatting on the old one and so prevented anyone from using the code.
No matter what you would need 2 different parsers, but couldn't you have just run the single node that spits out triggered and event payloads into a switch node, and did a quick "has key" check on msg.payload.value to pick the path taken?
Not a big or real functional difference. Just asking.
I was replying when I saw your revision with the screenshot. You are correct I think your switch node solution works equally well.
I was just thinking to myself whether there was a way to do it in 1 device node instead of 2. Again, not that it matters in the least. Either way should work fine and there is no appreciable loading or other difference.
Purely an academic question. 
1 node either way (function or switch), but as always NR shows there are infinite ways to skin a cat. I hadn't explored all of the switch options always focusing on the == option only. Thanks for the pointer to look at it more deeply.
Exactly
Not really with the current implementation (webhook).
But all depend on what you mean with webhook action failed? If it fail before that NR receive it, then nothing can be done if we don't have information. If it fail after, well it's a bug in the nodes and must be fixed 
Adding an heartbeat would break webhook concept. If someone need this resilience, it should just listen events directly through the websocket.
Anyways, I still not have seen a webhook failed (from HE), so no need to worry. And local network should not be an issue. If it's a real issue, maybe exploring the HE websocket would be an option, but it would add other consideration/issue
Please explain the "has key". I never noticed that before.
The "has key" operator in the switch node does exactly that. It checks to see if whatever message.parameter you specify has a key named whatever other value you specify.
it is a very handy way to check if a certain parameter exists in a data object.
The screenshot above is a good example. It checks to see if msg.payload has a msg.payload.value key. If it does go out #1, otherwise out #2.
One of these days I will master pasting in the code like this. I have fixed it in the original post. I tried checking by round tripping it from the post back into NR.
let me know if it doesn't work this time.
Looking for an existing node. I know how to do this with a function node, but is there an existing node that takes in a msg and outputs that message on 1 output and a copy(clone) of that message on another?
This is what the function node looks like:
It sends along the original msg to the first output and sends the msg to the second output if the boolean msg.translate is true.
There's no single node that can do this that I know off. But you can accomplish this using two change-nodes and a switch node.
I am having a hard time envisioning that. How would you do it with those 3?
Not related to my function question.
Any idea about this warning?
I am probably missing something obvious so apologies but I think your function node above could be rewritten like this?
What am I missing? 
Edit: if you want to trap the null msgs then maybe something like this with 2 change nodes like @aaiyar said...
@aaiyar and @erktrek you are both right. I had gotten fixated on the split happening in my single node, that I realized nothing prevented the split from happening coming out of the earlier part of the flow just as @erktrek showed.
I in fact realized that almost as soon as I was lying in bed last night and woke to find the example you made clearly illustrating the answer. Thanks as always.
Download the Hubitat app
