I really appreciate the knowledge shared here - thank you to all the contributors!
I’ve started to convert parts of my flows into reusable sub-flows to cut down on repetition.
Today I have a flow that handles the events from a ZHA attached Hue v1 remote. Currently I have a flow that performs well and a sub flow copied from it that performs really badly. Hue v1 Dimmer dim up performs instantly in the flow vs 4 seconds using the sub flow!
In the node debug log (with the current Deprecated API warnings issue) the window is blank for a few seconds and then spits out thousands of lines of these warnings alongside a couple of debug nodes) . Running on HA Yellow this uses 40% CPU for several seconds.
Clearly something is not right. I have compared the flow and the sub-flow, but can’t see anything wrong. I’d like to figure this out rather than saying what is wrong with the attached flows.
I would like to pose a few questions I could not find an answer for so far:
Is there a performance diagnostics tool for node red to help me understand where all the cycles are being used?
I also used node red environment variables for the first time - should these be used in HA?
I read plenty of notes on turning off the warning, but none of the paths are visible from vs code plug in on HA Yellow. I also got the response from terminal docker not found. Is there an edit available to turn off the deprecation warning for my hardware?
You can enable the CPU sensor in the node red integration, but I believe that the addon’s CPU usage is not computed by this sensor.
I don’t know if there is any diagnostic tool, but perhaps you can disable everything you have on the node red and enable one thing at a time and see what is consuming the processing.
Since turning off the deprecation warnings - the momentary usage is only 20% - pressed the dim up / down buttons - you can see the last peak and the memory usage increased too.
A CPU monitor is not likely to help locate the problem, so I’ll have to try to disable other flows etc.
Happy to say that at the moment the flows are responsive. I tried several actions to try to narrow down where the performance hit might be coming from but in the end inconclusive. Performance is back to normal, but re-adding these suspects did not recreate the performance problem.
Get Entities without join. I used get_entities to find a light group and checked the split option to keep payload messages a little cleaner. The original flow had a join node (with nothing beyond that).
Call Service node with debug. I had some call service nodes with the debug option enabled. These have now been turned off.
Since the deprecation message has now been suppressed, performance is much better it is not possible to be particularly objective. I’ll leave this open in case it comes back and can look further.
You can compare CPU usage before and after updating nodered and after applying the command in settings.
I even tried to make this comparison, but on the same day I made a change to a camera, so I won’t get any useful information.
