as many other people here, I use Node Red to read data from a smart meter via Modbus RTU.
At first, this works great, but after a few hours, Node Red slows down and gets unusable.
The smart meter is a Eastron SDM630.
Node Red runs on a RPi 4 with following serial converter:
I read 36 values with 2 16-bit registers each, cycle time is 2 seconds.
For this, I use seperate modbus-flex-getter nodes from node-red-contrib-modbus.
I will attach the code as soon as possible.
In the first 2 hours, everything runs smoothly and looks perfekt.
But as time goes by, the dashboard gets slower and takes longer time to respond.
After around 12 hours, its completly unusable with response times of around 30 seconds.
A restart of Node Red brings back the original performance.
Interestingly, the task manager stays at 10-15% load the whole time.
My questions:
Is there an infinite loop in my flow?
Is the node creating a new connection every time?
What is the difference between RTU and RTU-BUFFERED?
What can I do to increase perfomance?
hello .. it would be good if you mentioned what ui components you are using on your dashboard. text, gauges, charts, tables ? maybe share a screenshot or better your flow
When this slowdown is observed .. have you checked (with a Debug node after the Modbus node) if the data from the meter is still arriving at the rate of 2 sec ? This could help you cut down the issue... Could it be possible that the modbus meter cannot handle 36 value requests at such a rate ?
This flow is only reading the data from the smart meter and displaying it as text on the dashboard.
I also have some other flows, where I connected devices via API and Modbus TCP, these flows work without a problem.
These flows also contain graphs, with time limited to 24 hours.
I diagnosed the problem by deactivating my Modbus RTU flow, without it everything ran great for a week.
I think the smart meter can handle it.
I already used it for a different project with a much higher polling rate, but there I used C and libmodbus.
And as I said, the first 2 hours it works like a charm.
Attached are screenshots of my flow.
As a new user, I can't upload my source code at the moment, I'm sorry.
Please let me know if there is a way to change this.
Can you list out the registered you access & I'll tell you how to consolidate those into a very simple flow.
I know you said you have narrowed it down to the modbus stuff but It could be compounding the issue. How often do you send data to the graph? If it is every 1 second then your browser will be trying to show 86400 points on the screen & I am pretty sure that is more than the width of your display (in pixels). To clarify: Don't send more points to your graph than there are pixels in the width of your display otherwise you are simply wasting process cycles.
This makes a lot of sense, I never thought about it this way.
I will try to optimize my graphs on this issue.
I tried to to read more register at once and found an interesting problem.
Response significantly increases with the number of registers.
2 registers -> immidiate response, even with the other nodes in parallel
10 registers -> ~ 2 seconds response time, no other nodes in parallel
30 registers -> over 10 seconds response time, no other nodes in parallel
I will have a look at the serial connection when I get home.
Does anyone have an idea what might cause this?
The difference between 2 and 30 registers is 56 bytes. There is no way it should take anywhere near that long. From experience the time difference can normally be measured in single digit milliseconds! Maybe there are some addresses in the range that don't exist?
EDIT
Can you share a small flow (no dashboard nodes etc) setup to get 30 registers, that demonstrates this problem - I am intrigued.
