How to inject a buffer?

General
1

Hi, I've the I2C node outputting a buffer:

payload: buffer[2]
0: 0x40
1: 0x0
topic: ""
address: 32
command: 255

I need to simulate it from inject, I choose "msg.payload" and buffer, then I type [0x40,0], but doesn't work, I tried also 0x40,0, ([0x40,0]),(["0x40","0"]), but I get always errors. I've tried to figure out reading around but no info on syntax. Thank you.
PS: would be lovely to include in the brief guide of node, on the sidebar, a quick example for each format

2

["0x40","0x00"]

1 Like
3

JSON (which is what is entered into the inject node) does not support hex or octal. JSON5 will, but I assume node red is not (yet?) using that. You will have to enter it in decimal [64,1]

4

Oh, I didn't know that. I live and learn. For a while longer at least :slight_smile:

2 Likes
5

Thank you, that's the only one I haven't tried :sweat_smile:

Looking forward for the time NR introduce the chance to change inject without deploy the node :slight_smile:
I mean not the type, but values yes, really helpful. My flow is really huge and it takes always 3/4 second to deploy it..

6

If you select Modified Nodes in the Deploy button drop down then if you edit the Inject node only, then only that node will get re-deployed.

1 Like
7

While editing the inject node - you can use the "inject now" button image
to test your input before you finish editing.
(As part of Node-RED 2.x)

1 Like
8

What deploy type do you do? Full, flow or node?

9

thank you, really useful answers! I got now on partial Deploy, which speeds up dubug process (before I was just deploy, as I always did, poor servers that had to re register my nodes again and again), and about NR 2! I've read you introduced lot of staff, but I'll wait for next time to install a version that have been super-tested )

About that I have an important suggestions, which is about debug problems, I thin it's really useful:

  1. On an error message (from function for example), to put more evidence to which function generated it. Now you just slighly border the function, which result invisible on a fully zoomed out flow. My flow is really big and when it happened, I just couldn't find it (was not an hidden module). Suggest to change its color fully, maybe flashing it.
  2. When a debug is outputting a message, it's also very useful to understand who generated it. If a message contain an error, that made the function stop, we haven't details (such as message object) to understand where it come from, for example: something like "can't read property topic of undefined", if I remember right it comes to debug because it's linked to the function, if you click on it the debug node flashesh.. not the function which generated it.
    Thank you
10

Maybe it would be a good idea to split up the tab into multiple tabs. I try to make sure that a flow fits onto a single screen without zooming (or nearly fits at least).

Set the debug node to Output Complete Message and you can see the full message object.

Once you see which debug node it is, then you just have to follow the wire back to see the function.

11

Hi, sorry but your suggestions sounds all not practicable for me

  • I need all in a flow, to avoid adding extra nodes to link on different flows, for me is comfortable like that. Anyway I have so many nodes that I would need at least 20 different flows, and browse between tabs to find them sounds bad for me, sorry
  • You didn't catch me, I'm not telling you I can't see full message, I'm telling debug node doesn't tell me from which function is coming from that message. You are suggesting me to add debug node as many as functions I need to debug. Yes it can be a way, just sounds a bit weird. Usually when I debug I put a debug node close, then I link on it all nodes I need to monitor, nad not an each debug node for each link..
    I hope I expleined myself correctly )
12

The correct way to see where a msg came from is to have only ONE wire into a debug. That way, there is zero doubt where it came from.

Alternatively, in each function, add something into the msg to identify it.

Do you know the link nodes have a clickable hyperlink that jumps you to the relevant tab?

13

Why do you want to avoid links?

It is very unusual for a flow not to naturally break up into blocks fulfilling specific purposes. Inputs, Outputs, Logic for each section of the requirement, and so on. For example one of mine has tabs labelled Temperatures, Controls, Schedule, Conservatory, Kitchen and so on.

The central server controlling my home has 35. It is not a problem. The i tab shows them all as a list and you can jump to any of them by hovering and clicking the search button that pops up.

Yes, generally one is only debugging one function at a time. When you have more than one Debug node on the flow at a time make sure you give them names so the output is easily identifiable.

14

Mates, I'm not arguing with you about something, thank you for your kind explanations :slight_smile: for sure I'm not using it in the proper way. I've just thought it was useful to see in the debug node where the message come from, maybe not complicated to implement, useful.

By the way, I think you agree about the general function error (not coming from debug node), kindly to make it more evident the flashing, to find it when zoom is out. Thank you

15

Actually very complicated to implement as the input event only has the knowledge of the msg contents, and the knowledge of what is wired to what is only held by the preceeding node. The simplest way is as Colin suggests to add another property to the messages so you can tell them apart, or use separate debug nodes.

useful thought - noted.

1 Like
16

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.