What is that eth-ip node, node-red-contrib-something possibly.
On the post flow issue, did you try posting the data that you got when you did a GET of the same tab id?
What is that eth-ip node, node-red-contrib-something possibly.
On the post flow issue, did you try posting the data that you got when you did a GET of the same tab id?
Yes.
I posted the exact data I received from the GET and it still failed. If it failed, I received an error message in the response from NR ("can't post flow", "missing nodes property," etc.). Most of the time it would respond with the node id as expected. Knolleary didnāt point anything out I was doing wrong (I posted the commands I tried) so I'm guessing at least one of my commands was correct. All I can figure is I'm not being clear on what I'm trying to do and everyone thinks I'm trying to do something similar but different and NR isn't actually capable of doing what I'm trying to have it do. I can deploy an entire flow just fine, but I want to re-deploy just a single tab and leave the others alone.
Environment variables are a better approach anyways, but that might not be possible either with ST-One's nodes.
You all ready read some on my repository. Can we continue some with getting from you some feedback?
Or you have solution and Ciach DONE?
I provided feedback in comment 17. I've visited your repo several times and was royally confused. I think you did a great job on putting together your collection of programs that works well for your needs. You told me odtm-tools would do exactly what I couldn't figure out how to install just that component. It looked like I needed to install a bunch of other things on the Pis and an Android device.
Run the get and feed it into a debug node. Then in that debug node use the Copy Value button to copy it, and paste the into a debug node set to be configured with JSON. That will give you a debug node with what should be valid data. Then feed that into your flow that does the PUT. If that doesn't work, then export those nodes and paste them here so we can try it.
in the curl command that you shared in post 33
you have the parameter --request POST
and then -X PUT
i dont know what takes precedence with curl but
for updating a flow its a PUT method so remove --request POST
I tested the command on a virtual test machine and it works fine.
If the id of the flow you want to update is f72d85c5e090800f
try the simplest test
(an inject and debug node)
curl --location --request PUT 'http://192.168.0.10:1880/flow/f72d85c5e090800f' \
--header 'Content-Type: application/json' \
--data '{
"id": "f72d85c5e090800f",
"label": "TEST 1",
"nodes": [
{
"id": "abbed8844a2db61",
"type": "inject",
"z": "b6fc9dc98a231f5a",
"name": "test1",
"props": [
{
"p": "payload"
},
{
"p": "topic",
"vt": "str"
}
],
"repeat": "",
"crontab": "",
"once": false,
"onceDelay": 0.1,
"topic": "",
"payload": "",
"payloadType": "date",
"x": 220,
"y": 120,
"wires": [
[
"d59b1fc7011ef7f3"
]
]
},
{
"id": "d59b1fc7011ef7f3",
"type": "debug",
"z": "b6fc9dc98a231f5a",
"name": "debug 1",
"active": true,
"tosidebar": true,
"console": false,
"tostatus": false,
"complete": "false",
"statusVal": "",
"statusType": "auto",
"x": 430,
"y": 120,
"wires": []
}
],
"configs": []
}'
ps .
add your Authorization headers,
change to your server ip
backup your flows if you have important information.
Even if a flow edit dialog is not developed to support ENV vars, you can simply substitute them in the flow JSON. e.g. support the flow JSON is { "send-payload": true }
you can POST or PUT { "send-payload": ${send_payload_bool_option} }
Did you follow the docs and example for updating a single flow tab?
https://nodered.org/docs/api/admin/methods/put/flow/
What info is missing?
Even if a flow edit dialog is not developed to support ENV vars, you can simply substitute them in the flow JSON. e.g. support the flow JSON is
{ "send-payload": true }
you can POST or PUT{ "send-payload": ${send_payload_bool_option} }
Good to know. I'll have to check that out. Thank you!
Thank you!!! So there was, in fact, an error in my command. I see it now.
Even if a flow edit dialog is not developed to support ENV vars, you can simply substitute them in the flow JSON. e.g. support the flow JSON is
{ "send-payload": true }
you can POST or PUT{ "send-payload": ${send_payload_bool_option} }
Thank you. That's good to know. I'll have to look at that.
Did you follow the docs and example for updating a single flow tab?
PUT /flow/:id : Node-RED
What info is missing?
The authentication page gives specific examples using curl for getting an authentication token. Each page under methods tells you the basic arguments NR is looking for but provides no examples.
So can you not extrapolate the CURL command for a PUT
? All of the info is there, you just need to put it together. There are thousands of examples around the internet.
e.g.
curl -H 'Content-Type: application/json' -H 'Accept: application/json' -H "Authorization: Bearer <ACCESS_TOKEN>" -X PUT -d '<JSON_FLOW>' http://<IP_HERE>/flow/<FLOW_ID_HERE>
@ChZeman thanks for the feedback. Adding more working examples to the api docs will be useful.
@Steve-Mcl
Between a problem that knolleary noticed with my json (which I SHOULD have noticed comparing to the docs) and UnborN supplying a curl example (spotting a problem with the curl commands I had put together), the problem is now solved.
I had attempted many times and posted what I tried. I also found countless posts on the internet from others having the same problem I was but they weren't able to come up with a solution either. When you have that many people struggling with the same thing, it means something needs to be added to the documentation. I'm not saying the documentation is horrible by any means. I've found it helpful in many cases. It just needs working examples to help people understand certain concepts they don't yet understand.
The great thing about IT is that it's an ocean of various technologies that can work together. The bad thing about IT is that none of us will ever grasp all of it and struggling to put things together can be discouraging and a turn-off that steers people a different direction.
I appreciate that - not everyone can know everything. But also appreciate, every single scenario cannot be documented either. (I get lost off when there is too much info and it risks going stale / maintenance headache) but examples would be a nice addition.
If you can, a PR to the docs with 1 or 2 working examples would be a great .
Oh exactly. I do a lot of reading of support posts both here and other sites and see so many cases where the developer responds to support requests with "It's in the docs." Sometimes it is. Sometimes it isn't. "Just read the docs" has become a pet peeve of mine.
That said, I realize there are many people who simply don't read the documentation. I'd rather read the docs and come up with an answer because it'll more often than not be completed faster than receiving a response. Clear, concise documentation is paramount in my line of work. It's not always perfect, but we work to improve it as scenarios come up. The other side of that is the documentation can be there but the operator might need to be walked through a couple times because the equipment and situations CAN be intimidating until you get used to it.
PRs are something I've never done before but I'll look at that. I've seen them talked about. I might know more about them than I realize but I won't know until I check it out. Thanks!
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.