Hi, @Colin
I'm sorry to be late.
The node you are using is a URL.
Maybe it's not the node you told me?
I can see the log output in the debug message, but how should I write it as a trigger?
Yes, the one you are using is a different node. If you follow the link you sent and then the link to the github repo you will see that it has not been updated for a couple of years and there are a number of unanswered issues on the Issues tab, which suggests the node is not well supported, so probably it will not get fixed.
Try using a Catch node and a Status node attached to the azure node and see if you get a useful message when it fails. Connect those nodes to separate (named) debug nodes set to Show Complete Message so you can see what is there. If you get something useful you should be able to use that to restart node-red.
Hi.
I tried setting a catch node, but it doesn't catch the error.
I don't know how to get the message to debug and how to pick it up.
The catch node will only catch errors by nodes that are 1.0 compliant in their message handling i think. Which this one most probably isnât when it hasnât been updated in a couple of years.
1 Like
I See...
I am a little confused.
It is a problem that it cannot automatically recover when the connection with Azure IoT Hub is lost.
I don't know how to solve it. Want to cry¡¡¡
Let's start again, how can you tell that it has disconnected, other than looking at the status on screen? Does it send anything on its output that indicates disconnection? Perhaps it stops sending messages on its output when it has disconnected. If we can find a way to know that it has stopped then we can do something about it (even if it means forcing a node red restart).
@Colin
Thank you so much for helping me.
I would like to organize again.
If the connection is lost, the following will occur.
Under the node of Azure IoT Hub, "Error" is displayed.
The debug message says "Error while trying to send message: Error: cliend disconnecting".
At the moment the situation looks like this.
Than what i wrote right at the top in my first post is true. You can use the status node. The status node can be used to watch the status text that you see under specific nodes. It will output a message when this text changes with the text in msg.status.text i think. As your node is showing error under the node:
You can use switch node connected to a status node watching this node to only act when this error status appears. This doesnât give you the whole message but at least it should give you something to work with.
Johannes
That is also what I suggested earlier. You said you tried the Catch node and nothing appeared but I realise now that you have not confirmed whether the Status node does see it.
I tried using the status node.
It showed the "Error" status in the debug message.
Can this bug be dealt with by using this debug message as a trigger?
Yes it could
Look at the Switch node, you can use the Contains option to send on only if message.status.text is Error. Then you can use that output to trigger the operation.
[Edit] Of course you could also use a switch on the main node output and look for payload Contains Error.
No i donât think this works. As the message in the debug comes straight from the node and node the debug connected to it as it comes from the node calling node.error() and this doesnât get passed along the normal wires. The only way to get hold of that error message would be to watch the actual log file for it as it gets written there. So i think acting on the output of the status node is still the best/easiest bet.
Yes, you are right, I had forgotten the earlier posts in the thread and was mislead by the image above which accidentally gives the impression that the two messages are from the debug nodes, whereas as you say the first one is direct from the node, not from the attached debug node.
So @yossy4 use a Switch on the Status node.
1 Like
Little question: When you just try to send the message again after waiting a few seconds does it reconnect and work than or do you have to restart the flow?
1 Like
Hi.
I made it based on your information.
But maybe my way is wrong.
I have a problem that Node-RED does not start in the middle.
Hi, @JGKK
O, no, no, no!
Originally I do not want to restart the flow.
If an Azure IoT Hub node encounters an "Error", the only way to recover from the error is to restart the flow and I have found it.
Unfortunately, the Azure IoT Hub node doesn't seem to retry after an error, even after waiting a few seconds. (Is there such an option in the first place?)
There is no good solution.
Do you have any good ideas?
Thanks.
I can't see what condition you have set in the switch statement, the left hand side of the image is missing. Put a debug node on the switch output and check it is working.
You cannot restart Node-RED like this.
The node-red-stop call will stop Node-RED. That includes killing all its child processes, including your exec node. That means it gets killed before it gets to the node-red-start command.
sudo systemctl restart nodered
should do it. But you need the switch to be right first.
1 Like
