Node-RED nodes for hubitat

[JasonJoel]

Here is a data point from my system...

Zigbee motion to a zwave light, on/off logic in Node-Red.

Motion: 12:10:46.747
Light ON: 12:10:47.079

So 0.332s. On that device driver I know that I log the ON event via the report back from the device (not issuance of the ON command), so it actually turned on faster than 0.332s.

Now, the logic is very simple in node-red on that one (motion, check mode, turn light on at x% based on mode), but still gives you another data point. My node-red server is running on docker on my AMD EPYC 3251 based server.

[aaiyar]

The logic in that flow is very similar to mine (for turning on). Are the zigbee sensor and zwave dimmer psired to the same HE?

[JasonJoel]

Similar to yours EXCEPT I am not asking the hub for the current mode in that part of my logic.

I store the mode as a flow.variable any time the mode updates and then use that variable in a switch node. That is MUCH faster than going out to the hub to check mode every time.

@aaiyar

Are the zigbee sensor and zwave dimmer psired to the same HE?

Yes.

[aaiyar]

@JasonJoel

I store the mode as a flow.variable any time the mode updates and then use that variable in a switch node.

Can you post a flow demonstrating how to do this and one on how to use use flow.variables?

Many thanks!

[JasonJoel]

I will when I get home - too hard from my phone.

To do this is super easy, though.

To store mode in a variable:
Hubitat mode node -> change node that does a 'set flow.currentMode = msg.payload.value'

I just stick that at the top of my lighting flow sheet (side note: I do all lighting for my entire house in a single Node-Red flow), then I can use flow.currentFlow anywhere I want to in that flow. I guess you could make it global.currentFlow instead, and then use it in all flows. I haven't tried that to see what the speed penalty is by doing that (if any).

To check the stored mode variable in a flow:
switch node that checks flow.currentMode == 'desired mode'

Whether you check the flow.currentMode in a function node or a switch node is up to you (more of a style preference versus technical decision). But either way it is a really handy way to do mode checking basically for 'free' (well, close enough to 'free' versus polling the hub, anyway).

[dan.t]

@JasonJoel

To store mode in a variable:

And here is what @JasonJoel said in pictures:

and the change node is like this:

I have an inject upfront in case I want to trigger a manual check but that is not necessary

You can use that variable in a switch like this:

[JasonJoel]

@dan.t

And here is what @JasonJoel said in pictures:

Exactly right, thanks @dan.t!

@dan.t

I have an inject upfront in case I want to trigger a manual check but that is not necessary

It is handy to have that inject there. Even handier if you make it a 1-time 'on startup' execution (run after 0.1s, repeat=none). Then the variable gets set on startup without waiting for the next mode change.

[aaiyar]

@dan.t @JasonJoel

I can't get this work. So clearly doing something wrong. The debug node indicates that I am able to save the current mode, but I cannot retrieve it using a switch node.

When I click on inject #1, here's what the debug shows:

So, I'm presuming that flow.house_current_mode was set to "Home" also.

When I click on inject #2, here's what the debug shows:

Here's the content of the function node:

What have I messed up this time?

Really appreciate your help!

Edit: This is the switch node configuration

[JasonJoel]

You can't refer to flow variables that way in a function block. You have to do flow.get('variable name') to fetch the variable.

Yet another reason I think it's easier to do it in a switch node(s) and ditch all that Boolean logic.

[aaiyar]

@JasonJoel

it's easier to do it in a switch block

Will try this right now. I'm assuming I use a true/false type switch? for each possible mode?

[dan.t]

In a function node, you have to get the variable like this:

var mode = flow.get(‘house_current_mode’);

I agree with @JasonJoel, it is easier with a switch node

[JasonJoel]

Can't answer that. I don't do any Boolean logic like that. Never saw a need to.

That said, Boolean logic can work just fine technically, you just need to get the variables all in the right state I guess.

I don't have any function node with 3 outputs, for instance. I would rather chain a couple of switch nodes together.

Either can work just fine. Just stylistic preferences.

[aaiyar]

@JasonJoel @dan.t

I guess I don't understand how to use that switch node directly?

[JasonJoel]

Just explain in words a sample flow that you're trying to do, and I would be happy to slap together how I would do it.

Not sure if that would be more or less helpful though. Like we've all said before, there are probably a dozen different ways to do it - all technically fine.

[dan.t]

If you “just” want it to work, go into your function node and replace

flow.house_current_mode
With
flow.get(‘house_current_mode’)

That is the “easy” way out

[aaiyar]

@JasonJoel

Just explain in words a sample flow that you're trying to do

Excellent idea. I have 3 modes (Home, Away, Sleep). In many of my sequences, I do this:

Each of the outputs the "Mode to Boolean" function corresponds to one Mode, and can have two values (true/false).

I take that true/false Boolean value through a switch node, and do something if it is true ....

This is inefficient because everytime I run the sequence, it fetches the mode.

As you've pointed out, the efficient thing to do is to save the mode, and then recall it in the desired sequences on that flow.

That, in a nutshell, is what I want to use the switch node with three outputs for.

@dan.t

That is the “easy” way out

I am 100% going to try this. But I also want to learn the right way

[JasonJoel]

Still not sure why you would want/need all the boolean true/false stuff - that just isn't how I do my logic - but no matter.

If you want to use the function node like that, then do it the way dan said. That is the easiest way to do it with the assumption that you want to use your function node like that.

[aaiyar]

@JasonJoel

that just isn't how I do my logic - but no matter.

So I'm asking the wrong question. The better question would be - how should I modify my flow logic?

@JasonJoel

That is the easiest way to do it with the assumption that you want to use your function node like that.

I messed that up.

[JasonJoel]

That is hard to answer without knowing what you are doing with the boolean logic.

Need to understand the big picture to say how I would do it. And who knows - maybe I would do it the same way? I definitely use function nodes for some of my mode based lighting logic - just not as boolean true/false on the output.

For instance, here is a standard motion lighting (2 motion sensors) with no function blocks, but it does different things in 2 different modes. Could have made it 1 Hubitat command block on the right if I used a function node, but I like not using function nodes when I don't have to.

(note to self, probably needs some logic on the "on" path so that it doesn't send an ON command every motion detection event - so this isn't a great/perfect example...)

[aaiyar]

So here's a big picture. This flow works, but it is slow. I want to speed it up.

Let's focus on the motion sensor M-K and go upward.

1. M-K is my kitchen motion sensor.
2. If it is "active", it gets the current mode (function with 3 outputs). O1 = home, O2 = away, O3 = sleep. The function sets home as (true, false, false), sets away as FTF, and sets sleep as FFT.
3. If O1 or O3 are True, then based on the time, I either turn on the kitchen tube lights or the kitchen wall lights.
4. If O2 is True (away mode), then I check the state of two switches (Visitor and Pattie Poehl). If either of those are true, then it feeds into the same time based light selection.

I want to learn better logic.