Nice. I didn't know that until you posted it!
1 Like
Just upgraded my main pi to NR 2.01 - so far so good but we will see how it goes..
4 Likes
Has anyone here used the node-red-contrib-apcaccess pallet with with UPS's in their setups.
I am playing with it using UPS virtual driver and this seems to work ok..
It is a bit chatty though. My virtual driver creates a command for each attribute so it can be updated. Is there an easy way with Node-Red to Consolidate a set of messages and make one long comma delimited string. I know it is probably a simple answer, but i can't seem to figure it out.
I bit the bullet and updated to NR 2.0.1 yesterday, and it created an issue with my http request/web scraping (keeping an eye on certain prices/variables on the web, and even internally in my home network - solar etc). Anyway, I posted over at the Node Red forums and they fixed it within about 4 hours. There's a fix coming in 2.0.2, but the workaround was to delete an offending node built old dependancies.
2 Likes
Thanks for the heads up! What node were you using?
SpeedTest Node. node-red-contrib-speedtest-updated
But it's not limited to that Node, there's a number who use the underlying dependancies. There's a fix in 2.0.2.
1 Like
I tinkered with node red, but I didn’t see any benefit of using that vs other things in hubitat.
Are you all seeing a benefit?
yes! 
2 Likes
Anecdotal evidence inbound!
My automations are perceptibly faster. Even though that's completely counter intuitive... You would think that adding an external step to the process would ADD to execution times, but that hasn't been my experience. I eased into NR just because I didn't think it could be any faster. Now I don't have a single RM rule.
I also find building automations in NR much more enjoyable than tripping through RM's UI (especially when making changes). That's just my opinion.
I won't make any statements about stability because there have just been too many variables to credit any one change.
3 Likes
Countless benefits. The automations are in a permanent place no matter what device or hub I choose to use in the future, and switching from the current device in a rule to a new device on a completely different platform other than HE is as simple as about 3 clicks, instead of completely having to redo the entire automation, editing an automation in NR is crazy simple. That is the many benefit, there are numerous others
3 Likes
Yes: speed, reliability, visual programming (not for all though). Wider integration.
My first foray home automation was smartthings, then hubitat. And in both cases SmartThings and Hubitat were the backbone. Now it's Node Red as the backbone, utilising Hubitat as just one of many integrations.
Edit: not knocking Hubitat. I love Hubitat, especially as a device controller. And I'm not going anywhere soon.
I agree with @harold.min & @waynespringer79!
For me the visual nature of the sequences and flows makes it very intuitive. It's extremely easy to replicate and modify rules ("sequences"). I can add as much hardware as I want and troubleshoot down to the system level. I also really like the opensource nature of the system.
On the HE side, removing almost all apps has the benefit of lower resource usage which keeps things snappy. HE is the best all around home automation server / device controller out there for my purposes.
With NR I am not really beholden to any one vendor as @waynespringer79 says I could switch platforms if I had to and keep my "rules". Although I am pretty much all-in with HE at this point with no plans to change anytime soon.
NR & HE work really well together.
4 Likes
Yeah - I feel ya! I came from Wink and initially, NR was for logging. Then I figured I'd move my logic to it so I had a little more "transportability" for my rules. Have not looked back. Pretty confident that HE is going to be around, but what if my needs change?
3 Likes
When I had an automation based on its reporting of power failures, I just used a tail node on the apcupsd.events file and switched on content... There wasn't any need to connect HE to it. Added benefit was events were real time vs. polling based.
Also, maybe the 'Join' node is what you're looking for? I don't use it, but maybe it could be useful?
When I change the device that a node refers too, I have noticed in the Node Red logs that the device shows as the device's node id instead. It seems to be when I have entered something in the name field originally but left it blank for the new device to auto-populate. Its easily fixed by entering something in the Name field for device but is a strange anomaly.
The HE mode status doesn't seem to auto update until I hit deploy, is there a way to get that status in NR to auto sync with HE? I must be missing something obvious...
I use a sequence like this to be notified when any device is low on battery (<50% battery).
The change node sets:
msg.topic to be the name of the device
msg.payload to be the battery level
msg.model to be the device model
The switch node then uses the device model to create a "msg.battery_type". The template node at the end puts it all together so I get an SMS message for each device with low battery that looks like this:
I'd like to modify this sequence so that I get an SMS sent only if there are multiple (say 3 or 4) consecutive low battery levels reported.
So I want to introduce a counter that counts messages per topic.
How do I do that? The counter nodes I am aware of are not per topic counters.
If it's a recent add to MakerAPI, sometimes I've had to open the config node and clip on the Configure Webhook button...
1 Like
Something like a Queue node maybe?
1 Like
I'll check it out for sure!
