Issue: The Node-RED Socket-IO (listen) node doesn’t function
Resolution: Set the correct httpRoot
variable and associated nginx proxy configuration
Discussion: Socket-IO is an important technology for time-sensitive I/O without CPU intensive polling. The current Node-RED settings.js hasn’t been correctly informed of the /node-red httpRoot that the nginx proxy enforces.
This has resulted in a more complex nginx configuration to handle the required /node-red/comms Socket-IO path specifically, and blocks other Socket-IO traffic configured using the Node-RED Socket-IO node.
Node-RED not being informed of the correct httpRoot causes other subtle problems such as the inbound HTTP node not displaying the correct httpRoot, but the biggest we’ve found is breaking inbound Socket-IO functionality.
Files to change
/usr/share/nxtio/services/node-red/settings.js line 89:
httpRoot: '/node-red',
Once Node-RED has the correct httpRoot setting, the nginx proxy can be simplified to combine both http and socketio under the same path, while retaining authorization requirements:
Full /etc/nginx/sites-available/http/opto/node-red.nginx.conf file:
location /node-red {
return 301 https://$http_host/node-red/;
}
location /node-red/ {
error_page 400 401 404 = @error401;
auth_request /auth/access/user/confirm;
proxy_pass http://127.0.0.1:1880/node-red/;
# WebSocket connections
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
groovEPIC: This is also an issue with Node-RED on the groovEPIC, but we have been able to get around it using ssh. The ssh license allowed us to debug this issue and provide a resolution on the groovEPIC, but we have no mechanism of resolving this on the groovRIO, so the issue is filed under groovRIO.
Once this is validated by the Opto22 support team, would it be possible to request an OptoSupport RSS on the groovRIO before a patched update is available?