Just looking for people's opinion on best practice for the following situation
I have a hardware device (laser scanner) that only has a c++ interface to interact and control it. The plan would be to create a custom UI to send commands to node-red which would in turn would relay on 'command messages' to this backend application as well as some other hardware devices with similar interfaces as they are all part of a larger system
Some of the tasks the hardware device performs can take a long time to complete but it does send data continuously through callbacks as it scans (complete scan could take a couple of minutes potentially)
I would like to integrate this device into node-red as part of a larger system but I am not sure what's the best architecture
As best I can tell I have the following options
I could use something like MQTT / Sockets to send control and data messages to and from the application that is written in c++ to node red and the UI - ( not sure the best way to launch the backend c++ code from node-red if I went this route)
You could, of course, have a shell executable wrapper and call from the exec node.
Really though, unless you want to be able to connect to your C++ code from other applications or servers, I think that MQTT or websockets would be overkill in this case.
While I've never use the C++ integration with node.js as a programmer (I'm pretty useless at any c/c++/c# stuff), I would think that using that and wrapping your code in a node-red custom node would be the most robust and performant method. But that is based on what you've described here.
Thanks for the feedback. I'm still in two minds on how best to implement. I may have to mock something up and get a better feel on how it works together
It would be a complied application. I can import any lib into the scanner project that is required. the norm would be just to use their SDK which has all the .h and dlls required. Things like MQTT and sockets functionality can be brought in if required.
It has ethernet connectivity
Unfortunately it depends on their own protocol. No Http/rest protocol so I can't control directly in Node-red
Really interested to see how similar hardware with a specific SDK has been integrated into Node-red?
For this particular hardware scanner I wouldn't be able to publish due to commercial constraints it but for more general parts of the project I's have no problems publishing and contributing back to the community.
Thanks. As I am certain you know, node-red thrives due to contributions
As they have their own DLLs/libs (assumption) for talking to the device, it obviously remote controllable.
In this instance I would first ask if they would publish the communication info (sign NDA if necessary). If not, then I would attempt to decode it (wireshark etc). If that fails, I would probably add either MQTT or my own UDP/TCP protocol in a custom app.
PS: I am assuming the application runs on the device? or does your compiled application run on a PC and communicate (over Ethernet?)
Sorry maybe I was unclear. I do have access to the SDK from the vendor but it's a c++ sdk they offer.
What I am trying to figure out in my own head is should I 'wrap' all this custom code with a Node Addon or similar or should I just keep it in a separate application and interface with it from Node-red using something like sockets or MQTT.
I'm leaning more towards keeping it separate and using MQTT as the interface between it and Node-red but really interested to see how other hardware with a specific c++ SDK has been integrated into Node-red
We also had to make this decision with the dali server. Actually, I really like the C++ addon concept of node js but in our case it simply turned out to be simpler to leave it as a separate, standalone component which we just kick in from node-red and communicate with it via localhost tcp. I tend to think that there's no best practice here. Or even if there is, there are different constraints in each case, like e.g. in ours we also had a time pressure So we took the simplest way but it turned out in the end that this was the right choice. It works well, no extra time was lost by wrapping it, etc. I'm not saying here of course that this would be the right choice for you as well.
By the way, if you have time to play around (i.e. no time pressure) with it, just leave it as a separate component and check how it works out. If you see that there's anything that the C++ addon could do better, you can still switch over.
So we took the simplest way but it turned out in the end that this was the right choice. It works well, no extra time was lost by wrapping it, etc. I'm not saying here of course that this would be the right choice for you as well.