The "else" looks a little screwy - also isn't it payload.value?
if (msg.payload.value === "open"){
msg.payload = "The Front Door Is Open";
} else if (msg.payload.value === "closed") {
msg.payload = "The Front Door Is Closed";
}
or just get rid of the "if" conditional of the "else if" and make it an "else"
Can't say for certain why it repeats, since we can't see the whole flow. But as @erktrek says, the else part is wonky. Can't have two sets of braces like that... I'm not even sure I understand exactly what you were going for there (maybe explain in more detail?).
EDIT: Ohhh... I think I get it now, based on erktrek's posted code. I didn't recognize that as an else-if.... 
@leeonestop
Alternatively, replace your function node with a switch node and two change nodes.
Do u have a device node with Send Events box checked prior to this function node by chance? That could cause a repeat in some cases. That little box has caused me more headache than anything else.
Here is my flow my light in the front hall works good and I was just trying to get notify that the front door is opening or closing? Thanks for the help.
I added the SonosPollyTTS palette, and created a flow you can import & modify for your needs. It only plays the message a single time.
There is no need for a function node. You can use your existing switch node (which turns on the light) and two additional change nodes (one for door open, the other for door closed). Set msg.payload in the change nodes to be the text you want spoken via Sonos.
[
{
"id": "7180dbe8.227cec",
"type": "hubitat command",
"z": "3009af18.2611a8",
"name": "Attic Light off",
"server": "662851c4.3ccad",
"deviceId": "4198",
"command": "off",
"commandArgs": "",
"x": 740,
"y": 760,
"wires": [
[]
]
},
{
"id": "e6866d9a.183a7",
"type": "switch",
"z": "3009af18.2611a8",
"name": "open/closed",
"property": "payload.value",
"propertyType": "msg",
"rules": [
{
"t": "eq",
"v": "open",
"vt": "str"
},
{
"t": "eq",
"v": "closed",
"vt": "str"
}
],
"checkall": "true",
"repair": false,
"outputs": 2,
"x": 530,
"y": 740,
"wires": [
[
"a49584b2.1eff",
"26dc73e6.8f6a24"
],
[
"7180dbe8.227cec",
"9b31952c.59c798"
]
]
},
{
"id": "a9e7950.53fd3e8",
"type": "hubitat device",
"z": "3009af18.2611a8",
"name": "Contact - Attic Door",
"server": "a22e0ea9.276dc8",
"deviceId": "388",
"attribute": "",
"sendEvent": true,
"x": 320,
"y": 740,
"wires": [
[
"e6866d9a.183a7"
]
]
},
{
"id": "a49584b2.1eff",
"type": "hubitat command",
"z": "3009af18.2611a8",
"name": "Attic Light on",
"server": "662851c4.3ccad",
"deviceId": "4198",
"command": "on",
"commandArgs": "",
"x": 740,
"y": 720,
"wires": [
[]
]
},
{
"id": "9b31952c.59c798",
"type": "change",
"z": "3009af18.2611a8",
"name": "",
"rules": [
{
"t": "set",
"p": "payload",
"pt": "msg",
"to": "The door is closed",
"tot": "str"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 750,
"y": 800,
"wires": [
[
"5d034f76.575b2"
]
]
},
{
"id": "26dc73e6.8f6a24",
"type": "change",
"z": "3009af18.2611a8",
"name": "",
"rules": [
{
"t": "set",
"p": "payload",
"pt": "msg",
"to": "The door is open",
"tot": "str"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 750,
"y": 680,
"wires": [
[
"5d034f76.575b2"
]
]
},
{
"id": "5d034f76.575b2",
"type": "sonospollytts",
"z": "3009af18.2611a8",
"name": "",
"voice": "0",
"ssml": false,
"sonosipaddress": "192.168.1.218",
"sonosvolume": "40",
"sonoshailing": "Hailing_Hailing.mp3",
"config": "a57893d5.3a977",
"property": "payload",
"propertyType": {},
"rules": [],
"x": 980,
"y": 740,
"wires": [
[]
]
},
{
"id": "662851c4.3ccad",
"type": "hubitat config",
"z": "",
"name": "HubitatS",
"usetls": false,
"host": "192.168.1.36",
"port": "80",
"token": "5dee560c-c42c-4e4b-bdf7-6bed1bb77371",
"appId": "4489",
"nodeRedServer": "http://192.168.1.4:1880",
"webhookPath": "/hubitat/webhook2"
},
{
"id": "a22e0ea9.276dc8",
"type": "hubitat config",
"z": "",
"name": "HubitatM",
"usetls": false,
"host": "192.168.1.46",
"port": "80",
"token": "496f7f11-256d-44c9-99c6-4ed460d3efb0",
"appId": "1522",
"nodeRedServer": "http://192.168.1.4:1880",
"webhookPath": "/hubitat/webhook"
},
{
"id": "a57893d5.3a977",
"type": "sonospollytts-config",
"z": "",
"name": "Config",
"noderedipaddress": "192.168.1.4",
"noderedport": "1980",
"purgediratrestart": "leave"
}
]
Why replace a single node with 5 (simple) lines of code with 3 nodes? That seems super counter intuitive.
I kind of get that "hey, it's all drag and drop and quick UI", but that is seemingly overcomplicating matters
Sorry, I'm just trying to see the angle of suggesting that, please don't take it as anymore than that.
The suggestion has been made several times that using the built-in nodes is much more efficient than using a function node. At one point @JasonJoel (or maybe @dan.t) indicated they use function nodes only if it replaces ~10 built-in nodes.
Edit: it was @dan.t in this post. There's a useful discussion linked to in his post.
This is interesting info. I was just reading a conversation about how function nodes have greater overhead due to the way they are sandboxed.
I'm using a VM so am less concerned about resources however best practices says I should be so maybe time to refactor some stuff.
Thanks for the heads up on this!
That post is definitely not saying a function node is necessarily slower
Like a lot of things, it’s all about context... in the specific example presented a few posts above, there is no way three nodes is a better solution over a simple string comparison in a function
Ah well, to each their own!
I'm no programmer - so I have no idea if this analogy is appropriate. But my (naive) perspective is that perhaps the built-in nodes are akin to pre-compiled binaries, whereas function nodes are run-time compiled.
It's really murky when you consider the backend is Node which is running cached bytecode which is kinda what the code in the function node would be ultimately converted to and then cached itself maybe. Must be the sandboxing overhead... something about the JIT compilation that things maybe get disposed of too quickly or too many instances get generated? Are function nodes in subflows more or less efficient I wonder.. interesting to think about.
We'll agree to disagree there. I'll pick 3 nodes that I can tell exactly what they do from the flow overview over code buried in a function node that I have to open to see any day.
But to your point - each to their own. There is no one right way to do it!
@aaiyar really appreciated your help and I have downloaded your flow and just wanted to say thank you. As you said i'm not a programmer but I try to learn but sometimes it's hard to understand all the ends and out of the nodes and the logic of it. Thanks to all for helping me and others on the forum we all appreciate the help we get from each and everyone here. Anyhow thank you very much.
How are you getting on with the NR Harmony integration? Any issues on NR re-start?
I would have to say this is mostly true - you still might have to go into the nodes to see whats really going on unless the sequence is simple or obvious BUT understanding the content of non-function nodes is MUCH quicker/easier.
Good practice to name your nodes descriptively - function or otherwise!!!!
Been working fine.
I wonder what's up with mine then?
I've just had another tinker with mine and once I get it going it's fine, but if it starts up about as reliably as a 1970s British Leyland car on a cold wet morning!!
The HE community driver works perfectly on the same Harmony hub so it doesn't feel like it's a hub issue.
Following up cause I find this interesting but apologies for the distraction. Found this older thread on NR...
Simple takeaway: You can run functions as "unsafe" by using "node-red-contrib-unsafe-function" palette and get much improved speeds..
On that thread "kazuhitoyokoi" provided an analysis:
He also created a cool tool that converts function nodes to custom nodes.
edit: I don't know if this has changed since the new release but the default switch node performance looks kinda bad relative to the other stuff.
Download the Hubitat app
