I've find this one pretty handy. It sends a pushover notificaiton to your device on any Node Red errors, showing the Flow, node and error message.
You just need to add the configured pushover node at the end, and in the second node: change the device name to you device name in pushover. You also need to place the entire flow on every page you want notifications.
The node-red command nodes don't do any queuing/buffering, so if you blast it with a lot of simultaneous commands, it is going to try and send them all immediately to Hubitat. May work, may overwhelm the hub.
I would consider making a GROUP (or set of groups) in Hubitat and just turning the group device(s) on/off from Node-red.
If you can't use groups, then I would do some combination of serial/parallel in node-red. Or parallel with random delay nodes before the command nodes to distribute load.
I do my Good Night sequence in parallel but I check each switch/light bulb's status before sending a command to it so I am only sending the OFF commands to switches or lights that are on. The check isn't polling the device, just seeing what the device's current status is according to NR so it's not addl traffic. Most of my switches are ZWave.
Always a good/best practice. The current on/off status data is just sitting there in memory in node-red, might as well use it!
I do that on most things - except locks. I send the lock command no matter what "just in case" the status happens to be wrong in node-red (not that that has ever been a problem for me).
No worries. I just thought figured you guys had been at it would be able to guide me to helpful node / flows. Retrieving a response and parsing the request likely has several approaches that can be taken as it's quite basic imo. I'll get it sorted.
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 think some of us will hate you )
if we make this feature incompatible with the other, than it add some complexity for the user
Conceptually:
We already mention it in this thread (lol but I don't know where ), but a node should do one and only one thing.
I don't like the idea of half-mixing concept of device node with command node. Otherwise we will end up with one big node to do everything
Since it's a good practice to check the device state before sending command. On most scenarios it doesn't do anything to send multi time the same command
Summary
It's technically not an easy process (but possible) and conceptually not an idea that I'm convinced
You guys know if it's possible to emulate a hue bulb on node red then feed those commands into hubitat to control zigbee bulbs linked direct to hubitat?
Looking at the hue node documentation the nodes seem to be able to translate for commands in different formats on the fly..
Looking to incorporate some more led strips into my hue entertainment groups.
A big thank you to @aaiyar, now I'm start to learn Node-RED nodes for hubitat.
I had a Hue Dimmer Switch ( 4 button ) on Hue Bridge. On NR, use HueMagic.
On this simple flow, it did not work !
How about Dim Up/Dim Down ?
Any help much appreciated.
I don't have Hue, so I'm not sure. But I have a good guess. Each integration uses a different msg property.
So here is what you should do:
Attach a debug node to the Hue button node. Set the debug node to "complete msg object".
Then save it.
Then open the debug window and press each button. In the window, the msg properties will be displayed. Based on that, you can configure the switch node.
I'm taking a guess and saying that the Hue node sends "msg.payload", not "msg.payload.value".
)
), but a node should do one and only one thing.
