Node-RED nodes for hubitat

This is something I worked on a while ago. It may help.

    [{"id":"3f814648.830bda","type":"ui_slider","z":"8c249630.076968","name":"","label":"Office Hue","tooltip":"","group":"57bd8750.b32dc8","order":4,"width":0,"height":0,"passthru":true,"outs":"end","topic":"","min":0,"max":"100","step":"5","x":630,"y":600,"wires":[["9e3d9c15.728d6"]]},{"id":"c6acccbb.0ea2b","type":"template","z":"8c249630.076968","name":"On","field":"payload","fieldType":"msg","format":"handlebars","syntax":"mustache","template":"{\"on\":true,\"brightness\":{{payload}} }","output":"json","x":890,"y":600,"wires":[["58ce48aa.b93d48"]]},{"id":"94d591c1.5b387","type":"change","z":"8c249630.076968","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.brightness","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":1340,"y":560,"wires":[["29d106f0.a3ee1a"]]},{"id":"29d106f0.a3ee1a","type":"rbe","z":"8c249630.076968","name":"","func":"rbe","gap":"","start":"","inout":"out","property":"payload","x":1490,"y":560,"wires":[["3f814648.830bda"]]},{"id":"58ce48aa.b93d48","type":"hue-group","z":"8c249630.076968","name":"Mike's Office","bridge":"5e6fe1ca.85689","groupid":"3","colornamer":true,"skipevents":false,"x":1050,"y":600,"wires":[["36cf9319.34314c"]]},{"id":"36cf9319.34314c","type":"switch","z":"8c249630.076968","name":"","property":"payload.on","propertyType":"msg","rules":[{"t":"true"},{"t":"false"}],"checkall":"true","repair":false,"outputs":2,"x":1190,"y":600,"wires":[["94d591c1.5b387"],["e623ee4e.41f81"]]},{"id":"e623ee4e.41f81","type":"change","z":"8c249630.076968","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"0","tot":"num"}],"action":"","property":"","from":"","to":"","reg":false,"x":1340,"y":600,"wires":[["29d106f0.a3ee1a"]]},{"id":"9e3d9c15.728d6","type":"switch","z":"8c249630.076968","name":"","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"0","vt":"num"},{"t":"gt","v":"0","vt":"num"}],"checkall":"true","repair":false,"outputs":2,"x":770,"y":600,"wires":[["b37b8be7.3e8e28"],["c6acccbb.0ea2b"]]},{"id":"b37b8be7.3e8e28","type":"change","z":"8c249630.076968","name":"Off","rules":[{"t":"set","p":"payload","pt":"msg","to":"false","tot":"bool"}],"action":"","property":"","from":"","to":"","reg":false,"x":890,"y":560,"wires":[["58ce48aa.b93d48"]]},{"id":"57bd8750.b32dc8","type":"ui_group","name":"Downstairs","tab":"1862e313.45ffad","order":15,"disp":true,"width":"4","collapse":false},{"id":"5e6fe1ca.85689","type":"hue-bridge","name":"Philips hue","bridge":"192.168.1.221","key":"76VF5utXrkJ9PftxiZgEDKW3dFB67Mv8H1Op4RQA","interval":"3000","disableupdates":false},{"id":"1862e313.45ffad","type":"ui_tab","name":"Mike","icon":"dashboard","disabled":false,"hidden":false}]

Cheers!
Will take a look

I just updated the code to a more recent version.

Hey, Any chance of being able to set the deviceId for the device node like the command node? That would help me out alot. Or is there another way of getting the state of a device using a variable deviceId? Thanx! Michael

Not for now, but it's not impossible that I take some time to make a branch to test it .. :slight_smile: People have been quiet about this feature request recently
Workaround: use event node to catch all events and build your own cache with variables

2 Likes

I think that is why no one has pushed for it. Super simple to just do an event node + switch node to filter by deviceId.

Ok thanx I will look into that!

Michael

Is it possible to interface the built-in Thermostat Scheduler app, specifically the turning on/off of EcoMode? I am currently doing it through a virtual switch in NR and a simple RM rule for each room to interface:


Is there any way to directly interface however in NR?

1 Like

What I'd like to be able to use it for is in subflows.

One issue I am running into with the C-7 is delays in switches (for example) from the time the command is called to the time it gets updated. This is not a Node-RED or HE Nodes issue but a slow response via hub.

It would be nice to be able to encapsulate something like this:

which is part of an "fake" NR group I created into single subflow into something like this maybe:

Why wouldn't you just use a device node to detect the change? That way as soon as the event comes in you would trigger.

You are never going to be faster in detecting the change than the device node itself, so no need to loop like that (in my opinion), but maybe I'm not understanding.

Maybe I am missing something obvious.. I have a command node that I want to turn "on" so it makes a request to HE for the device to turn "on" - I then immediately test the "device" node but it still shows "off" - this is the delay I've encountered.

Right, but why wouldn't you use the device node to see when the device updates? You don't need to test the device node, it will send the message as soon as the event comes in from the hub.

Basically just the same thing you have now, but don't connect the command to the device node, make sure the device node is set to send events, and no loop.

Now, if you ONLY wanted to do logic when you sent the ON in that particular logic rung (and not if something else external changed the device state), then yes you may have to do it like you are today or some variation on that.

1 Like

By waiting for the event to fire I gotcha - yeah I may need to look into my group subflow logic a little more... thanks.

I guess I still would like to be able to specify a deviceid though.. nice to be able to have a generic way to grab device data for use in subflows and such... maybe a lookup node or something.

Something more or less like this:

Gotcha. Yeah, since you can specify device id for the command node, I can see how that would be handy on the device node too in some cases (subflows in particular).

Although you could do it today by putting an event node in the subflow, then a switch right after that filters events by the deviceID you pass to the subflow. Not sure how good/bad that is for loading having a ton of event nodes, though, I've never tried it en masse.

Like this:
image

With the filter something like this (assuming the environment variable you store deviceId in is "deviceID":
image

1 Like

Yeah it's kind of what you mentioned about my logic being on a different rung/branch. I already test using the device nodes for other things but am now looking into merging my other logic in there as well.

In essence I am recreating an HE group in NR in a subflow. You can call it like a device node and get info back, you can send on/off "command" to it, you can have it report events and you can define how you want it to respond (all on/all off etc).

It returns a fake "group" device payload with the relevant information.

Ah! Nice. Yeah, to do that you really would want to be able to specify the deviceId on the device node directly. :+1:

I actually have a very beta version of a node set I worked on a long time ago that keeps EVERYTHING from the hub in the node-red memory blob at all times - built off of an initial "devices/*" call, then updated via the event updates. Then you can just adhoc pull any attribute from any deviceId at any time, as it already has them.

After @fblackburn made his node set, though, I abandoned work on it.

1 Like

Hehe it's probably what the config node become to be, i.e. a global cache of HE devices.
The other day I tested the devices/* and allowing to specify deviceId. Everything worked!
I'll try to push a draft PR in the next days to test it
:shushing_face: :speak_no_evil:

4 Likes

You spoil us. :slight_smile:

2 Likes

Someone know if virtual devices have the same load on HE (Maker API response) than real devices?
I'm trying to do some benchmark for the next version, but I don't have enough devices to see impacts :sweat_smile:

From a maker API event standpoint I believe they are equal.

Command nodes setting methods via maker API are almost certainly faster on a virtual device than a real device though. It that wouldn't impact your initialization time.

I will say that in 2.2.4 beta devices/* only takes about 1-2s for 103 devices in Maker API (~80 physical, 20 virtual). I think the platform optimizations they have been doing are really working, as it used to take 10+ seconds.

4 Likes