Wow, that worked!
"makes sense" = this to me is like trying to write a book before you know vocabulary. But it's coming on slowly Rome wasn't built in a day.
Thanks again, I'll try not to hound you all the time for help, only after I've tried to figure it out for a few days and am stuck.
I'd like your thoughts on this. In the flow below, opening my closet door (C-CD) or detecting motion in the closet (M-C) sets the dimmer (CL) to a specified value.
Here are the Hubitat logs:
C-CD shows as open at 12:52:02.725
CL was set to 100 at 12:52:04.369 (so ~1.6 seconds later; that's a noticeable delay).
The load average on the Odroid is around 0.2 - 0.4.
I have two thoughts:
Your experience in such matter exceeds mine considerably - what would you suggest?
That thing is pretty much sitting around being completely bored.........
Have you timed the flow once? Trying to take that out of the equation
No, I haven't. How would I do that? What nodes do I add to track time? Just the debug node?
That's what I would start with. Not scientific but neither are the log outputs in HE...
I want to thank you for this! I've been unsuccessfully fighting for over a week on trying to figure out a "cancel (stop) delay on truth change" to actually work.
And this did it!!! Very much appreciated
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.
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?
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.
Yes.
Can you post a flow demonstrating how to do this and one on how to use use flow.variables?
Many thanks!
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).
And here is what @JasonJoel said in pictures:
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:
Exactly right, thanks @dan.t!
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.
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
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.
Will try this right now. I'm assuming I use a true/false type switch? for each possible mode?
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
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.
Download the Hubitat app
