I setup Node-red on a computer, maker API with some virtual devices, etc. It works but I miss something probably ridiculous...
I can inject numeric values (inject node) and the result is ok on my dashboard/device
I harvested some data from my modbus PLC (ok, I obtain the values - debug mode) and I want to inject them into HE. That's my problem. I obtain only msg.payload[X] where X is the payload position of my modbus area.
I probably forgot something about values, messages, conversion... where is my error ?
I'm not completely sure, but it looks like the Arguments field in the Command Node might only accept values, not JSONata, so I'd suggest adding a Change Node before the command node, and setting msg.arguments to msg.payload[58], then remove the arguments from within the Command Node.
As you can see, the result of my modbus poll is a number (967 Watts, a number, taken from an array), I did convert it from the beginning, and removing the argument has no consequences.
People get tired of my saying this, but READ THE ONLINE NODE HELP (caps for emphasis, not anger). It says exactly what are allowable inputs - there is no need to guess.
All that said, I just submitted an issue/request to consider renaming the input help to say "msg.arguments" instead of just "arguments" to remove ambiguity.
Yeah I figured and read there are ways to import useful nodes but didnt work out how yet. Just playing with the basics after watching all the standard videos. This is like my early Stringify days so it's a very, very welcome approach to creating rules. I should have jumped in earlier but stuck with RM until I really knew it and now feel it's time to get into this! It looks amazing I have to say. Very cool indeed.
Additionally, I created a Node-Red RaspberryPi image and there's an explanation on how the image was built, including how a dozen nodes were installed via the command line.
I also submitted a pull request for this change for the 4 nodes that have configurable input message parameters. Assuming I did it right (lol - I've screwed up easier PRs before...) maybe it will get merged for next release.
Note that with multiple motion triggers it can be tricky, depending on how the sensors react to continuous motion. If some stay "active" the whole time motion is present, and others don't, then you will need more logic to check if any=active before triggering the delayed off.
As yours appear to all be the same type (Xiaomi) you might not have to worry about that.
If you did, you would just daisy chain the motion sensors in the "off" path (making sure to DEselect send events in the node config) like this - basically the msg would never reach the stoptimer node if all nodes aren't = "inactive":
Some would say "that's a lot of nodes for something simple". My counter to that is I would rather explicitly see the msg flow than to bury the logic in a function node that makes the flow sheet "prettier" but hides the logic/flow control.
While I could easily do it this way, I don't find this useful in the long run:
I guess you could also take advantage of HE's Zone Motion Controller app to combine sensors.. and just expose the resulting virtual sensor to the maker api.
I fully agree. My mistake was probably due that I previously used that kind of parameters with Hubitat MQTT app that asked for text instead of numbers. I had to extract data from the area and submit each of them to MQTT. Now I have the full area again (debug) but the result is as expected.
To be honest I don't know what you talk about (hubconnect nodejs server) (and didn't search neither ) But if this feature is required by some of you, then I can think about it how to integrate it. (I will try to read about it, let's hope for some rain this weekend )
Woups I total miss that thing. Yes I don't reuse the port option for the websocket connection URL. I'll fix it in the next release. Thanks
) But if this feature is required by some of you, then I can think about it how to integrate it. (I will try to read about it, let's hope for some rain this weekend 
)
