And if you know what the variables should be there is the config node. It always runs before all other nodes, Sonos really handy for populating variables.
But again, since it runs before all other nodes, it is only useful for variables you know the value of - not useful for ones that you need to store the result of another node.
I'm hoping some of the experienced Node-Redders on here can help me with this please.
My NR interface web page has suddenly started being very sluggish to the extent that even scrolling up and down within a flow tab takes ages. I've tried restarting node red but that hasn't helped.
Over the last couple of days I have been testing various "-contribs" and then removed any I don't want so I guess I could well have left something partially un-installed.
I looked in the browser console and have these error messages. As they refer to 0/1/and inject.js I guess they have to be to do with NR, but I have no idea how to sort out the errors.
Help please!
Update. I don't know if this is symptom or cause but my Hubitat nodes have stopped updating too.
Update 2. Turns out the errors in the browser console were a red herring from a password manager extension and nothing to do with NR.
I have now exported and then removed my "motion lighting" nodes in NR though as I seemed to be having issues with all of the sensor nodes updating from Hubitat. Since I removed them NR is back to it's snappy best. I will try putting them back one by one to see how it goes.
I presume others are using motion sensors from Hubitat to NR without any issues?
Replace "==" with "===". FWIW, here's a function that works for me:
if (msg.payload.currentValue === "active") {
msg.payload = "stop"
} else {
msg.payload = "false"
}
var newmsg = { topic:msg.topic, payload:msg.payload }
return newmsg;
AFAICT, that's the only difference between our functions ..... (I also don't use two outputs, but that's not relevant).
Edit:
Here's a sequence with a function indicating how a single output can be used ...
[{"id":"8bf2f6aa.42c95","type":"hubitat device","z":"6a24e889.3323f8","name":"Virtual Motion Sensor","server":"a22e0ea9.276dc8","deviceId":"1314","attribute":"","sendEvent":true,"x":230,"y":440,"wires":[["75d025fd.65af9c"]]},{"id":"75d025fd.65af9c","type":"function","z":"6a24e889.3323f8","name":"Test Function","func":"if (msg.payload.currentValue === \"active\") {\n msg.payload = \"stop\"\n} else {\n msg.payload = \"false\"\n}\nvar newmsg = { topic:msg.topic, payload:msg.payload }\nreturn newmsg;","outputs":1,"noerr":0,"x":500,"y":440,"wires":[["5c34cac2.94824c","3a09c14d.3df246"]]},{"id":"5c34cac2.94824c","type":"debug","z":"6a24e889.3323f8","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":750,"y":280,"wires":[]},{"id":"3a09c14d.3df246","type":"stoptimer","z":"6a24e889.3323f8","duration":"45","units":"Second","payloadtype":"num","payloadval":"0","name":"","x":770,"y":440,"wires":[[],[]]},{"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"}]
@JasonJoel, @dan.t
I noticed a lot of function nodes being used in cases where a combo switch/change node would accomplish the same thing. When I was learning NR there were many references to avoiding use of functions as they added a lot of unnecessary overhead. In cases where advanced logic is needed, they should be used but, if a few smaller built in nodes can be used, they should be avoided.
These references were old posts but they strongly influenced how I create my flows.. I use function nodes sparingly and only in scenarios where using the built in nodes would just be too complicated. Do you think this is still good advice today?
There is definitely some overhead with function nodes. I think it all depends on what the flow is actually doing, how many messages you push through, how many flows you have and what you do in the function itself. I think in the big scheme, the number of function nodes are always less than the other nodes you use. But technically and bottom line, you will get the biggest bang for the buck if you use built-in nodes instead of function nodes.
Here is an interesting article about that topic:
https://groups.google.com/forum/#!topic/node-red/v6luhAc1kKU
EDIT: Something to keep in mind.. If I need 10 builtin nodes to represent what I can do in a "simple" function node, I might not achieve any performance improvement. Again, to me, apply common sense... If a single builtin node can do what a single function node can do, go with the builtin node.
One thing that I read if you use a lot of debug nodes it will slow down node-red.
Do you see any weird activity in the Node-Red logs? Not the debug output, I am talking about the NR log file
Thank you for that link. I have been assuming that the rate limiting step in a sequence is the number of nodes a message has to pass through. That was clearly wrong.
I had a few but mostly they were turned off, but I've now deleted them all just in case.
I didn't check at the time (I've only just learned how to view them, to be honest) but will add back one of the motion light nodes and see if anything odd happens in the logs.
Wanted to say thank you! Figured out how to create/use/delete context variables this morning. Perfect for many of my needs.
Thank you for pointing me in that direction.
Hi Guys,
is there a simple way to check status of a device? what I'd like to do is, e.g. if switch 1 state is currently on, then I'd like a notification to be sent to google hub nearby to that switch.
I understand that the device will only give out payload when you trigger something / when an event gets generated. I'm wondering if there's a way to regularly (interval based) checking the status for a particular device.
Cheers
You can modify the attached flow for your needs. It will generate switch status 15 seconds after NR startup and then every 30 minutes after that. In this particular case, the output is saved to a flow variable, but you can do something else with it - like use it for TTS.
[
{
"id": "a960330f.bcf398",
"type": "inject",
"z": "6a24e889.3323f8",
"name": "15 secs",
"topic": "",
"payload": "",
"payloadType": "date",
"repeat": "1800",
"crontab": "",
"once": true,
"onceDelay": "15",
"x": 160,
"y": 160,
"wires": [
[
"bf427e0e.e4dae"
]
]
},
{
"id": "bf427e0e.e4dae",
"type": "function",
"z": "6a24e889.3323f8",
"name": "Switch Status",
"func": "msg.attribute = \"switch\"\nreturn msg;",
"outputs": 1,
"noerr": 0,
"x": 372,
"y": 40,
"wires": [
[
"a406b60a.f997"
]
]
},
{
"id": "a406b60a.f997",
"type": "hubitat device",
"z": "6a24e889.3323f8",
"name": "Vacation",
"server": "662851c4.3ccad",
"deviceId": "105",
"attribute": "switch",
"sendEvent": true,
"x": 540,
"y": 40,
"wires": [
[
"dd84d887.56cb3"
]
]
},
{
"id": "dd84d887.56cb3",
"type": "change",
"z": "6a24e889.3323f8",
"name": "save Vacation status",
"rules": [
{
"t": "set",
"p": "vacation_status",
"pt": "flow",
"to": "payload.currentValue",
"tot": "msg"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 741,
"y": 40,
"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"
}
]
For anyone interested: Thanks to @fblackburn creating this wonderful integration, you can now tie Vera to Hubitat or vice versa.
I've been disappointed that I have this $300 VeraSecure just sitting there collecting dust from my move to HE and had no way of using it for anything other then a really expensive UPS (has a 4 hour backup battery) for my Hubitat hubs, especially at a minimum since it has a built in very loud siren that I would have liked to include to my home automation, among a few things that Vera does better than HE.
I never wanted to try and run two different platforms independently as that is to much of a hassle. I held out hope that someone that came from Vera would try and get HubConnect to work, but that so far is still wishful thinking.
Now it is possible to tie both platforms together, I've tried it with one sensor on Vera controlling a device on HE and it works. Although the person who created the NR integration for Vera is pretty basic and didn't do the extensive work as @fblackburn has and it is a bit more tricky to get devices to communicate on Vera's end, but if you read their forum on node red you can figure it out.
Thank You again for your awesome work making this happen this has opened up so many doors for me that were previously closed in my goal for home automation!
thanks @aaiyar, unfortunately, this is slightly beyond my node-red skill 
i'll tinker around and I'll let you know how I go! thanks!
another question, rather on a tangent here.
is there a way to have nest hello link to HE somehow? I was hoping to be able to link it then to node-red?
I've looked around and looks like homebridge was mentioned, as well as hass.io.
given that I've got pretty much an android house, what would be the best recommendation?
Thanks
Have you looked at this?
Hi @JBrown!
No actually! I'll look into this straight away!
Cheers!
EDITED: looks like it has been retired. only works with non-migrated nest account and I can't because I have migrated to google 
Built in nodes are preferred in general. I never use a function node if less than (approx) three built-in nodes will do the job.
So for something that a normal switch plus change node would do, I would not use a function block.
Now, if it would take ten nodes to do the job, then I'm using a function node every time.
Functionally, is there really any difference in Node-Red between a global variable and a flow variable? Seeing as there is a requirement to have connectors between all nodes, and with link in//link out we can span pages and flow?
Flow variable = accessible inside that flow only
Global = available in any flow
This video explains it well
Have you guys discovered the Bigtimer node? It lets you practically do anything as it relates to timing with time, days of week, month of year, etc. You just have to insert a change node in between to convert msg.payload to msg.command for Hubitat Command Nodes. It's a great compliment to the Hubitat Nodes.
node-red-contrib-bigtimer
Download the Hubitat app
