This is another error I am seeing on a different machine

This is an interesting error I am seeing.

Where 89c38d55.164f48
What Key in object structure must evaluate to a string; got: undefined

Ok, the node mentioned:

This is the node's code:


What is happening?

Sorry: Other information.

3B Stretch
NR 1.2.6
Dashboard 2.26.1

I don't see the error in the debug pane in your screenshot. I would like to see the full error and anything else around it.

Edit: Restart node-red and refresh the browser page first

That's because it happens when I am not looking. (Kind of like that with errors. They seldom comply with requests to happen.)

zgrep -i --color=always -A 10 -B 10 "Key in object structure" /var/log/syslog* | awk -F: '{if(f!=$1)print "=========="; f=$1; print $0;}'
and it should find all recent occurrences or that error and print 10 syslog lines before and after each one to see if there are any other related messages. for me it prints those from the most recent syslog file first but I don't know if that is guaranteed.

(From post 1, this is "BedPi" who has this error.


I am not convinced that what you think happened actually happened.

1 Like


But it is annoying to me that I am seeing these errors that don't make sense to me.

Where do the Where and What in the message you posted come from? Are these messages that you have detected in your flow and logged in some way?
If so I would be concerned that there is some flaw in that logic. I find it difficult to see how an Inject node that isn't even configured to repeat or fire on startup could generate such an error. That is what the image you posted is showing isn't it? On top of that the error isn't even getting logged by the system apparently

Is there a timestamp with the error?

(Thanks Colin for the replies.)

Yes, the message is being generated by an "error catching routine" I have written.
(Do you want me to post that?)

That is written to a file and I extract that information from the file.

The message is slightly altered as it also needs to go over MQTT, so all important things need to be in the payload part of the message.

Though I have been wrong many times before the error routine does seem to be good as I do get other errors and when I drill down on the message, it is pointing to the correct node.

You didn't answer the question:

Sorry... Yes, the timestamp is generated with the error on capture. It is LOCAL time also.

In that case what do you see in syslog at that time. If it is a real error from a node then I would expect a message there.
Are you sure you are looking at the right pi?

Good question.

Yes, I am. The first screen shot. x.83

You posted the command to search and you see the CLI/Terminal is BedPi. That is x.83.

The only thing is that maybe the error happened before I set the save to log and so wasn't captured at that stage.

And so I am stuck at this point.

Do you mean you don't attach the timestamp when the error happens, but when you write it to the file?

Did you look in syslog at the time you think the error occurred?

The time stamp is generated in the capture part of the flow after the catch node.
Then written to the file as a compound message.

So, I ask again (third time), what do you see in syslog at the time of the error?

I showed you what the syslog shows when I enter the command you posted.

It shows nothing.

No matches.

Hang on. Here is an extract of said syslog.
(ok, sorry. First what I created in my error log:

When 2021-01-16 08:07:34
Who ERROR_REPORT/BedPi/Schedule
Where 89c38d55.164f48
What Key in object structure must evaluate to a string; got: undefined

/var/log/syslog ends (this is weird.)
I have syslog and syslog.1 and they both end near the same time.

I'm confused.

Hang on.....

So the time/date is: 20201 01 16 @ 08:07:34

The syslog files start on Jan 30.

I don't know how to access .gz files from the terminal.

syslog is the newest, then syslog.1, which probably isn't zipped. It probably doesn't end at the same time, well it does but the day before.
But if the date is 16th Jan then the message is probably long gone. syslog usually rolls over once a day unless you are logging a lot in which case it will roll over more quickly. I think the default is the current one and seven previous so once it is a week old it is too late.

You will have to wait till it happens again.

Looking at the others they don't go back that long. :frowning:

pi@BedPi:/var/log $ ll syslog*
-rw-r----- 1 root adm 26537 Jan 31 08:40 syslog
-rw-r----- 1 root adm 44034 Jan 31 06:25 syslog.1
-rw-r----- 1 root adm  4032 Jan 30 06:25 syslog.2.gz
-rw-r----- 1 root adm  3727 Jan 29 06:25 syslog.3.gz
-rw-r----- 1 root adm  3908 Jan 28 06:25 syslog.4.gz
-rw-r----- 1 root adm  3863 Jan 27 06:25 syslog.5.gz
-rw-r----- 1 root adm  3827 Jan 26 06:25 syslog.6.gz
-rw-r----- 1 root adm  3737 Jan 25 06:25 syslog.7.gz
pi@BedPi:/var/log $ 


I assume our posts crossed so you hadn't seen my previous one.
That confirms your system is as I would expect, you get a week or thereabouts retained.
It also explains why the command I suggested which searches the whole set didn't find anything.

1 Like