Node-RED nodes for hubitat

I agree; like if you have a bunch of Pico Remotes! Copying flow of one Pico and pasting to control another Pico in a different room is easy. You just have to update a couple of nodes but the logic and layout is same. It's much easier than writing similar rules over and over again in HE.

It took me a very small fraction of time to move all of my RM lighting rules to node-red than it would have taken to re-make them in RM. All because of copy/paste and quick mods/updates during troubleshooting.

For me the main draws to having logic in node-red, regardless of whether it is faster or slower, is:

  1. export capability
  2. copy-paste
  3. Rapid modifications/updating
  4. No code needed normally, although code can be done easily when needed
  5. Near platform independence from the device source

While I couldn't use my Hubitat lighting flows exactly/without ANY modification in Home Assistant or an MQTT device, it is a trivial modification - typically just replace the in/out nodes.

As someone that has used Homeseer, Vera, SmartThings, Hubitat, Home Assistant - and others I'm likely not remembering - and had to re-do the logic every single time platform independence is something that REALLY resonates with me. That is why I don't just do the logic in Home Assistant, even though the Hubitat to HA integration is pretty good these days.

Fast forward a few months and some company releases a Z/IP based zwave 700 hub... I'm good. If I decide zigbee2mqtt can work for my device needs... I'm good. If I want to incorporate some of my new LoRa/LoRaWAN devices I'm tinkering with into my logic... I'm good.

If I can get it into MQTT or there is a direct node-red integration, I can use the device in my logic. THAT is power to the people. :wink:


100% this. This is #1 on my list. As I'm currently shopping around for another platform that handles zwave better, the one thing that kept me held off was having to re-write all the logic once again, and then trying to tie whichever platform to hubitat so that everything is working together.

Node Red makes this possible. Now knowing all my logic is permanent and won't have to ever be re-written again, also knowing that any future platform update won't introduce a bug into my logic, is a big stress saver and opens up so many more options to join in my overall home automation experience.

1 Like

Well, after some tests, it seems that Maker API does not decode URL for arguments, which cause you the space problem (%20)

I guess that %25 does not show you error but don't say the right thing

Here some explanation about encoding URL: HTML URL Encoding Reference

It works well for the postUrl (ex: but not for arguments.

When I try to encode the secondary value from the command:

  • template from doc:[Device ID]/[Command]/[Secondary value]
  • not encoded:,50: OK
  • encoded: I got the following error in Hubitat log

java.lang.NumberFormatException: For input string: "10%2C50" (setLevel)

Allowing commas in the URL path (or any not encoded char) is a bit awkward (from developer point of view), but understandable if it is to be used by non-technical/general users (easier and can handle simple use cases). However, it's quite limiting when it comes time to enter arbitrary string/sentence.

A quick search shows that someone already mentions this issue:

I don't have any device to test with sentence:

  • You need to open an issue to Maker API
  • I need to have the exact URL format it takes to work from the API

I am one of these people

I'm not sure how to do or what is being asked for here. (from being one of these people)

Hopefully someone who has more experience can chime in.

I will confess you that I didn't read a lot about Hubitat's websocket and how it works.

I've chosen webhook only because it was officially supported, nothing more.

The following answers are only my opinion/preference

The main advantage of websocket is that servers don't need to be reachable by both sides. If Node-RED is behind a NAT, then is simplifying the configuration. But I don't think that facilitating complex architecture is the priority of Hubitat (which is fine).
For this plugin, it will remove the awkward webhookd configuration section that nobody understand (without reading doc) :sweat_smile:

A disadvantage of the websocket is to maintain the connection and handle reconnection. For all other performance issues, we can often improve the code and the desired performances depend on the use cases

I don't like this kind of architecture. I prefer separate events (weboscket) from commands (API).

True. Does the websocket is authenticated? Even if the websocket is already used internally, it's maybe not ready for being used by other external components

Do you talk about the initialization process of requesting all devices data? If yes and someday, it cause issues on this plugin, then there are probably some improvement that can be done on the plugin side (ex: requesting only one device for all the same device node).

True, but without any metrics I will not be too worried about this. :slight_smile:

I saw argument about that using a lot of webhooks can decrease the hub performance. Then I would say that if you want to have more than 10 (which is an arbitrary number) webhooks configured, just proxy it in another tool and use your own broker.

Anyways if one day, websocket become official, it should be authenticated (if not already) and maybe add the ability to filter events by event types. Meanwhile, we can also make a websocket node to receive all events (those we cannot have with webhook) and use both (websocket/webhook) :slight_smile:


How do I convert a rule like this to NR? Is there an equivalent of a Private Boolean in Node-RED? Or should I just use a Hubitat virtual switch .... (are there virtual switches that can be created in Node-RED?).

Screen Shot 2020-02-29 at 7.52.20 PM

Use a flow or context variable or a virtual switch in Hubitat like you said.

It would really be a global, flow or context variable. Then check/set the variable as needed with function node or switch + change nodes.

1 Like

I'm really loving the new attribute status below the node, but I'm finding a few HE device nodes dont actually display the selected attribute. For example, the contact sensor below is not showing.

It's been deployed and injected. I had the same with a Hue bulb, but that seems to be working today.

1 Like

Thanks, I'm going to go lookup how to create/use context variables.

Now that the device name is the node's topic, is it possible to override the device in a command node like we can override the command? For example, could I set up a command node to turn on Light A but then have an inject node that overrides the device and instead turns on Light B?

This thread has been moving pretty fast so I apologize if I missed how to do it.

Global, flow, and context variables are all the same - the only difference is scope.

Can set any of them in change nodes. Can do truth logic on any of them in switch nodes.

Can use any of them in function nodes. Note that for a context variable, you can only use in the node it was defined in, so could only use a context variable in a function node that was defined in that function node.

Yeah, when you inject a value in the device node, the status disappear and only reappear if the device receive an event

I found this bug tonight too, it will be fixed in the next version :wink:


Technically, the topic is not the device name, but the node name
Also a device name is not unique in HE, to make a such feature you will need to pass the device ID.

Setting the deviceId as message property is easy to do (technically), but I don't think it should be implemented. Making the device field optional (to keep consistency) and allowing to choose device with the input just make the device node too generic. For this, you can directly use the HTTP request node.

I'm open to discuss about it, but you should prove me some scenarios that cannot be done in another way or without adding complexity

That makes perfect sense. So I will ask if someone has a solution to reduce the number of nodes in my Vacation Lighting sequence WITHOUT utilizing a Function Node :smiley:

The pink nodes on the left are from node-red-contrib-presence-faker. Basically, it randomly sends off & on payloads and topics based on time parameters that you set. The sequence ends by writing what device changed and when it changed to a text file. As you can see, I have 7 parallel paths so I was hoping that there was a way to consolidate somewhere after the Presense Faker nodes again without using a Function Node. If there isn't, no big deal, this seems to work just fine. It's definitely not a reason to do anything weird in your integration.

In this sequence, I was originally using HTTP Requests and a Template node to generate the URL so the Topic for each of the Presence Fakers' node is already the deviceID.

EDIT: Ok, now that I have gone back and looked at this again, I think I can lose the Change Nodes and the Device Node (blue) now that the device name is part of the payload. I created this before that was an option. Also, i forgot to mention I change your Command Nodes to Red and Device Nodes to blue to help me distiguish.

Has anyone tried the NR Dashboard? I've just loaded it and started playing around with it. Looks very promising at first glance.

My flirtation with Node Red as a bit of fun the side is in danger of turning into more...............

1 Like

Welcome to Node Red, this is exactly what happens to all of us once we get started with this....


How would I change (in this node) in line 7, payload to payload.value

I tried "payload.value", 'payload.value', (payload.value), and a few others. Is is possible? Trying to keep the nodes down.

Have you tried msg.payload.value ?

If you want to do it in-line like that, you have to make the payload json format too.
In your case it would be:

var newmsg2 = { "topic": "control", "payload": {"value": "inactive"}};

Or, of course, you can do it in multiple commands...

var newmsg2 = {};
newmsg2.topic = "control";
newmsg2.payload.value = "inactive";

Same end result.

1 Like