If you want it variable/not pre-slecified then put the value in msg.arguments on the incoming msg. Usually done with a change node or function node.
Otherwise just type the number in the arguments field of the command node.
Holy Smokes, my motion lighting is RAPID at last! I'm still mostly in test mode on a couple of rooms, taking my Xiaomi motion sensors and pinging the actions from NR straight into Hue where I've now put all my lamps, rather than via Hubitat. It is like LIGHTENING! WOW! And my NR is just running on a Pi 3b. I really cannot understand how HE can be so slow in comparison.
Still working on getting my circadian lighting routine over into NR too, which will take further load off HE.
Very impressed with NR so far. Granted it's another system and device now to manage, more opportunity for failure. But it's clearly worth it.
3 Likes
You configure your message in a function node and send that to the blue pushover node
As for the configuration node....
Your User Key goes under User (Obviously)
For the token you need to create an application (you probably already did this if you setup pushover in HE), then if you click on your application it will give you API Token/Key.
All of that could be done with a Change Node instead of a Function Node correct?
I'm trying to switch from RM to NR and having trouble with a presence rule. I want the flow to lock all doors, but only after both my wife and cell I have left (cell presence). I think I have spent about 2 hours on something that has to be a simple fix.
Part of my problem is I could be trying to do too much on one flow. Maybe I should break up the coming and going sections.
Any ideas?
Here is what I have so far. (bottom part is latest attempt, but not working right)
The easiest way to do an "AND" with a small # of device is to daisy chain them. Note that you should UNcheck the "Send Events" checkbox on the device nodes in the "checking" chain (as shown in my picture below with the "hollow" symbols under the device nodes.
Here is an example with 5 presence devices I use to set mode to "away" (I have multiple hubs, thus multiple away nodes at the end):
When I have a small # of devices involved I do it as shown. If I had more then I would do something more exotic like store the presence status in variables and check them all at once in a function node, or maybe use one of Cobras apps or RM to toggle a virtual device "any home / all away".
1 Like
back to the pushover issue - sorry i sounded like a sh1t earlier. Turns out that there are significant differences between the two available nodes.
If I want to send the message using what is in the description text, how is that formatted into a message?
So if mode changes, it sends what mode it changed to in the description text. So I would only need to set up one sequence to cover all mode changes.
Change node like this after the mode node and before the pushover node (you may need more fields to specify the other pushover fields, as needed as shown 3 or 4 posts before your last one):
1 Like
OMG - I tried everything, but that. That worked and gave me a better understanding of how this works overall.
Thanks!
1 Like
I'm not gonna lie ...
I still want your pool.
1 Like
The water is a balmy 91F right now. 
While that is too hot to get in when it is 100F outside (feels like a bathtub), I find that it is actually good for evening swimming after the sun goes down and the humidity drops (one nice feature of San Antonio vs Houston - much lower humidity).
1 Like
Lol I was in San Antonio for a respiratory convention a few years back.. If that is low humidity I'm never going to Houston.
I live in California. I know heat. But that humidity is a whole other beast.
Does anyone know the best way to store a list of devices which are on, so I can turn them all off when I go to bed? I used to do this in webCoRE very easily, but cannot think of a good way to do it with NR.
Any tips appreciated 
Humidity is 28% out right now (and 99F). 
40%-60% is more average here though. It peaks at maybe 90% in the morning when close to dew point and drops throughout the day until night time when it climbs again.
1 Like
There are a few ways people do this - none of them are what I would call easy though. Could have a an event node going into a function node, and then make a global variable that contains a list of all lights you would want to turn off, then iterate over it in the function node when you want to turn them all off (you can override the deviceID in a command node) - for example.
Another way is you could have a gigantic flow with a device node for each light, then at bedtime start a message that goes into each of them, then a switch node checking if on/off, then if on to a command node.
I gave up on the 4 or 5 workarounds I tried, and just made a hubitat group with my bedtime lights in it, and turn that off.
Thanks, some food for thought there 
Currently, I'm just turning everything off, which could be on. I'm not sure what affect this could have, firing out all those commands, when basically it could be just two or three things which are actually on.
My hub does not seem to be updating node-red unless I "Deploy" or otherwise refresh a flow.
I do have this set, which looks correct. What am I missing?
Well if you are doing that, an easy way to reduce loading is to put another device node and switch in front of it checking if it is on/off.
The device node only checks against the node-red cache (it doesn't go poll Hubitat) so takes zero hubitat loading to do.
Make sure you UNcheck "send events" on the 'checking nodes' though.
Example:
2 Likes
Ah, so check the switch for each before firing off the command! a lot to add, but its worth it! Cheers for that.
2 Likes
