Yes, Now my issues are down to my very, very old Z-wave (only) switches that aren't always happy with Maker API.
2 Likes
My performance has definitely improved since moving to node-red and deactivating RM. I don't have a lengthy uptime stat for you though since 2.2.2 and resulting hotfixes have been released lately.
Yes, and particularly much faster and more reliable motion lighting with NR than if coded with RM in HE.
I too would be interested if there is a relatively easy way to move Motion Lighting or Mode Lighting apps over to NR.
It's not a completely straightforward thing to do but in my opinion it's worth the effort for the speed improvement. Here is how I'm doing it...
2 Likes
Motion lighting with modes is easy, it's when you start adding buttons is where It hurts my head...check out the share your nodes post
Can you guys tell me whether RBE nodes are supposed to reset (ie. forget the last msg) across all flows when only re-deploying a single flow? I've just noticed this in the past couple of days. I have a few sequences where an RBE node is set up to block certain Pushover notifications until a change in payload. I'll be working on some things on one flow, and I'll click Deploy, making sure that I've selected "Modified Flows," so I wouldn't expect that to have any impact on the other flows. But every time I re-deploy, I end up receiving notifications from the other flows that should have been suppressed by the RBE nodes.
Depends on how you are deploying... There are 3 options when deploying - selected with the dropdown on the deploy button:
- full deploy
- modified flows
- modified nodes
(and restart flows, but that isn't technically a "deploy" is it?
)
If you are doing a Full Deploy, then yes, they will reset. I typically do Modified Nodes only, unless I know for sure the whole flow needs to be restarted, then I will do Modified Flows.
Full Deploy
This will re-deploy all flows in the workspace regardless of whether or not they have been modified.
This means that currently running flows are interrupted and restarted.
Result
- Inject nodes will fire.
- Context variables reset
- Flow and Global Variables are not reset
Modified Flows
Only flows that contain modified nodes will be redeployed.
Flows that haven’t been modified will continue to run without interruption.
Result
- Inject nodes in that flow will fire.
- Context variables reset
- Flow and Global Variables are not reset
Modified Nodes
Only nodes that have been modified will be redeployed.
Nodes that haven’t been modified will continue to run without interruption.
Result
- Inject nodes in that flow will only fire if they have been modified.
- Context variables not reset
- Flow and Global Variables are not reset
Restart Flows
All deployed flows will be redeployed.
This means that currently running flows are interrupted and restarted.
Result
- Inject nodes will fire.
- Context variables reset
- Flow and Global Variables are not reset
2 Likes
Same here.
1 Like
Yeah, I've generally been using "Modified Flows," and that's what I was using at the time, so I wouldn't expect the other flows to be affected. That's why I'm surprised that I'm seeing what I'm seeing. I'm going to investigate further tomorrow. Now that I think about it, I don't think it's only the RBE nodes being reset, but also my startup inject nodes on some other other flows being triggered, so it's really as if the flow is being re-deployed, even though I haven't modified it. It doesn't seem to be all other flows, though. I have startup inject nodes on several flows, but only a couple of them seem to be getting triggered. It's too late for me to do more digging tonight, though.
Don't know, I definitely don't see that. Remember "modified" can be as simple as just moving a node one pixel...
1 Like
Yeah, I've noticed that Maybe you're right. I was pretty sure that I wasn't changing anything at all on any other flows, but I could have been wrong.
Or you could be remembering right and some other weird thing is going on...
Could be a node-red bug? Although I would think more people would be seeing it in that case.
I grabbed the .zip (which is named "node-red-contrib-lutron-master"), extracted it into .node-red/node_modules/,
restarted NR and it isn't happy
There also isn't any info like with all the other nodes I have
Have I managed to screw up this simple task?
You are not alone! I had that happen too.. after futzing around a bit went back to HE's excellent Lutron app. May try again soon though.. sure it was something obvious I missed.
1 Like
Stop node-red, then
Go into "~/.node-red/node_modules/node-red-contrib-lutron-master" and run "npm install".
Restart node-red. I think it should work.
3 Likes
Yes. You can't just unzip modules into the directory - they have to be installed.
3 Likes
arghhh...of course.. sigh.
I probably shouldn't mention that at one point I installed the old nodes and replaced that directory with the new stuff... if you value your sanity just don't do that.
2 Likes
I’m having s strange issue with the habitat nodes recently. I updated about a week ago and now a bunch of my nodes don’t work like I thought they did before — for example when a device node is fully configured with both a device and an attribute the status text doesn’t update in real time the way the used to. Other maker api integrations—homebridge for example—work fine and immediately, as does the habitat UI for the device.
As well, when those nodes should emit a message because if a state change, they don’t. They can still write to the device however.
I’ve checked a bunch of things and in at a loss—the POST token is correct and I’m not using web sockets. I can’t seem to find a pattern in the way it’s broken.
Any thoughts? Thanks
