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.
1 Like
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...
1 Like
@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.
1 Like
I'm wondering about best practices with the HE nodes..
When I have a motion light activation or any kind of timer situation when doing the resulting command is it better to test whether or not it's already on or off first and bypass if so OR just go ahead and do the command?
On the one hand you send less commands to HE on the other if the device node gets out of sync the sequence might not work properly / be able to recover by itself.
For timers and motion I'm not sure there is enough traffic to cause issue with HE so maybe a good idea not to test and force an on/off..
Anyone have any thoughts on this?
I think you hit the nail on the head in identifying the tradeoff. I have never seen it get out of synch so I wouldn't worry about it for anything with significant volume of interactions, but because the likely volume is so low, the belt+suspenders approach of sending it without checking shouldn't hurt.
1 Like
I pretty much always test 1st. I haven't seen node-red status getting out of sync being a real problem for me.
But I would agree that not checking would work around the sync issue completely. At the expense of more maker API traffic (which really isn't a big deal) and potentially more zigbee/zwave traffic (depending on how the driver is written).
1 Like
I have a couple of z-wave locks that never seem to be synced, so I never test their states.
1 Like
You know, I said I pretty much always test first... That is true on lights/vents, but isn't true on door locks. On those I intentionally don't check and just blast out the command regardless, even though my zigbee Kwikset locks are basically perfect in reporting status.
There are only a few scenarios where I lock/unlock automatically, so figure it is cheap protection from (a very unlikely) out-of-sync case.
The more I think about it, outside of initial reboot/initialization cases where sending commands blindly COULD be quite chatty/mesh-impacting, it is probably fine to not check status on almost all automations I have, as they are low frequency.
EDIT 1: I would have to think more about the reboot/initialization case, though. That could be ugly blasting out 50-100 commands at once, plus the added load from the corresponding report back from those devices.
EDIT 2: One thing I did on SOME of my automations is randomize the initialization on startup to distribute the load. If I were going to remove all checks before sending commands, I would likely make that a standard thing I do to cover the initialization case. And I would likely make the random more like 30s instead of 5s.
Just food for thought. 
2 Likes
I am curious, why trigger multiple calls per device for startup status instead of getting the all accessories status and the breaking that out as needed?
Myself, I am planning to move all status into MQTT and really saw the value in doing that way when I moved from getting 15-20 different attributes from an Echo Speaks Echo device down to just a single request. It still may make sense for me to introduce your randomization as this is what my startup looks like at the moment (this is largely 1 example of each type of device I have):
1 Like
Because it is a LOT more work (my opinion) to us the 'all' attribute and break it all out if you only care about 1-2 of the attributes on a device. If I were pushing out all or most of the attributes, then, yes I would use the 'all' attribute.
Also, @fblackburn what does a single device node with the "all" attribute specified do on initialization? Add every attribute to the cache, add none of them, other?
If all of them, then yeah that would be a good way to initialize if using a lot of attributes on a device.
