@aaiyar @csteele Thank you both! I looked at the options you both sent and was able to easily implement a template to do what I needed. Looking for any efficiencies I can across my Zigbee networks.
1 Like
you should be able to do it with a single JSONata expression. here is an example of a global and a flow variable being combined.
edit:
as an aside, I usually string together two nodes for this because I reuse my global color temp nodes, then I just add on the desired level to the argument:
edit2: just as a note, the 3rd number in the setColorTemperature argument is the fade rate. I often use the above method to append different fade times depending on how the node is triggered. for example, when the lights turn on when a movie is stopped vs a motion trigger (the pictured example is a setLevel command, which only accepts 2 arguments, not 3).
2 Likes
Oh indeed, it could be a nice to have
I don't know when I will have time to do it, but I added to the enhancement list (github issue)
Can you point me the built-in node that support this?
2 Likes
Template node is the most obvious one, with its mustache syntax documented here:
https://mustache.github.io/mustache.5.html
I'll look for other ones. I know other nodes support it, but I need to go look which ones. I was probably too glib in saying "many" of them support it - more truthful is likely "a few" of them support it, like the template node.
It gets a little confusing/technical because some nodes that use angular also support a mustache-like substitution, that isn't actually mustache (but likely good enough for what is asked for in this thread).... Like the Dashboard.
And here is a related thread about people wanting to add it to the Change node, which they did NOT do and instead did more js-like substitution, with some decent feedback from the devs:
1 Like
I'm having a reliability problem with NR calls to HE.
For instance, a have a Virtual Button set up via NR to turn off all the apartment lights, 35 circuits in total.
When clicking it, almost always 1 to 4 random circuits remain on, if I click it again, normally the remaining circuits are turned off.
The debug nodes on NR show that the offending command nodes are getting the messages as expected, so the problem is not in there.
I'm only using NR. Rule Machine and other rule apps, native or otherwise are not even installed.
I might be wrong, but it seems to me that some requests to the Maker API endpoints are failing and NR integration is not aware.
I have changed to websockets to check if it would solve the problem, but the result was the same.
Is there a way to debug the HTTP calls?
I had a similar issue. It was very intermittent. Sometimes all lights would turn off other times just some.
I put it down to the network being flooded with commands.
I solved my issue by separating the devices into groups depending on location. Bedrooms, bathrooms, lounge etc. etc.
By putting in a delay between each group it now works flawlessly.
i.e.
Button pushed.
Turn off lounge
Wait 1 seconds
Turn off dining room.
Wait 1 seconds.
Etc
Etc
You get the idea.
Might be worth a try. 
3 Likes
I put it down to the network being flooded with commands.
It shouldn't be a problem. Some web pages make hundreds of http requests on first access, and they are not even to the same network.
But what you said makes sense, I have some other actions involving less devices, and those are working flawlessly.
Probably HE has a low limit on the number of http connections 
In my view it should be solved on NR nonetheless, if a request fails, send it again.
For now I'll try your suggestion, thanks!
That and/or the difference in resources between a PC and the HE hub. Either way I think less calls being made is the way to go as well. One other benefit you may be able to get is group messaging or some other approach to being able to issue the commands to each of the lights in a timely manner from HE, rather than controlling them individually with separate HTTP calls from NR.
While a LAN connection (WiFi or Ethernet) is measured in MB and GB, the Z-Device (mesh) networks top out at 250KB and as low as 9.6KB. It's the mesh network congestion that needs pacing.
2 Likes
That too, that would make sense if the lights miss data being sent while dealing with a flood of data.
That would probably solve the problem, if they are really related to the HTTP requests.
But even if they are simple, I'd like to keep 100% of my rules on NR, for visibility and maintainability.
It's the mesh network congestion that needs pacing.
I have the impression that the mesh (Zigbee in my case) is more resilient, resending messages that fail until they are successfully delivered.
I also have all my "rules" in Node-RED and had a similar issue. What I did was to add a step to check the status of the device and only send an "off" command if the device was on. I also created "groups" for my zigbee lights (e.g. downstairs, upstairs etc.) I have about 18 lights ( 6 zigbee, rest z-wave) and 2 locks (z-wave) as part of this automation.
While the lights don't all go off simultaneously (all go off within a minute or so), I haven't had an "orphaned" light in quite a while.
Also, before Node-RED, I had a similar routine in HE rule machine (C-5) and it had the same behavior as what you are seeing, so it's not just Node-RED.
4 Likes
I would need to dig deeper, but yes HE doesn't like too much requests. I needed to throttle request (see technical readme
Maybe you could change to one simultaneous request here directly on the installed files.
I'm not available to make more tests now, but definitely interesting that we still have this issue. I would worth to give a retry investigation
3 Likes
Changed locally to 1 request, I'll see how it goes and report back here.
1 Like
Don't forget to restart node-red after the change
I know most HE folks with think this is sacrilege, but my solution to this problem was to call an Alexa routine. But, it's processed locally, so not totally evil. 
Could you expand on this? How are your Alexa routines processed locally?
Yeah, I suppose I should have expanded on that a bit, since it's not as straight forward as it sounds and it's a real PITA to set up. I use three different nodes to achieve this:
node-red-contrib-alexa-remote2-applestrudel
node-red-contrib-amazon-echo-oztourer
node-red-contrib-ecolect
It's a complicated dance to say the least, but it involves using oztourer to get specific Alexa device info, applestudel to create Alexa "routines" in node-red, and ecolect to process natural language locally for the Alexa commands. You can also use the Alexa Q&A skill, but that uses the cloud as far as I know. There are also some function nodes involved. I'd suggest looking over this post in the node-red forums for more details:
Pure fun with Alexa and Alexa Skills
There's a lot going on, but basically, node-red does all of the heavy lifting, but Hubitat ties everything together locally. If you decide you want to go down that rabbit hole, I'd be happy to share what I've learned over the past few months of tinkering.
