I have a Python socket stream monitor application (socket.AF_INET, socket.SOCK_STREAM) I wrote to monitor a custom protocol on a remote server.
Is there a way to connect this stream to a NodeRed node?
Have you tried the TCP-In node?
yes, not suitable. Thanks.
If your python app is already monitoring it then you need to forward on the data in some way. Several ways eg via stdout to exec or daemon node , MQTT to a broker , or maybe another tcp stream
1 Like
Yes, the app is already monitoring. I need to setup a sort of "channel" with a node. No idea yet. I thought about a websocket, but not sure if it is the best option.
I had a look at the node-red-contrib-daemon, and it looks interesting. But also your idea to publish output messages to mosquitto and then gather them with an mqtt-in node is interesting too. I need to test both and verify speed and stability.
I have many python scripts running outside of NR and communicating via MQTT. It is so good, I doubt you would wish for more. In my case several of those are publishing video frames and the performance is hard to beat, I have no idea what other method would be faster
To make it happen you could simply import the paho library. What you also should think about in design is to implement features that allows you to have control over the script execution from NR; is it running, to terminate it correctly (important if you use threads), handle automatic script restarts, eventual check that an older instance will be killed automatically if you start a new etc etc. If you are familiar with python, this is the way I would recommend to go, done it myself so many times, working so well
2 Likes
@krambriw thank you very much. I agree with you, but as I am not using mosquitto in this project, I would not like to add more complexity/point-of-failure so I am a quite undecided. I will first test node-red-contrib-daemon and then maybe then divert to MQTT is not good.
Hi @fmarzocca, are you avoiding MQTT as you are unfamiliar with it?
You say you don't want to add complexity yet you ask about connecting streams to sockets & piping stdout. Talk about complexity!
I personally believe that using MQTT will actually simplify things for you.
Not only will you be able to inspect data (at runtime) from amazing tools like MQTT explorer, but you begin to realise other applications can also consume those values, at the same time & gone are the days you split buffers and strings to get your sent data into usable variables & many more possibilities unfold because you used the pub/sub/broker architecture.
Once you start using MQTT and structured data (e.g. JSON) in your transmissions, you will not want to go back to handling socket disconnections and string splitting and plucking values from custom byte streams ever again.
Do you have a simple python test server that we could use to look at the data flow? There are bound to be ways to do this.
I fully respect your decision, it's anyway your design and your responsibility to make it work reliable. If you have a customer for this project, he will keep you noticed in case needed. I will not add any more comments about the benefits using MQTT, I think enough is already said about that. What I just would like to contribute with is a flow part I use, as a "design pattern", to control python scripts from NR
At flow startup the python script is started. I decided to make it visible on the display but that is of course just my choice. All communication with the script is then via MQTT. The script receives heartbeat signals regularely and if the response should be delayed more than the defined trigger time, in this case 5 min, the script will be restarted and an information message is sent via Telegram. To terminate the script, a command is sent to it and to be sure it is really terminated, an additional pkill command is sent some seconds later. So far this pattern has worked very well, it is kind of self-repairing, just set & forget, get informed if and when it eventually had to restart
Yes, I decided to go with mosquitto! The daemon node is not suitable to my needs.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
