That is interesting. Is it that chart that is using most of the CPU? If so, then as an experiment add a function node in front of the chart containing just
return {topic: msg.topic, payload: msg.payload}
If that makes a difference then that will be a big clue.
Testing it now.
I will stop the D1 chart and switch to the D2 charts again, including the cleaning function.
I think we can already kind of tell the D1 chart is not increasing cpu usage in the same way.
i will do it like this though:
let msg1={};
msg1.topic = msg.topic
msg1.payload = msg.payload
return msg1
Wow, that is a vast amount of data, and we haven't even looked to see what is in each element of, for example, originalPayload.
Looks terrifying ... but the reality is less shocking 
21-6-2026, 14:44:39node: debug 4
M3 (Measured) : msg : Object
object
payload: -14
topic: "M3 (Measured)"
data_type: "int16"
property: "battery_power"
communication_status: "operational"
scale: 1
unit: "W"
precision: 1
_msgid: "f86e7fd7dc3f9839"
messageId: "6a37dcbb40cb157a909ce3b5"
modbusRequest: object
value: undefined
unitid: 1
fc: 3
address: 30001
quantity: 1
emptyMsgOnFail: true
keepMsgProperties: true
enableDeformedMessages: false
messageId: "6a37dcbb40cb157a909ce3b5"
responseBuffer: object
data: array[1]
0: 65522
buffer: buffer[2]
0: 0xff
1: 0xf2
parse_buffer: buffer[2]
0: 0xff
1: 0xf2
specification: object
options: object
byteSwap: false
resultType: "keyvalue"
singleResult: true
msgProperty: "translated_payload"
setTopic: true
items: array[1]
0: object
name: "value"
type: "int16be"
offset: 0
length: 1
mask: ""
scale: "1"
offsetbit: 0
id: 0
value: -14
originalPayload: array[1]
0: 65522
values: array[1]
0: -14
objectResults: object
value: object
name: "value"
type: "int16be"
offset: 0
length: 1
mask: ""
scale: "1"
offsetbit: 0
id: 0
value: -14
keyvalues: object
value: -14
arrayResults: array[1]
0: object
name: "value"
type: "int16be"
offset: 0
length: 1
mask: ""
scale: "1"
offsetbit: 0
id: 0
value: -14
buffer: buffer[2]
0: 255
1: 242
translated_payload: object
value: -14
_event: "node:53ebc095797a50fc"
Buffer is at most two numbers, what you see is what you get. no objects burried in it.
For background. It is showing the communication with Modbus.
I do requests to my battery via modbus. A typical request or command has this format
let msg1 = {
"payload": {
"address": 31000,
"unitid": 1,
"fc": 3,
"quantity": 1
},
"topic": parseInt(msg.topic),
"data_type": data_type,
"property": msg.get_property,
"communication_status": "initialize"
};
What is being sent and received is maintained from the start till the end. as an object.
Not much data.
That is not the same as the message you posted previously with the large arrays. But whatever, first check if it is that chart that is consuming the CPU and then add the function node I suggested.
I have put this function node in front of one single chart. The one earlier used D2.
This function:
let msg1={};
msg1.topic = msg.topic;
msg1.payload = msg.payload;
return msg1;
This way I can be 100% sure there is nothing from the original msg being forwarded.
I will report back in 1 hour with the results. Should be visible then.
[offtopic]
For information only..
About the debug msg you saw earlier. It really contains hardly any data. It was a message from the same location.
responseBuffer:
data: [64935]
buffer:
0: 253
1: 167
The raw buffer contains "2 bytes"
which combine into one 16-bit value:
64935 (unsigned)
-601 (signed int16)
payload becomes:
payload: -601
[/offtopic]
The code I suggested would have been marginally more efficient and less typing.
Thanks, I'm learning still 
I have a status update for the CPU usage.
I have now only 1x D2 chart functional now instead of 2. So i presume the endpoint it will reach is also probably halved. ~3% instead of 6/7%
But for now, it does feel like the issue is still here.
I will wait for 1 or 2 hours more to be conclusive and report back.
To be clear;
This is the chart with the function node in front as you suggested.
messages going in:
It is the only D2 chart.
@Colin
Now with one graph, with the function in front, it looks a bit less severe compared to earlier
Red line is deployment.
You can see a steady increase, although it is not reaching the 3% as I expected yet.
But, the observation that the chart is using more CPU over time, is still visible.
Note: I did not have a dashboard open for the entire period.
I would not expect the browser being open to make a significant difference.
Are you restarting node red to reset the CPU usage or sending the chart an empty array? That is the best way, then you know it is definitely the chart.
If you want me to do something, Please tell me exactly what. In a bit more details.
But, if im correct, pressing 'clear chart' inside the chart node will result in a drop in cpu % directly.
I have not done anything yet. Waiting your instruction
That is good. So if that makes a difference to the cpu then I think that proves that it is the chart being full that is causing it.
Oke, I have let it dwell for a bit.
Using this one chart, it seems to stabilize at a lower cpu level than I anticipated. Which is good of course. See image below.
To verify, I will disable this chart, and enable the other chart with the P1 information. 1000 data point limit again, but a single topic this time.
I will again make sure that chart is being fed only a topic + payload as you have given.
I will reset both charts and wait for a couple of hours again.
The difference between the two charts, should only be the frequency of incoming data points. The new scenario has ~2,5x higher frequency.
It could be related to the dropping process of the oldest data point. But given that the cpu is slowly ramping up could also suggest it has to do with a different process.
I am puzzled.
Now with the 'crap'filter in front, it is not showing any signs of cpu increase..
a little bit a zigzag pattern, but nothing worrying.
1 = Graph 1 only (with filter)
2 = Graph 2 only (with filter)
I will test both graphs at the same time now, to see if that makes a difference.
If this is still all good (which it looks like it should be...) I will take out the filter again to see if I can reproduce the original behaviour.
This result is puzzling me....
@Colin
I have added both charts again, and now it is not increasing (with the filter in front)
I will remove the filter in front and see what happens now..
Sorry for the slow turnaround of feedback. Got tied up in other work too.
Oke, found it ! It is becoming clear now.
The 'crap-filter' removal did the trick.
So, apparently when the msg coming into the chart has a lot more 'crap' which is not actively used in the chart itself, it is generating cpu load...
Just to again give the example as what in my case is being sent towards the chart:
{
"payload": -433,
"topic": "M3 (Measured)",
"mac": "3C1ACCBAA19D",
"data_type": "int16",
"property": "battery_power",
"communication_status": "operational",
"scale": 1,
"unit": "W",
"precision": 1,
"friendly_name": "Battery Power",
"device_class": "power",
"state_class": "measurement",
"entry_type": "SENSOR_DEFINITIONS",
"_msgid": "16df34e86e841df2",
"messageId": "6a3d7abd40cb157a90acc984",
"modbusRequest": {
"unitid": 1,
"fc": 3,
"address": 30001,
"quantity": 1,
"emptyMsgOnFail": true,
"keepMsgProperties": true,
"enableDeformedMessages": false,
"messageId": "6a3d7abd40cb157a90acc984"
},
"responseBuffer": {
"data": [
65103
],
"buffer": [
254,
79
]
},
"parse_buffer": [
254,
79
],
"specification": {
"options": {
"byteSwap": false,
"resultType": "keyvalue",
"singleResult": true,
"msgProperty": "translated_payload",
"setTopic": true
},
"items": [
{
"name": "value",
"type": "int16be",
"offset": 0,
"length": 1,
"mask": "",
"scale": "1",
"offsetbit": 0,
"id": 0,
"value": -433
}
]
},
"originalPayload": [
65103
],
"values": [
-433
],
"objectResults": {
"value": {
"name": "value",
"type": "int16be",
"offset": 0,
"length": 1,
"mask": "",
"scale": "1",
"offsetbit": 0,
"id": 0,
"value": -433
}
},
"keyvalues": {
"value": -433
},
"arrayResults": [
{
"name": "value",
"type": "int16be",
"offset": 0,
"length": 1,
"mask": "",
"scale": "1",
"offsetbit": 0,
"id": 0,
"value": -433
}
],
"buffer": [
254,
79
],
"translated_payload": {
"value": -433
},
"_event": "node:53ebc095797a50fc"
}
This is a copy of the entire and full content of the object.
*And just to remind again. this is it. there are is no massive object inside something. *
"data":[65103] means "data" holds the value [65103]. This is not an object.
,"buffer":[254,79] holds the value 254 and 79. This is not an object with data or something.
It is the output of the Modbus node. node-red-contrib-modbus (node) - Node-RED
Thanks for doing the investigation. I am on the road at the moment but will try and replicate the issue when I return. Then I will post an issue and link to it here.
Does it make a difference if there is not a browser open looking at the chart?
Yeah no rush. Im glad to be able to help.
I do not think having a browser open or not makes a difference.
I removed the filter.
Shut down the windows pc from where I was using the browser
Then, after diner ~2 hours later, the result was as per image.
So this image/result was with no browser active
It could theoretically be of course that having a browser active has an effect. But I don't know yet, I did not test that.
ps
thanks @ totallyinformation for the formatting.
I was already messing with that.. but rather unsuccesful.
No worries. I just dumped it into VScode, formatted the doc and then pasted it back between Markdown code blocks: ```
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy