I tried to use the "node-red-contrib-ctrlx-automation" nodes to setup a connection between node-red dashboard and the Datalayer.
It works Flawlessly in the CtrlX-core using localhost as IP:
I have some problem when i try to do the same thing using node-red in another device (external to ctrlx)
Is there something i am missing? Do i have to set some permissions in the CtrlX side?
Solved! Go to Solution.
The CtrlX ip address is the default one : 192.168.1.1.
The user is the default "boschrexroth" which is the one working in localhost
Node-red is able to ping 192.168.1.1
Edit: the node-version is 1.2.1
Edit2: I was able to request a token and use plain rest api from node-red, without using the official nodes set. Thus the problem is inside the
node-red nodes or i have done some wrong configuration.
Do you have the possibility to look into the log files of Node-RED? Maybe we can find additional hints there.
Depending on where you installed (linux, node-red) this might look different. E.g. on raspberry pi you can enter 'node-red-log'.
On linux you can also show the log by entering
sudo journalctl -f -u nodered -o cat
EDIT: It might also be interesting to know which nodejs version is installed on your system. Use 'node --version" for this.
I have done the following tries:
-standard node-red snap node-red 1.1.3, nodejs? something like 10, easily repeatable.
-my node-red snap: node-red 1.2.9, nodejs 10.22 (version catched while compiling)
-windows node-red 1.2.9 node-js 14
The windows node-red starded working after a reboot. so i decided to investigate. moving from
nodejs 10 to 14.15.4 in my snap solved the problem!
Here my snapcraft.yaml in case someone has same problem.
sudo snap node-red logs:
I am attaching also windows log in new2.txt and as screenshoot
Thanks for the investigations and the detailed info. 👍
Will add a note to the readme, that at least nodejs 12.x is needed. This is also recommended by node-RED (https://nodered.org/docs/faq/node-versions).
In these days i am testing The node-red nodes because i am going to use them for a production demo with a customer.
The nodes works flawlessly and they are also working after several uptime hours, great job! 🚀
The only problem is that sometimes the Node-Red snap is booting just before the Datalayer is ready and the nodes have difficulty to autenticate (i'm attaching a video and a picture). This happens with Node-red installed inside the CtrlX core and the behavior is happening 1 time over 5 reboots.
is it possibe to add a node to trigger an autentication?
is it possible to add a node to get the authentication state? E.g that sends true if the system is authenticated or not?
This could be helpful also to manage the connection il the Node-red snap is not installed insidethe device.
Really thanks for your time 😊
I agree with @Mauro, it could be useful to be able to perform authentication on demand.
I looked in the code but I haven't touched it, I would like to know your opinion so I write an issue on GitHub:
btw: I really like the node it will be a very good tool for our customer, thanks!
thanks for the feedback.
Regarding the authentication:
good to know that the node will be robust and will keep on trying to reconnect.
I was thinking more to allow authentication without using the node-red frontend (the config part of the node). How about giving the credentials through a message? I wrote an example and a more detailed description on GitHub.
Thx a lot for node-red-contrib-ctrlx-automation Node-RED nodes.
I develop currently on ctrlX core a monitoring app (using node-red) for DC drives on a customer machine. The architecture is so that the ctrlX core is added to the machine config within its subnet and it reads DL data from drives (e.g. data available via Drive Connect App) and writes them on a db reachable via second eth in IT/office network. We know that there is a Device Bridge or IoT Gateway (not on ctrlX) or we can develop e.g., python app (probably we also do so) in a form of a snap but for now we wanted to do this using node-red and already existing solutions which can be also shown to the customer and potentially developed by him internally.
I have 2 topics that maybe you would like to address with the next releases (I use currently version: 1.8.19) of the nodes:
1) Do you think that this would be a potential benefit if for the DL subscribe node we would have the property "path" as optional input e.g. msg.path (used to set the path to the Data Layer node which shall be subscribed to.) In a form of an array probably?
Currently I would be happy to use it cause in my projects now I do SSE calls to REST/API interface from node-red where I have a full control what and when is subscribed. I had to ditch the subscribe node when I started to have error described in issue 2
Using the DL subscription node I have to (but I would prefer not) to hard code the DL path in the node-configuration via node-red GUI. I would prefer to send it with some payload and be able to catch potential problems afterwards.
BTW: I understand that one DL subscribe node on development dashboard of node-red makes one SSE call to the ctrlX DL with a specific keepalive and subscriptions’ times. But at least sending different path (e.g. as array of DL paths) in msg.path to subscribe node would be cool.
2) It happens that when the machine which includes the drives is down/restarted - the corresponding DL paths are not existing anymore (or the DL paths were deleted automatically or due app failure) and ctrlX is still online we got error on the DL subscription node. It is OK I can catch it and at least I am aware. Do you think that adding also e.g. msg.restart = true/false or msg.start =true/false msg.stop =true/false as input options would be a benefit in this case (especially having msg.path from issue 1 implemented) ?
In general: I want to subscribe to DL but only after some preparation of the ctrlX DL for this operation - e.g. drives are up, everything is checked and ready to start subscription.
All the best,