Removed my prior post due to insanity (apologies)... here is the JSON array that @harold.min is talking about and is probably the best answer:
var retMsg = {
"payload": [
"somedata",
{ "value": "somedata" }
]
}
return retMsg;
The "jaggedness" kind of weirds me out a little but it works fine.
Yuck, I don't like that at all. I hate root values + arrays in the same object.
BUT, it will work / is technically correct (I think... lol...).
I would have just made two objects in the payload array. But 2 messages works too!
Too many options.
It does - just tested. I like this one a little better..
var retMsg = [
{
"payload": "somedata"
},
{
"payload": {"value": "somedata"}
}
]
In a completely different direction for @mike ...
Since I have a Zooz relay for my garage, I just used their awesome HE app and added that virtual device to maker... I believe you could use this one for other setups.
Hey. How do we do a node-RED configuration for Hubitat if we are hosting node-RED on an oracle server, and not locally?
I think this is the root of all my issues trying to get it to work.
Thanks @erktrek, @harold.min, @JasonJoel
I now realise that what I was trying to do was dumb, and just bit the bullet and changed all my node rules to msg.payload, rather than having some with msg.payload.value It only took 5 minutes, rather than the inordinate amount of time I spend attempting to complicate things with arrays and objects and incompatible data types. Thanks for all the help. It did improve my understanding of Javascript.
Any reason why you're hosting it in the cloud? I mean... one of the big benefits of using Hubitat is keeping as much as you can local.
If possible, I'd just bite the bullet, get a Raspberry Pi and throw NR on it.
Nah, not dumb at all. Just different than typical. There are lots of ways to do everything in computer-land.
Yeah but the atypical or clever stuff really bites you in the a** a few months or years down the line when you have to revisit it and can't remember why you took that approach.. Of course that's usually true with most of my prior code sadly... 
Months or years? I’m lucky if I can manage days and hours.
I’m pretty good with minutes though. 
That looks like something I would like to try!
Which Google Home plugin are you using?
And how would I go about re-creating this?
I have a list of timestamps as part of an object in the msg.payload
This is a shortened list:
How would I go about comparing all the msg.payload.heapsOfNamesHere in 1 go, rather than manually entering each msg.payload.Mike's Computer and msg.payload.Temp Ensuite. etc.... I want to compare to a timestamp of now, for reference.
Also, possibly related question (in my googling for answers above). What is this called: msg.payload[0] and msg.payload[1].....I dont know what it is, so cant google it.
JSONATA perhaps? $each?
Here's a simple example you can adapt..
$each(payload, function($v, $k) {$k & ": " & $v})
I have run into a minor challenge that I am hoping someone can suggest a simple solution for. I have already started thinking about a complex solution inside NR, but am hoping I am missing something obvious that will simplify my approach.
Background
I have a virtual RGBW Light in Hubitat. Sometimes I want to change the brightness of the bulb from Hubitat. Sometimes I want to change the color of the bulb from Hubitat. I have a configured and well functioning hubitat to NR connection.
Control of the Brightness is via the Level state. Sure enough when I change the setting in Hubitat I get an output like this in NR:
Control of the color can be done in 2 ways in Hubitat (for the Virtual RGBW Light). Either Hue, Saturation, and Level (HSL) can be altered individually. Alternatively, there is a color picker. I am only concerned here about the color picker method.
When the color picker is used it sends NR 1-3 separate inputs. 1 each for Hue, Saturation, and Level (but only for the attribute that changed, though from the color picker, it is almost always either Hue only or Saturation and Level or all 3). From the NR side, it basically looks like 1-3 separate inputs that come in a random order and are indistinguishable from someone sending the inputs individually but really quickly.
For reasons that would be a whole other post, I don't care about the Level input when it is meant as a color change, but I do care about it when it is a Brightness change. I know technically, with a Hue, Saturation and Level triple different Levels are different colors, but for my purposes they aren't.
Challenge
I am trying to figure out how to know that a given level change is a brightness change and not a color change. The best I have been able to come up with is keep track of all 3 HSL inputs. If a L change comes in then hold it for some time say 100ms, then look and see if an H or S change came in within a window of 100ms before the L or 100ms after the L. If so throw it away, else treat it as a Brightness change.
Any suggestions would be welcome.
Side question/request
My initial guess was that it was the Hubitat side driver that sends them individually, but I guess I also want to ask @fblackburn if it is possible for the Hubitat node to output a single HSL attribute any time more than 1 changes, send a brightness attribute when only the Level changes and continue to send the individual attributes as is? I suspect this is a little to corner case to justify monkeying with the code, but thought I would ask since otherwise I am building some timing based work around.
You could try a join node. I think there is an option to set a time out and the number of messages to receive. (Create a single message from separate streams of messages : Node-RED)
Another thought is testing for level change and storing the HSL values in a flow variable. The next level event test for a difference in H & S values if they are the same as previously stored then you know it's "brightness" uh, "lightness" changed. 
Because why not? @tmichael - Here is a very crude example of what I was thinking... hopefully I was understanding what you were going for..
The switch "property" is a JSONATA expression that evaluates to true or false...
($flowContext("hue") = payload.hue.value)
and ($flowContext("saturation") = payload.saturation.value)
and ($flowContext("level") != payload.level.value)
and ($flowContext("colorMode") = payload.colorMode.value)
It may still be a little buggy but you get the idea. My "Office Left Table Light" is a Sengled Color+ bulb using the Zigbee Advanced drivers. Also the 2 HE device nodes have the "all" attribute set and "send events" turned off.
The idea is to test for Level changes but everything else being the same. Also had to add a test for colorMode as switching between RGB and CT leaves the HSL values the same.
edit: might also want to add colorTemperature as a test / flow var too..
Being more a Javascript than JSONATA guy, I was thinking a function node, but otherwise this lines up with my thinking. The challenge is that sometimes a color change will come in as a Level change followed by a Hue change followed by a Saturation change. Without a delay built into the process, the level change will look like a brightness change if the evaluation happens before the hue or saturation change can update the flow variables.
Download the Hubitat app
