"Modbus Failure On State sending Get More About It By Logging"
guenter-ms opened this issue · 17 comments
Which node-red-contrib-modbus version are you using?
5.27.2
What happened?
I'm getting randomly the warning message "Modbus Failure On State sending Get More About It By Logging"
Server
"Modbus Flex Getter" Node
How can this be reproduced?
No.
What did you expect to happen?
I like to get more about it by logging. But I don't know how that can be achieved.
Can you provide information, how logging can be activated? Can you provide an example?
Thank you.
Other Information
No response
Go into the Node for the server and down the bottom under Show Errors is Logging, tick to enable. Then add a debug node after the server node and monitor the messages in debug.
Go into the Node for the server and down the bottom under Show Errors is Logging, tick to enable. Then add a debug node after the server node and monitor the messages in debug.
Thank you, but I do not understand.
What "server node" do you mean? Is it the "Modus Server" node, which is for testing?
I'm using the "Modbus Flex Getter" node, and checked "Show Errors" under the options tab, see screenshot.
But I do not get any logging data in the output, see 2nd screenshot.
Whats my mistake?
Your first post said
'Modbus-Server Node'
and this is the node I was referring to, flex getter node is not a modbus server node.
Your first post said
'Modbus-Server Node'
and this is the node I was referring to, flex getter node is not a modbus server node.
Yes, I'm sorry, that was wrong reported, and I did correct it. In my opinion the "modus server" is the photovoltaic system and I'm using the flex getter node as a client to get data. This works in general, but around 10 times a day I'm getting the mentioned warning which refers to Logging. And logging is what I try to get.
So have you added a debug node to the output of the flex getter mode so you can see what info it currently puts out.
Do you have any other kit connected to the PV Modbus Server.
Yes I have a debug node and I can see the data coming from PV, responseBuffer. Nothing more connected to PV.
Look at the screenshot and my general question is: Whats the reason and how can I "...get more about it by logging"?
Well I assume the message about logging is about logging on the server which is your PV inverter not the flex getter node. If the server was a node then you can turn on logging.
As its a comms issue even if you could get logging on the flex getter then how can it get the info when it has no link as the error is no link.
So you need to get access to the PV inverter logs and see if they have messages ref RS485 not being available.
For it to be only 10 messages a day it will be a minor issue.
- Is it actually giving you any problems or is it you just want rid of the messages.
- Is it RS485-RTU or RS484-TCP
If its RTU is the cable good stranded shielded twisted copper with 120ohm resistors both ends
If its TCP how good is the network connection, have you tested pings over a period including the messages appearing.
In the example above you are requesting 36 registers starting at address 0.
Do you have just this request or other requests with other address and quantity too ?
Maybe you can split this request into "smaler" one?
It is TCP RTU-buffered.
Will setup pings in parallel to check the network.
I'm getting the data from PV split into 4 parts due to number of registers, waiting 100ms in between.
Its a minor issue. It was interesting to me how to "get more about it by logging", assuming that there is a way to get closer information for investigation of root cause.
Have you tried "Defalut" instead of "RTU-BUFFERED"?
How are your timeout settings?
I cured a regular every 15 minutes with gap of 20 sec comms by turning off the Gui on a Pi plus only running one node-red flow. The Pi was getting overloaded.
Make one change only then test.
The Pi was getting overloaded.
Which model of RPi ? Cann't belief...
3b, hard wired ethernet, the cpu was not getting overloaded but there were 3 node red flows with modbus (all using same server), yasdi2mqtt running and MQTT server. Either a data pipe was getting overloaded or data was clashing. Only one flow has the issue strangely.
It is TCP RTU-buffered. Will setup pings in parallel to check the network. I'm getting the data from PV split into 4 parts due to number of registers, waiting 100ms in between. Its a minor issue. It was interesting to me how to "get more about it by logging", assuming that there is a way to get closer information for investigation of root cause.
may there are requests much too fast in communication and it is not supported in power of the server to call every 100ms - try 250ms or higher, because Modbus in RTU is more stable with more time. If the RTU server is closing on overload on its side you get a lot overhead in Node-RED to get re-connected and the results are much more worst then to communicate less with more time. What is the use case for the 100ms? In the most cases it is enough to read every 1 sec.
Hi, changed to 250ms. Will observe.
This issue is stale because it has been open 60 days with no activity. It will be closed in 30 days, but can be saved by removing the stale label or commenting.
Is stable now. Very seldom timeouts on the network.