Pulling apart message arrays

General
1

Ok, I'm stuck.

Messing around with a message which looks like:
n,r,g,b
(String but the values are numbers)

n ranges from 0 to 7.
the others from 0 to 256.
(Guess what I am doing - rhetorical)

Because I am curious I want to mix and match the messages.

So though #0 is usually on I want to blink it on/off.
But that is difficult because I can't control message timing.

The idea is to store them as flow variables (or context, I guess) and when a message arrives the values are stored.
When another message arrives, the new values are added to the values.

Another part (so I guess the do need to be flow) these values are read in and sent out to the LEDs.

Part of the problem is how to merge them so I can both turn things on and off with ease.
(I'm thinking XOR now)
But the other part is how to pull apart the messages and store them.

I get that the first one is the index but then I am stuck.

Basically this is the idea:
I send 0,0,128,0
LED 0 turns on GREEN.
I send 0,0,128,0 and LED 0 turns OFF. (Given no other signals in the mean time.)

That's nice all things being as they are, but it is difficult to also have a "TURN ALL LEDS OFF" function in there too..... Ok. Just realised: Set the values directly and not via the XOR.

But, back to the problem:
How do I handle the message to set the flow values?

2

Are you generating this n,r,g,b message? Is that a string like it appears to be ? If so, why not generate and send an actual object with all the properties already separated out? That way there is no real requirement to "pull them apart"

This is a bit unclear? I'm sure you know a change node or function node can store values in context / flow. What is you real issue?

As I'm not inside your head and don't fully understand your requirements, I can only offer advice & that advice would be, generate objects that are relevant to your requirements and if you need to store values , then store the whole object and retrieve it as a while object.

3

Well, because - say I want LED 0 to be green.
That is 0,0,255,0 Full green.

How else would I go about doing that?

In the debug node it shows up as "0,0,255,0"

That is done on/in another flow - else where.
Rather than have global names.

So I am trying to confine the names to flow.

I need to send the values to the flow which handles the LEDs.
As n,r,g,b seems to be how the message is sent to the LEDs, why not use that method/structure?

(Sorry. Brain's a bit awash with other things as well.)

So the message arrives with the n,r,g,b and I want to pull it apart to save the RGB values for each LED.

I don't think I could merge the totalistic (yeah...) thing where I merge the entire message.
the first value is the LED, so it has to remain unique.

So I save the 8 RGB values as flow then in another part of the flow I read them in and send them to the LEDs.

4

I literally have no idea what you're saying apart from ...

So my suggestion was why pull it apart if you're generating the msg yourself. You already know you can pass more than just msg.payload so why not send the payload string AND the component parts as msg.r and msg.g etc. Then from the very origin, they are already split up? Or am I missing something?

5

No you aren't missing something.

I just hadn't thought of

Just didn't occur to me.

1 Like
6

Hope I helped in some way. Good luck.

7

Me too. :slight_smile:

8

Perhaps you like to split the string into the components?
There ist a handy javascript method for this array=string.split(',');

var components = msg.payload.split(',');
msg.colors=global.get("colors") || {};
if (components.length>3) {
  var n=Number(components[0]);
  msg.colors[n]={};
  msg.colors[n].r=Number(components[1]);
  msg.colors[n].g=Number(components[2]);
  msg.colors[n].b=Number(components[3]);
}
global.set("colors",msg.colors);
return msg;

image

Here is the output:
image

This should give you an object with all your colors in the global store.
image

9

@Christian-Me sure there are plenty of ways of parsing a string.

I decided to centre my reply from a "take a step back" perspective (i.e. consider your design point of view).

For example, if you are the person generating a msg you can/should consider how it will be used. I.E... instead of sending msg.payload="0,10,20,30" you can just as easily send msg.payload={n:0, r:10, g:20, b:30}" then all this string splitting becomes completely unnecessary.

That said, if the msg is being generated by something out of your control & you have no means of formatting the src msg, your solution is perfectly fine.

10

I totally get your point. But sometimes there is little you can do about in which format you receive your data. For example: I do not agree on the color piker string format, but I see the use of it. Yes I can use the output as object but the fact that it is there says a lot. It is human readable and says everything about the value types and units. But to make it software readable you have to split it apart with a lot of effort.

That`s why I'm working on standardizing all my communication (especially over MQTT). Sometimes a standard is not the best I can imagine but a well documented open standard is better than nothing.

3 Likes