Feasability of migrating to dashboard 2.0

Dashboard
21

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.

22

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

23

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.

24

Looks terrifying ... but the reality is less shocking :smiley:

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.

25

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.

26

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]

27

The code I suggested would have been marginally more efficient and less typing.

28

Thanks, I'm learning still :slight_smile:

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.

image
image952×363 24.4 KB

To be clear;
This is the chart with the function node in front as you suggested.
messages going in:

image
image681×521 15.5 KB

It is the only D2 chart.

29

@Colin
Now with one graph, with the function in front, it looks a bit less severe compared to earlier

image
image952×405 68.9 KB

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.

30

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.

31

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 :slight_smile:

32

Sorry, I read incorrectly from my phone.
I am not restarting node red.
I am only pressing the clear chart button
or sending this towards it.

image
image582×249 6.56 KB

33

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.

34

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.

image
image956×366 62 KB

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.

35

@Colin

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.

image
image957×366 59.7 KB

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....