Problem to display state from device


I am still fresh to the Node Red, seeking for some help for displaying the status of my S7-1200 PLC with the node-red-contrib-ui-state-trail.
It can be display when the S7 is sending value, so I am able to use a change node to change the integer value to boolean for display On.
But I wonder how to display for the S7 off status, because when I tried to disconnect my S7, I can't get any value from it, only the debug message showing msg : string[20] "Failure (Bad values)".
So, I would like get any solution or method for me to achieve my objective.
Thank you in advance.

Best Regards.

You can use a CHANGE node with a REGEX to match this string (above) and change it to false, if that is the message you getting, for example.

1 Like

Hi unixneo,

Thanks for your suggestion, I would like to try with your method. But the error message on debug message not come from any node. (I try to put debug node on every node, but didn't get any output.) So, I wonder which type of the input for REGEX match in a switch node in order to get for the error string, such as msg.payload/flow.payload/global.payload etc :zipper_mouth_face:

Best Regards.

Honestly, netsuko93 ... it is hard to understand what you are debugging, where and when and how.

It's best to work in a simple, step-by-step manner when debugging (not put debug nodes on every node, as you said).

In your diagram, your first node is labeled "S7-1200 Read" and that node nodes "failure".

So, you should turn off all the other debug nodes (for now) and only put one debug node at the output of that single "S7-1200 Read" node, and make sure the debug node is for the entire message object (not just the payload).

Then, you can easily see the entire msg object and what are the strings and stats the "S7-1200 Read" node fails (and of course, when it succeeds). Then, post that output clearly (not just a screenshot) between "code tags" so we can easily read it, clearly and precisely.

Normally, as I am sure you realize, when we have an issue the best place to start is "at the beginning" in a step-by-step, logical manner. It often sounds strange, but usually the fastest way to solve a problem is to go in a slow, step-by-step way, starting with the first message object.

1 Like

Dear unixneo,

Thanks for your advise, actually my boss ask me to implement a dashboard to show the machine run time by using the Node Red and I tried to put the state ON when it receive value from the S7-1200 device, but I realized it didn't send any value when I tried to disconnect it for trying to display the state OFF.
So, now I start from the beginning with only S7-1200 Read node and debug node. But I not sure which is the tag code, but I tried to expand it. Hopefully you can see clearly. :persevere:

  1. Image below shows the "msg.payload" [success without failure]
  2. Image below shows the "complete msg object" [success without failure]
  3. Image below shows the "complete msg object" [disconnected failure]

    I'm struggled with this problem. :confused:

Best Regards.

You should change the debug node on failure to show the entire msg object, not only the msg.payload.

Generally, when debugging, it is best to show the entire msg object, especially when you want to build a SWITCH or CHANGE node; but in general, debug with the entire msg object (especially when you are "struggling" to find "causes" and potential solutions).

Hmmm...The output display I get for both of msg.payload and entire msg object is the same.
Image below shows the " entire msg object " [disconnected failure]


So, you can easily add a SWITCH node to switch based on a number of ideas and add the OTHERWISE node for the exceptions.

If it was me, I would try to first SWITCH on msg.payload perhaps using contains or has key but the choice is yours (based on what you want to switch on) and SWITCH OTHERWISE and you are done, with a little bit of testing.

For example (but you should experiment on your own to learn, based on how you want to switch between true and false, etc):

Screen Shot 2020-03-03 at 11.25.20 AM

You should be "good to go" with this information. Try first and enjoy Node-RED where:

"Logic Transforms into Art and Beauty" :slight_smile:

(just made that up, but is sounds about right, LOL)

1 Like

After looking at your screenshots and data, I don't think your S7 Read node does send anything at all because it likely throws an error. The debug won't get any messages in this case, and any switch based on that won't work either.

So, try adding a catch node, select the S7 node as target and wire a debug node to that catch node in "complete msg" mode.

Here's more documentation on how to handle errors properly:

1 Like

Hi kuema, yes u're right!

S7 Read node doesn't send anything when its failure. I also tried to use the catch node for error, but also get nothing. Anyway, I had found a solution using a ping node to get the status for my device and it's work.
:rofl: Thank you for spending time wrote your suggestion here.
Best Regards.

Then the S7 node is probably only setting it's node status to "failure" and doesn't send an error.

You could use a status node in this case and filter the failure events instead. Same procedure as with the catch node. :sweat_smile:

But ping should work too.

OR... use a trigger node to act as a watchdog that sends a message if none has been received for x seconds. :thinking: Endless possibilities.

1 Like

Dear kuema,

I had tried the status node, but it displayed "undefined" when my device is online.
Trigger node need to key in the input right? I never use the trigger node before, but I need the instant feedback, so changing state after few seconds I think it's not suitable for my objective. :face_with_monocle:

Best Regards.

The status node uses msg.status, not payload. Just attach a debug with "complete message". I don't know what status events the S7 node is sending, so you would need to investigate that yourself. :slightly_smiling_face:

Ah, okay. It was just an idea. I am using that timeout pattern for my sensors a lot. :sweat_smile:

Okay thanks, I'll try for it.
Anyway, do you guys know how to select any flow to run or to stop? :confused:
I just made a jumping flow after the device status is disconnected by using ui_control node. But I found that it keep stuck at the flow unless it get connected back. :persevere:

You can disable the entire tab and/or individual nodes in the node property dialog (at the bottom).

It will work easily if you manage by exception as I have illustrated.

I do this all the time on other flows.

Managing by exception in a switch is very easy.

It's trivial to do if you follow what I have advised; which is to switch between when it has a "correct reading" to when does not have any correct reading.

Sorry to be repetitive but I have this exact same problem on.a number of nodes, and I handle all of them this way, and it works fine.!

FYI, these are messages:

Screen Shot 2020-03-03 at 6.17.52 PM|176x183

FYI: these are messages:

Screen Shot 2020-03-03 at 6.19.35 PM

This is trivial to solve with a switch node. The switch node will switch on a message. If it has the right payload it will switch to the designated node. OTHERWISE is will switch to another node.

The failure is the exception and it can be done in a switch because, as mentioned, I do this in a number of nodes in my flows just like this with the same issue (but different device).

As I understood the OP, we confirmed that the S7 node seems to "misbehave" and does send neither a message that indicates a failure (to be used by switch), nor does it throw an error message that can be caught be the catch node. So there's no message to go on.

The one thing it does is updating its status on failure. So that would be the only place to start an error handling flow.

However, I haven't used the S7, so these assumptions are based on the info that @jan-k provided. :sweat_smile:

@jan-k: Are you using the node?

1 Like

I just had a brief look at the source code of the S7 node. They don't pass the input message to the error handler function node.error(), so catch nodes will never get triggered.

So in this state, there is no way to handle errors properly. You could raise an issue with the node's author to improve the code on that matter.

1 Like

Yes yes, I'm using that node! :laughing:

Exactly! :+1: