Node-RED nodes for hubitat

Speaking in Hubitat language, how do I distinguish between triggers and conditions?

I have a flow with motion (I think) as the trigger. In the flow are switches (mode and lux) that are from two posts above (flow.office_lux and flow.current_mode). I'd like the triggers (in Hubitat language) to be motion, illuminance and mode change. How would I accomplish this?

Here is the flow I'm testing with......it's not doing much now, except educating me. There are other parts of the flow that set the flow.office_lux and flow.current_mode

I've joined in with the "Hubitat Node Red" club running Node Red on my Pi 3. I have previously used Node Red under Home Assistant on the Pi and have noticed a difference that I'm not sure is settings related or something else.

When I was using NR with Home Assistant each of the node boxes used to have a line of text underneath showing the last activity/action and time e.g. "turned on at 10:26". That was really useful for checking and debugging flows. Running NR now with Hubitat nodes there is nothing showing there (with the exception of the Mode node which does show the current mode under it). Is that because the Hubitat integration isn't providing that data or am I missing a setting somewhere?

Great work on this integration btw, and some great knowledge on this thread which encouraged me to have another go with NR. :+1:

That is a function of the node itself and not a NR setting. Sounds like a good feature request though.

1 Like

Based on the commits in GitHub, Iā€™d say be patient, I think @fblackburn has something to surprise you with

3 Likes

The adder, as it stands right now, will show the last value but not time received/updated. There is very limited space, so he can't show everything everyone wants...

Regardless of final form, additional info in the status area will be welcome - although in my case I'll now have to go re-arrange about 75-100 nodes... I pack my nodes tight, so will now have to go back and space them out vertically. :confused: Worth it, though.

@JasonJoel @dan.t

BTW, late last night (while preparing for my class this morning), I finally got both of your point on how to use a stored value in a switch ......

Makes sense now. Thanks!

2 Likes

I don't know if it's overkill for you, but you can disable all node status in the node red settings:
http://www.steves-internet-guide.com/using-the-node-red-status-node/

And the device node status will only be shown when the device node will have a configured attribute (not the default)

I've tried that before, but don't really like that option either.

I'll get them all moved, not that big of a deal.

If Bruce adds digital/physical type indication to the Maker API events I will have a bunch of flows to rework anyway to catch physical switch presses and initialize/synchronize device states in node-red.

How would one go about TTS messages (particularly with Sonos) within Node Red?

I don't do tts in node-red, or own Sonos. But a quick Google search yields this, and a number of other links:

I don't have any Amazon AWS credentials (that I'm aware of) so I'll have to look at one of the other palettes.

I was assuming I would just use the hubitat command node with my corresponding sonos device on hubitat and use the command "speak". I tried it and got some error, which is where I was hoping to see if someone was using it this way I could see how they have it configured.

Ah. I would have thought sending a command to the Hubitat device would work too.

I asked this question half a day ago, and since this thread moves so quickly, I thought I'd ask again.

Speaking in Hubitat language, how do I distinguish between triggers and conditions?

I have a flow with motion (I think) as the trigger. In the flow are switches (mode and lux) that are from two posts above (flow.office_lux and flow.current_mode). I'd like the triggers (in Hubitat language) to be motion, illuminance and mode change. How would I accomplish this?

Here is the flow I'm testing with......it's not doing much now, except educating me. There are other parts of the flow that set the flow.office_lux and flow.current_mode

Clearly I'm misunderstanding something simple here ... what I'm trying to have happen is, when the Good Morning switch is turned ON that the Living room light is turned on, and the Island light is turned on and then turned to 100% brightness.

Good Morning is received and both lights do turn on, but the flow dies with Turn Island On (ie: it never sends Island 100%). The debug nodes (Island On and IslandPercent never get triggered).

What am I misunderstanding here?

Mike,

First of all, I am sorry, but I am travelling right now so I won't be able to post nice images like I use to. But I'll try to explain by text:

"Triggers":
Any Device node or Mode node is by default a trigger. The important thing to always remember is that a device node could somewhere in the middle of the flow and it would trigger the flow from that point on. When we talk Hubitat, a "Trigger" always starts the rule from the top. This is not the case for Node Red, a trigger can happen in the middle of you flow.
If you don't want a Device Node or a Mode node to be a trigger, than uncheck the "send Events" box in the Node Red configuration for that node.
Let say I want to trigger based on "Device A - motion", "Mode changes" and "Device B - illumination", I would add three separate nodes for each of them to the beginning of my flow. For the two devices, I would have it followed by a switch node to filter just for the events I am interested in (e.g. I don't want to trigger the flow for the battery event that a device might send). I would have all of them flow into a RBE node to make my flow only start when there was an actual change (this might not be necessary based on your use case)

Not so nice pictured flow:

"Device A" -> "switch node for motion" --------> rbe node 1
"Mode" ----------------------------------------> rbe node 1
"Device B" -> "switch node for illumination" --> rbe node 1

"Conditions":
Conditions I would handle in two ways:

  1. Global conditions like the current mode I would store in a flow or global variable as it makes it easier and less resource hungry
  2. For devices, I would have a node for that device in my flow and the "send Event" option disabled. This node has a function node as in input to specify which condition I am after

Not so nice pictured flow:

"function msg.attribute = switch" -> "Device C"

I know it is a lot of text but still hope it is somewhat understandable

1 Like

It might be too quick...... Have you tried to just send the "set Island light to 100%" without the turn light on command? Usually a light will turn on if you send it a setLevel command. The "on" command is redundant

That's the best way to do it. do a setLevel to 100 instead of on then level.

If you want it as-is for some other reason, add a delay node between.

I have tried that as well. The message dies with first command node and the light does not turn on.

I also tried chaining Island to the Living room node directly, and again the flow dies with the first command node it hits (the Living room turns on, but the Island does not)

Not sure if it makes any difference (Living room = Wemo light switch) and (Island = Lutron Caseta dimmer).

Weird. I have used chained commands in a number of my flows with no issues.

Have you tried just putting an inject into the two island commands and manually triggering them to make sure they work at all?

In the arguments field for the setLevel node, did you write 100 or 100%?
Do you see any logging on HE that there was an error setting the level?

1 Like