Node-RED nodes for hubitat

[erktrek]

Yes - good idea!

I know it's not all that hard to work around using another device node etc but that seems like a nice way to simplify things..

[LosinIt]

My first thought was...meh, I haven't needed it though I'd probably find a way to use it. Then you pointed out the benefit of reducing mesh traffic and I perked right up. So, even if for no other benefit, I'll say go for it.

[JasonJoel]

In reality it isn't a huge issue unless you are sending a ton of commands (initialization, mode changes [bedtime modes], bad logic, etc are times where that is more likely to happen).

But it is easy enough to do in node-red I just do it to reduce mesh commands. Many (really most/almost all) drivers will send the command on the mesh if on/off/etc are triggered regardless of current state - so this technique does indeed remove commands off the mesh.

How valuable that is obviously depends on volume, the device in question, and health of the mesh.

[napalmcsr]

I asked about this before if I am getting this right

Node-RED nodes for hubitat

Having a feature to do not send command if the device state is the same value than the command? Technically This palette doesn't keep device state for all of devices. Each device node keep its own state. I would require to copy the same init logic as the device node You can set the deviceId dynamically with the input message to the command node. if we want to continue to support it: we need to keep state of all devices in NR (and if we need to initiate cache for all devices (slow process), I…

[fblackburn]

If it could simplify flow of the majority, then we can ask ourselves the question

@JasonJoel

Edit: The downside, though, is commands and state values don't always match... So instead of a single check box it might be required for user to manually specify the state value on which to not send the command. Example - presence... Arrived/departed commands versus states of present/not present...

It's the challenge of this feature. It would needs to have a mapping of "command value" with "device attribute"
I still have difficulty to imagine: how to implement/expose this feature to the user without adding a layer of complexity for him

@napalmcsr

I asked about this before if I am getting this right

Yes you're right, it's not the first time this feature is requested. But these nodes have changed over time:

• Since 1.3.0, devices logic has been moved to the config node instead of device node (to use global/shared cache)
• Since 1.4.0 we cache all devices available through Maker API.

With these changes, a lot of technical difficulty have been gone and some of the already requested feature can be easier to do or can be thought of differently

[fblackburn]

What should be the output of this node?
A list of device with the name requested or the first one?
ex: you have two devices with the same name:

• bedroom outlet
• bedroom outlet

Then if you request "bedroom outlet" you will have two devices or only the first one?

Do you want a fuzzy match too?
ex: you have three devices:

• bedroom outlet 1
• bedroom outlet 2
• bedroom light

Then if you request "bedroom" you will have three devices or only the first one or none?

In case we only return the first exact match:
Should be more interesting to have an input attribute for device node? (ex: msg.deviceName)

Limitation:

• HE allow to have the same name on different devices. Behavior needs to be defined for this case
• using NR cache would imply to restart flows after editing device name in HE (or new devices)

[JasonJoel]

@fblackburn

It's the challenge of this feature. It would needs to have a mapping of "command value" with "device attribute"

Agreed. It might not be worth doing at all.

After some thought, the 'easy' way to do this would be to make the user manually enter the attribute and value in a string fields.

"Do not send command when device attribute " + attribute + " is " + value + "."

Then user enters

• attribute - switch, level, etc
• value - on, off, 99, etc

But to your point, that does add complexity to the command node, for something that is readily done with just 2 nodes externally today.

@fblackburn

Then if you request "bedroom outlet" you will have two devices or only the first one?

@fblackburn

Limitation:

• HE allow to have the same name on different devices. Behavior needs to be defined for this case

I didn't think of that.

[fblackburn]

Maybe it can be half automated

[erktrek]

That looks cool! You wouldn't even need to test the related attribute for example the command might be to switch "on" but you could test for hue... seems like even more possibilities doing it this way..

[fblackburn]

It exactly what you said that's scare me. I don't want to add this feature to be used as "logic maker". If you want to do this kind of logic, it definitively nothing to be inside the node. But I can see your enthusiasm

I'll think about it again for the next few days: how to automate/simplify the logic for this feature

[MRobi]

@JasonJoel

Question for the group...

Would it be useful to anyone other than me to have an option in the command node to "only send command if different than current state"?

The thought is that there are a lot of times I check the current status of a device and don't send an on/off (for example) command if it is already in that state. Why? Processing power on the node-red side is cheap, and any reduction in hubitat hub and zwave/zigbee mesh traffic is a big plus.

Not sure how useful that would be to others, so thought I would ask before dropping it in Francois' suggestion box.

This is a feature of the home assistant "current state" node as well as the "events state" node. I use that functionality almost all the time. It basically builds the switch node right into the main node, or it can be used exactly how you are in the example by not specifying the state and then it sends based on any state. It makes the flows so much cleaner looking which is great for my OCD

[erktrek]

I understand your point with the design so it's fine to leave it out.

It would be nice to be able to dynamically select maker instances along with devices in the nodes via input though...

[jpoeppelman1]

@JasonJoel

Would it be useful to anyone other than me to have an option in the command node to "only send command if different than current state"?

The thought is that there are a lot of times I check the current status of a device and don't send an on/off (for example) command if it is already in that state. Why? Processing power on the node-red side is cheap, and any reduction in hubitat hub and zwave/zigbee mesh traffic is a big plus.

I like this idea, it would certainly reduce the http calls between NR and HE. Doesn't HE already filter commands if the device is already On when sending through the Z protocols? I would think HE would stop the z command from leaving the hub, thus keeping the mesh from being saturated during many serial commands?

[JasonJoel]

@jpoeppelman1

I like this idea, it would certainly reduce the http calls between NR and HE.

It would only reduce hub traffic if you aren't already checking the current state before sending commands on the node-red side. If you are already checking the device state and only sending if different today using 2-3 nodes (like my example above), it would be the same just less nodes.

If you aren't checking current state in node-red today and only sending commands if different, and just sending every command regardless, then yes it would reduce hub and mesh traffic.

@jpoeppelman1

Doesn't HE already filter commands if the device is already On when sending through the Z protocols?

It is up to the driver, but no it doesn't on the vast majority of drivers. You click "ON" 3x, it sends it on the mesh 3x.

At the platform level Hubitat only de-dupes incoming events (if not explicitly marked as a state change in the driver), not outgoing commands. Which is the right behavior in my opinion.

[csteele]

@JasonJoel

not outgoing commands. Which is the right behavior in my opinion.

+1

I have "Deadman Timers" on a couple of water valves. I want them OFF. Unless I programmed them to be on, and even then, they are never on for more than 12 mins. Thus I have a Timer running to send an OFF every 20 mins, round the clock. One of these is a Pool Filler. I certainly don't need the pool filling for 8 hours. That would be expensive. 99% of the time, these Deadman Timers are redundant. The valves are off and another OFF cannot hurt, only help.

Therefore, I am 100% on the "do what I tell ya" on the output side of the Hub.

[rocketwiz]

General node red question to satisfy my curiosity - is there any difference in terms of propagation delay from node to node vs lines on a javascript function ? (or put another way is there much of an overhead at all in the node red gui approach? )

[LosinIt]

You'll likely get a more knowledgeable response on the NR forum

Node-RED Forum

[rocketwiz]

Yeah I know, just thought I'd ask here first as I'm here more often than over there

[JasonJoel]

No worries. Doesn't hurt asking here. But that is a very nuanced and technical question that really only the maintainers of node-red will know the technical basis of.

All we could give is anecdotal experience or opinions.

[buckchucko]

I noticed you use an XU4 for node red. I am getting a C-7 to replace my C-4 and I am thinking to use node red (which I know nothing about as yet).

I have an XU4 I would want to use for node red. I thing it has the 32gb emmc. Can you tell me what system image you use on the XU4? Then what I would need to get node red running on it? ANy help would be appreciated.

Thanks in advance.

I am a linux noob, so please be detailed as possible.