This flow (on one machine) works. On another machine it doesn't

General
1

I have a flow (with non-standard nodes) and it works on "machine A".

I have worked out it is easier to export entire flow tabs rather than mess around importing parts.

So here is a picture of it on "machine A":

Screenshot%20from%202019-08-31%2013-20-53
Screenshot from 2019-08-31 13-20-53.png1360Ă—768 153 KB

It is the node circled of interest.
Note the inputs to the node - shown from the debug node. (red lines)

As those "messages" work, I copied one and injected it on "machine B" - to really see what's going on - and I get an error.

Screenshot%20from%202019-08-31%2013-23-58
Screenshot from 2019-08-31 13-23-58.png1360Ă—768 137 KB

The version of the node is the same on both machines.

Thoughts?

Here is the message: (One of the many)

{"payload":{"who":"Machine Health","payload":"orangered"},"topic":"softTempLimitOccurred","_msgid":"17b45638.a4e69a","state":false,"event_time":"2019-8-31 13:13:40","_event":"node:c73d5b1e.6ed038","time":"2019-8-31 13:13:40"}

The node in question is node-red-contrib-ring-buffer

2

Analys EXACTLY and COMPARE the msg's going INTO the ring buffer nodes in resp flow and you might find the answer

3

I shall.

It just confuses me that on "machine A" the flow works.

Copying the entire flow (tab) onto "machine B" it gives an error.

4

Ok, I see that in one the date is the other way around.

Rather than being yyyy/mm/dd is it dd/mm/yyyy
(be it / or - between the numbers.)

In the mean time have had two RPIs die on me.
NR loads, but any modifications to the flow, they just lock up.

Starting in --safe mode is ok. But only one change can be done, deployed and it works.

Subsequent deploys it just hangs.
(Gotta love computers)

5

It is almost never the computers fault.

3 Likes
6

True. But the . . . . annoying part that it works on one machine and not another.

Other than the date being the "wrong way around" between the messages.
(I have now got two machines which won't boot to NR.)
(How do I recover a draft message I was typing when you replied?)
(Scratch the last part. The button goes from NEW POST to RECOVER DRAFT - or something like that)

7

There must be a reason for the difference. It is just basic debugging. Work back through the flow using debug nodes to find where the problem starts. We cannot do that for you.

8

It doesn't help when the errors mean nothing to me.

I think my nodejs needs updating.

On the bad machine is is 6.? and on other machines it is 8.?

That may be a problem.

Investigating it in the back ground while trying to work out why the other machine just locks up.

9

Didn’t you rule that out in your very first post

10

At time of posting the version of node wasn't understood to be . . . needed.

I looked up the error and read something about an old version of node.

So, I didn't know it was needed to be updated.

I can't declare what I don't know.

11

Why have you got question marks on the versions, don't you know? It is easy to find out by restarting node-red and looking at the versions given in the startup log. If you have got 6.x on one of the Pis how did you get to that state? Don't you use the recommended install/upgrade script to install node-red?
How did you end up with nodejs 6.x

12

Because I don't have the exact value available.

I know that one machine (the faulty one) was 6 and another was 8.

Is the exact version critical or is 6 to 8 good enough?

pi@PIFACE:~ $ node -v
v6.17.1
pi@PIFACE:~ $

I have done the bash <(curl -sL https://raw.githubusercontent.com/node-red/raspbian-deb-package/master/resources/update-nodejs-and-nodered) command on that machine several times.

So I am again missing something.

The other (working) machine is:

pi@TelePi:~ $ node -v
v8.12.0
pi@TelePi:~ $
13

Well you should not end up with node 6.x, I don't think that has ever been a supported version, and now you need at least 8. Run the script again and look at the install log. Post the log here if you can't see what is going on with nodejs.

14

If you are asking for help solving a problem then making statements that you haven’t checked is going to make it much harder to solve. Stick to the facts .

15

I am trying to.

Your question to me implies I somehow know that the node is/was needed for this problem.

I took the step and looked into the error. It mentioned the node. Maybe I should have looked before posting, but hindsight is always perfect.

If I don't know something is needed how do I know I should declare its version?

(While all this is going on I have seen another monster which has kind of bitten me too.)
Seems I am going to have to put in a lot of computer time in the near future.

16

My question implies nothing of the sort.

You state in your very first post that the version of node was the same.

Later on you state that it is different.

One of these statements is false. If you don’t know that the version of node is the same don’t say that it is (or even better check first).

It doesn’t matter if the issue is the version of nodejs or not. Stating something as fact which isn’t true isn’t going to help anyone diagnose what the problem is.

17

(argh!)

The version of the node in question. That being node-red-contrib-ring-buffer

Not node (or nodejs)