Hello
i set up several flows which have become quite complex and where i invested a lot of time and testing.
This I now have to hand over as hardware together with a documentation.
I wanted to ask you how you document such a thing so that an error analysis or later extension can be done by third party. ( assuming they know what Node Red and JScript is)
I have successfully described the setup of pi and node red, but now I lack the approach how to proceed with the node red flows
Have you read through https://nodered.org/docs/developing-flows/documenting-flows ? If so, are there specific situations that aren't covered there that we could help with?
Don't think I've ever read that page!
Layout section could perhaps mention the use of link nodes to improve complex layouts. Also, I don't think I saw anything about using a node's information tab? Ah, that is right at the end.
Naming section doesn't mention the use of inline /n
to get newlines.
Overall, quite a useful page.
I wonder though if @edstobi isn't looking for a more corporate approach for documentation beyond self-documenting the flow itself? Also documenting the settings.js and other associated files, in particular the package.json.
At the beginning of my Node Red Projekt dokumentation I will describe the additions from the settings and package.
I will describe the function of the flow. I will use a flowchart for this purpose. As an appendix I will add the export of the flow and hope that this is sufficient.
If this is enough for a supplement or error analysis in a few years you have to see
https://nodered.org/docs/developing-flows/documenting-flows helps to understand Node Red, but not the project. But also I haven't read this page before and have read some interesting points and will add it to the project. The grouping of nodes is a good tool for the documentation
One of the things I've started doing with my custom nodes that might also be useful for flows in general is adding test cases. These can be used to show common successful and failing flows by providing standard inputs and testing the output for the expected results.
Possibly most useful for sub-flows? But you could also use to test a tab for example by adding an input and an output link and connecting to those from your test flow.
Groups are really nice for making those tests neat and tidy.
There is also a neat node-red-node-swagger node that helps document any HTTP apis being exposed from the container.
PS. The node is quite outdated and needs some work though
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.