Node-RED nodes for hubitat

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.

1 Like

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 :wink:

1 Like

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.

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

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.

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

I messed that up.

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

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...)

1 Like

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.

Actually, it is - it gives me a much better idea of how to use the mode switch!

On that particular switch the details are:
image

1 Like

Yes, this definitely did the trick!

Thank you. I'm trying my best to learn and both of you are spectacular teachers.

That seems fine to me, other than fetching the mode. If you wanted to leave it all as-is, and just stop fetching mode then replace the Current Mode fetch block with a change block that shoves flow.house_current_mode into a msg.payload.mode (or other) variable, and use msg.payload.mode as your variable in your function node.

Or delete the mode fetch node altogether, and then do the flow.get in your function node. I would probably do it this way, since you are going to have the function node anyway.

Obviously need to set that mode variable somewhere else, too. :slight_smile:

1 Like

So in summary:

  1. Delete the mode fetch node
  2. do this:

It will definitely be faster. How much? Dunno. :slight_smile: I haven't found a reliable way to measure millisecond log info in node-red. All I know is a mode fetch on my system takes something < 1s... So I'm not 100% sure this will speed things up greatly for you?

2 Likes

I can answer that. We've gone from around 1.6 seconds to 400 milliseconds.

Motion active at: 17:44:31.832
19%20PM

Light turned on at: 17:44:32.256
39%20PM

That's a decent saving!

Thank you and @dan.t for sticking with me!!

P.S. In the meantime, I'd ordered one of these. Now, I'm tempted to cancel the order.

4 Likes

I'd cancel it, if it were just for node.red. Not really needed most likely.

Now, if you just want a toy.... :wink:

I have a 7 series NUC somewhere around here. Should throw it at your house when I'm in town
in a few weeks. :wink:

1 Like

Logically, I should cancel it. I have 46 autosomes and an X chromosome that say "Cancel it". But my Y chromosome says quite clearly, "Nah - I don't think so".

3 Likes

I'm a Y advocate. I got a NUC about 6 years ago. One of my best buys ever. It has been used for so many things over the years.
Windows 7/8 media center pc.
Windows 10 "kitchen" computer.
Ubuntu server to host Docker with a TON of containers including my HE influxdb/Grafana/NR.

Now it runs Home Assistant in docker on top of Ubuntu.

Trust me..worth the purchase one way or the other.

2 Likes

How would I go about getting the lux from a motion sensor? I cant seem to find a way to do this.

Is something like this what you are looking for?

lux

2 Likes

Maaaaaate! We are doing the exact same stuff on different sides of the globe. Virtual high five.

(I guess it's dark there).

1 Like

Yep 1 AM

2 Likes