Today I had to do some troubleshooting related to mbus errors in node red. Something I find notable in Node-RED is how many request nodes are silent when an error occurs. They don't send any output at all! Which is super annoying, since nothing is logged and you just stumble across missing data elsewhere in the system. Is it less of a concern in the broader node-red community about requests that fail? HTTP is pretty clean about it, with various status codes. Worked with other protocols like Bacnet, mbus, modbus etc. and there it is often times not so clean.
Anyone got a simple solution to make sure an input always generates and output after a set timeout? Thinking about wrapping all request nodes that fail to produce error ouput into subflows.
Ah sorry I misinterpreted this generalisation to mean http request node. You mean all types of request nodes that are defined in Node-RED.
So you're asking is there a kind of "best practice" when creating a request-X node in node-red (where X is anything that requests a external connection i.e. serial, http, snmp, ftp, ...).
I would have thought that would be the catch node that caught exceptions.
and it does work, there is indeed more details in the debug node about errors that occur when the modbus mode attempts to make a connection to a device.
I would submit an issue against the node. It should throw catchable errors when something goes wrong.
As for getting round the problem, use a trigger node set to send nothing immediately, then an error indication after a timeout. Start that with the message that you send to the mbus node, then use a reply from mbus to reset the trigger.
Yeah could have used a better description than 'request nodes', what I meant was basically any node that says "hey you, I want to read some data" or write data. Basically I/O. One example is http, which in my experience always returns an output "no matter what" (I'm sure there are some caveats like power outage hehe but you get what I mean).
I'm not so much asking if there is a best practice for creating I/O nodes, I firmly believe the best practic is (or should be?) to always produce an output. My question is rather why this seemingly is not the case in node red?
Whether it's output as a message with error property, or sent to a catch node is less important. I can work with both of those options. What I'm so often facing is neither.
Thanks, I had something like that in mind but wasn't sure about the details. Perhaps I will try it out later, need to fix the root cause regardless first.
Is touches on the old debate "exception driven programming" - should exceptions be used as control logic? Generally the answer is no, exceptions are just that - unhandled situations that haven't be covered by code and are unpredictable in their occurance.
So having an unreachable host when using http request (for example) - this can be handled in code and a message be sent on the output wire "host was not reachable". Then you would need to add logic to handle that case - that's what http status values are actually for.
Hence the http request node would probably through an exception if a host is down (this is abnormal) and generate an output message for 404 status code - both are error conditions but one is abnormal and the other is covered by the protocol (HTTP in this case).
Therefore I would argue that having a catch to handle exceptions is perfectly ok since it means that the rest of the flow probably won't work. Potentially the handling of that is the same as a 404 error but that's up to the developer.
I must have explained myself poorly because I don't care so much whether the output is a msg (with props to describe) or an exception to be caught in a catch node. What I care about is that it produces "something", no matter what that "something" is. In contrast to being, well as the title says: dead silent - a black hole. If I get "something", I can log the error to see when it started, how long it lasts, and possibly when it stopped. This is in my experience always useful - particularly in relation to upgrades, which I just went through today, and then later accidentally noticed that some data wasn't being sent, because this particular mbus node decided to shut up without any notice that I'm able to handle. At least it shows up in debug sidebar, so is visible IF you log into node-red in web browser...
I was looking at the code - if you're using node-red-contrib-m-bus and to me it appears as if the node just logs errors to the console.
I'm no expert for this node and I just scanned the code but if that is indeed the case - all errors are logged to the terminal, then that is indeed not a very useful thing to be doing.
It basically means that the flow cannot recover from or retry or replay the error.
