Node-RED nodes for hubitat

When you are posting in a public forum, by definition it is everyone's business. Have a great day.

And you're right, my post helped about as much as your post. If you had a problem with what one person said, you should have pm.'ed them instead of posting it in the public forum for all to comment on.

But never fear, I added you to my ignore list. So I won't see your posts at all, and I would recommend you do the same to my profile if I annoy you so greatly.

1 Like

Oh, please! You make it too easy to get me to play. :stuck_out_tongue_winking_eye: :rofl:

I cant get the first export section of your circadian lighting routine to work, it says there's an error, possibly due to the forum formatting? "SyntaxError: JSON.parse: expected ',' or '}' after property value in object at line 1 column 8936 of the JSON data'

Hiyah. Not sure how to fix that. I just did an export and pasted it directly into the editor. Sorry about the trouble. Maybe someone else can assist.

When I eventually move all of my devices to my new C-7 hub, I assume that I will have to go thru every Hubitat Node and correct the device since Decide IDs will change whether I transition manually or use the upcoming migration tool.

Please tell me I am wrong!!! :grinning:

I was just about to point you to this recent post by Bruce, which I'd hoped would remove the need do change all the Device IDs, but I just realized that what this post describes is a way to preserve (or re-assign) old Device Network IDs (DNIs) on the new hub. Apparently this will allow your Hubitat automations to continue to work on the new hub. However, I notice that the NR nodes use the Device ID as identifiers, and not the DNIs, so I guess this wouldn't help us.

However, one great thing about NR is that we can also edit our flows in text editors (via export and import), which means you could do some find-and-replace-ing to change the Device IDs in your flows. You might even find a way to do it throw a NR flow :wink: haha. Or, failing that, I believe we can edit our flow files directly, making it easier than export/importing each flow.

EDIT: I forgot to include a link to the post:

1 Like

Correct. I just did that on 800+ nodes... The other option would be to shut down node-red and search/replace the deviceids in flows.json I guess (EDIT: Yeah, like @jason-lane already said. lol). I did it by hand as I also took the opportunity to remove a bunch of nodes through more intelligent change nodes/logic to set commands/arguments. Got rid of maybe 200 nodes or so worth.

Maybe a future version of the node set will allow overriding device with name OR deviceid. That could potentially prevent the issue (if you named the devices the same on the new hub, of course). Or maybe the Hubitat migration service will keep all deviceids the same on the migrated system, which would be nice.

Being a rookie with NR I'm interested to see what you did here. Might you have a before & after flow as an example? I'm sure I'd learn from it as I only recently tossed my function nodes in favor of change nodes for reading/writing context variables. I'd read something about doing so but it wasn't until I imported a flow that @aaiyar posted in the examples topic that I saw how to do it.

Thanks for considering my request.

I'll see if I can find one for a picture.

In general though, I had a lot of places where for GE motion dimmers I would set the dimmer level, default level %, motion setting, and light timeout.

I liked doing that with 4 different command nodes, as it makes the flow VERY easy to read and follow. The side effect of doing that, though, means I had to edit 4 nodes when I changed hubs.

Now I use a change nodes to set the msg.command and msg.arguments going into a single command node. So in the future, just 1 node to update if I change hubs. Yes, there are now more change nodes, but those are static.

1 Like

I see. Good re-use there :+1:

It is handy to reduce the number of nodes - which actually is a good thing because each node keeps its own cache of values. So if you use the same device in 4 nodes, there are 4 copies of the attributes floating around out there.

If the node sets ever changes to using a global cache (I believe Francois was looking into/testing that) that redundancy would go away, of course.

But I'll say that the flows are a little harder to follow/read. Not horribly so, but I did prefer the look/feel with 4 command nodes more.

2 Likes

I figured it out the "hard way", parsed the json by hand. In the 2 functions the quotes around circadianTemp and circadianLevel need to be escaped.

1 Like

Ah, I see. Sorry about the additional hassle.

I have 1 switch that throws the same error every time. When my outside illum goes over 30000 it triggers a boolean that triggers atimer to turn off the lights in my master bedroom.


You can see the response error.
image
and here is the maker API error.

If I call a straight turn off from node red without the logic, it works perfectly.

Can you try copying the working 'command' node to the flow in question and see if it errors there?

Also, are you setting a command in the msg or are you defining the command in the node itself?

Defining in the command itself.

What does your debug msg look like? (I'm assuming that's what hanging off the switch node called 'Check On')

Can you attach an Inject node directly into the command node and see if it works?

yup, it works.