And again more confustion about error handling


Ok, at the beginning I was silly. I didn't get all the quirks with MQTT and msg.error.

I think I have moved forward from there but "it" still doesn't seem to be working.

Though the long way, I'll start with knowns and work towards the error.
That way it may help you see how I am confused rather than me post the real order in which things happened.

To generate an error I have this:

[{"id":"cf90dcaa.cb5a1","type":"inject","z":"98cfac7a.d84cf8","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":1220,"y":740,"wires":[["28da7698.4e18d2"]]},{"id":"28da7698.4e18d2","type":"function","z":"98cfac7a.d84cf8","name":"","func":"j = index.of(blah);\nreturn msg;","outputs":1,"noerr":0,"x":1400,"y":740,"wires":[[]]}]

It makes a nice:

"ReferenceError: index is not defined (line 1, col 5)"

Error in the DEBUG window.

That is in a flow with no CATCH node.

I have this code on any needed flows to catch any errors and report them back.
Yes, some nodes need editing to give the correct names. Thought I should declare that.

So, the nodes have the right names.

[{"id":"ae688514.9c35a","type":"comment","z":"98cfac7a.d84cf8","name":"Error catching","info":"","x":130,"y":880,"wires":[]},{"id":"c542bea1.39266","type":"catch","z":"98cfac7a.d84cf8","name":"","scope":null,"x":130,"y":920,"wires":[["d08624b3.de1ca8"]]},{"id":"19adcc0e.9befbc","type":"mqtt out","z":"98cfac7a.d84cf8","name":"ERROR_REPORT","topic":"","qos":"","retain":"","broker":"af39dd36.0e8058","x":980,"y":920,"wires":[]},{"id":"e8471ea7.f7e1e8","type":"inject","z":"98cfac7a.d84cf8","name":"","topic":"","payload":"Test","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":140,"y":970,"wires":[["d08624b3.de1ca8"]]},{"id":"9815e08.0b8cf2","type":"debug","z":"98cfac7a.d84cf8","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","x":1100,"y":970,"wires":[]},{"id":"e85a793d.fd2ee8","type":"simple-queue","z":"98cfac7a.d84cf8","name":"queue1","x":950,"y":970,"wires":[["9815e08.0b8cf2"]]},{"id":"3b7f4d56.4fd6ea","type":"change","z":"98cfac7a.d84cf8","name":"Read","rules":[{"t":"set","p":"trigger","pt":"msg","to":"1","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":270,"y":1010,"wires":[["e85a793d.fd2ee8"]]},{"id":"34b6685a.f54c68","type":"change","z":"98cfac7a.d84cf8","name":"Wipe","rules":[{"t":"set","p":"reset","pt":"msg","to":"1","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":270,"y":1050,"wires":[["e85a793d.fd2ee8"]]},{"id":"c41ab019.3587d","type":"inject","z":"98cfac7a.d84cf8","name":"Wipe","topic":"","payload":" ","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":"","x":140,"y":1050,"wires":[["34b6685a.f54c68"]]},{"id":"ba2e4c37.49b1a8","type":"inject","z":"98cfac7a.d84cf8","name":"Read","topic":"","payload":" ","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":"","x":140,"y":1010,"wires":[["3b7f4d56.4fd6ea"]]},{"id":"d08624b3.de1ca8","type":"function","z":"98cfac7a.d84cf8","name":"Name flow","func":"msg.topic = \"Local Readings\";\nreturn msg;","outputs":1,"noerr":0,"x":280,"y":920,"wires":[["ac65f9f0.e3fa9"]]},{"id":"ac65f9f0.e3fa9","type":"change","z":"98cfac7a.d84cf8","name":"","rules":[{"t":"set","p":"error","pt":"msg","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":450,"y":920,"wires":[["cf3a10d9.9043d","26edae58.39e532"]]},{"id":"a11384d1.34a88","type":"function","z":"98cfac7a.d84cf8","name":"Set topic","func":"var device_name =global.get('myDeviceName');\nmsg.topic =\"ERROR_REPORT/\" + device_name + \"/\" + msg.topic;\nreturn msg;","outputs":1,"noerr":0,"x":810,"y":920,"wires":[["19adcc0e.9befbc","e85a793d.fd2ee8"]]},{"id":"4a395e4a.3fd61","type":"link in","z":"98cfac7a.d84cf8","name":"","links":["585d89f4.3fa05"],"x":705,"y":960,"wires":[["a11384d1.34a88"]]},{"id":"17fe672e.a2aed1","type":"inject","z":"98cfac7a.d84cf8","name":"","topic":"","payload":"stop","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":478,"y":830,"wires":[["cf3a10d9.9043d"]]},{"id":"8145c990.cacbf8","type":"inject","z":"98cfac7a.d84cf8","name":"","topic":"","payload":"go","payloadType":"str","repeat":"","crontab":"","once":true,"onceDelay":"1","x":478,"y":870,"wires":[["cf3a10d9.9043d"]]},{"id":"cf3a10d9.9043d","type":"traffic","z":"98cfac7a.d84cf8","name":"","property_allow":"payload","filter_allow":"go","ignore_case_allow":false,"negate_allow":false,"send_allow":false,"property_stop":"payload","filter_stop":"stop","ignore_case_stop":false,"negate_stop":false,"send_stop":false,"default_start":false,"differ":false,"x":648,"y":920,"wires":[["a11384d1.34a88"]]},{"id":"26edae58.39e532","type":"debug","z":"98cfac7a.d84cf8","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","x":630,"y":880,"wires":[]},{"id":"af39dd36.0e8058","type":"mqtt-broker","z":"","broker":"","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"20","cleansession":true,"birthTopic":"SOM","birthQos":"2","birthPayload":"'Awaiting Music Pi'","willTopic":"EOM","willQos":"2","willPayload":"'MusicPi telemetry failure'"}]

Now if I put the first bit of code on THAT flow/tab, and press the inject button, I get:

local Readings : msg : Object
_msgid: "e0033ac7.5a9ed8"
topic: "Local Readings"
payload: 1535861136083
error: 1535861136083
_error: object

at the first debug node.
Pressing the READ button (inject node) I get the same at the second debug node.

I was told that MQTT doesn't handle error message when I was sending messages over it, and was shown how to get around that.
Which is what I have done with the CHANGE node.
But that's academic because all this is way before MQTT is used.

So what is happening to the error message?

I'll dig around too, but (as you may have guessed:) I need to ask.




Seems I did that silly ting with the CHANGE node.

Rather than setting the msg.payload to msg.error, I was setting msg.error to msg.payload.

Reversed the names and it seems to be working a lot better.

Sorry. I shall again say that how the CHANGE node is worded is confusing as it isn't (to me) intuitive.

I know it is not as easy but I think of things that I move the first value to the second.
But it REALLY sets the first one to the second one.




I think of it as being the same as a standard line of code :

msg.payload = msg.error

but written vertically





Yes, but when you go to other options (can't remember now exactly) the layout looks ok.

But to me, when I see the layout I get which is which reversed.

I just looked and now it kind of makes sense, but maybe because the threshold has been passed.

I hope I don't keep falling into that problem. But I don't often use that node.



Are you saying that you expect
to Move msg.error to msg.payload

If so what you expect this to do?



That's where I fall over.

In the first example, I see it as setting msg.error to msg.payload.

In the second one - which is "more intuitive" (cringing at that) is that msg.error gets MOVED to msg.payload.

But in the second one the direction of what is moved is the other way.

I think I am too confused at this point.

(Shakes head to try and clear things.)

Ok, here is what I have NOW.

I had that the other way around thinking (and reading it) that it would move msg.error TO msg.payload.

But because the SET word is used I am/was/(still am?) confused.

In your second example where you have/say MOVE msg.error. TO msg.payload that is the way it moves - or so you are saying.

All I know is that with it how it is NOW shown, it works.

I had it the other way around and it was failing because the error message wasn't getting through to the next stage.

Am I more confused? Probably. Sorry if I am waffing now, but I am still confused.

I think that will really help me.




I sympathise with your confusion - I thought it was just me! :slight_smile:

Quite a few times I've struggled to debug something and its because I've done it the wrong way around

I only get it wrong when using msg properties - I'm fine when using it to set flow ones




What "annoys" (or confuses?) me is that with the MOVE, it makes sense.

I MOVE a to b.

b = a

But with SET.....

I parse it as SET a to b Or a = b, when it is setting b to a. (Or have I got that around the wrong way? The more I think about it the more it hurts.)



That is because the first one does not Move it Sets.
I do agree that it could be improved a little. If Set changed the word before the second field, currently "to" to "from" so the Set screen read "Set msg.payload from msg.whatever" it would be less capable of misinterpretation I think. Whether that word could be made to change with the selection in the dropdown I don't know.



The way to improve it would be to make the change always the same direction.

So if you say:


Then: B = A. (But B is negated, or what ever)

If you say SET A -> B

Then B = A. Same Direction.

But that's just me. Keeping things the same.



Forget about the change node for the moment. What would you expect to happen if I said
Set msg.payload to 7



Yes, I get it here, now.

But "SET" throws me - when used with MOVE.

SET msg.payload to 7

msg.payload = 7.

But I am getting what/where you are going.
Just if I am silly enough to fall for it, who else could?

So when MOVE is used..... argh, I give up. (cheeky wink)

But thanks.
I am starting to get the idea.



Just think
Set msg.payload to 7
Move the dagger to the billiard room
The difference in direction is implicit in the English language. I guess for non-English speakers it may well be even more confusing.

1 Like


Well, I won't argue with that at all.

Lesson learned.



I've always said the same thing -- the fact that the "Set" option is reversed from the "Move" logic has always tripped me up.

I would love to see it changed from:

"Set" target <- source


"Copy" source -> target

just as:

"Move" source -> target



Yup, I get confused by that too. I always have to stop and think.



I think everyone has that confusion, I know I do too. I like 'copy' instead of 'set'!

1 Like