accessing nodeRED 'http in' nodes using http (not https)

[Brian Wyld]

Hi,

I’m trying to access a nodeRED flow with an http-in node.
However, given the https certificate is not recognised by my http client (actually, this certificate is pretty annoying in general), I’d like to access my URL using vanilla http.
(note the access is only via an openVPN tunnel and not external, so no security worries here)

I tried disabling the ‘http->https’ remapping in the web admin, but this doesn’t seem to have helped : still got automatic re-direction in the web admin and connection drop in the nodered port 1880 (coz it tries to do SSL on it).

Is it possible to access a nodeRED http-in via an http request? If so, how?

thanks

Brian

[Lawrence Griffiths]

I think you need to edit setting.js and I can’t remember what folder they are in on the AEP and I have hunch they might be overwritten.

[Lawrence Griffiths]

In a non MT node-red installation you would edit settings.js to remove https
/var/config/app/install/development/settings.js

// From MT support
Looks like the /sbin/app.py script is writing the settings.js file.
There appears no place for a user settings.js file to incorporate functionality you are attempting.

So for now looks like you might have to edit /sbin/app.py which in turn will create the settings.js

NB. this won’t withstand a firmware update

[Jeff Hatch]

Brian,

As Lawrence says, on a typical Node-RED installation you would use the settings.js to specify this type of configuration information. There is currently discussion to create a solution to this problem on the Conduit. It is hoped that there will be a solution implemented and released towards the end of Q1 2016. That this happens by that time is dependent on other priorities and project work.

There is a chance that you could create your own file with the necessary configuration, read it in with a file node, and process the data with a function node. Once again, in this case you will need to be aware of the firmware upgrade, and keep the file in /var/config where it will persist.

Jeff

[Brian Wyld]

Hi,

I’m also experiencing a certain amount of ‘instability’ from the nodeRED environment (stops updating the web interface, stops processing inbound messages after a while).

Might be better just having a custom process in java to connect the MQTT queues to my backend….

thanks for the infos

[Jeff Hatch]

Brian,

What type of flow are you running, what nodes? Also, in the upcoming 1.1.x AEP release Node-RED has been upgraded to version 11.1, and node-js to version 10.40 (farthest we could go with the processor). My experience with this upgrade has been a lot more stability and better performance.

Jeff Hatch

[Brian Wyld]

Hi,

less than 20 nodes; basically just a LoRa-in -> https REST API backend and http-in -> LoRa-out pair.

Nothing that should stress it!

My current AEP version is 1.0.33 : when will 1.1.x be available?

thx

[Lawrence Griffiths]

Brian, hum I’m running 50+ nodes same use case as you, to multiple REST end- points and 2 different mqtt brokers along with a lot of Function nodes.

Also I have two custom nodes of my own which are poorly coded. I have 3 mDots sending every min. I do sometimes have to reboot, may be every other week.

>>Might be better just having a custom process in java to connect the MQTT queues to my backend….
You could Bridge the AEP MQTT (mosquitto) broker to yours..

[Brian Wyld]

Hi,

I think I’m going down the ‘bridge mosquitto to my MQ’ route.
I think this means creating a MQTT client on my Conduit, that connects to my central server (handling the inevitable ppp downtimes…) and sends the messages, rather than a multi-mqtt client on the central server that connects to all my Conduits…

I’m thinking of creating this mqtt client in java to be able to run it on the Conduit – any reason not to do this?

cheers
Brian

[Jeff Hatch]

Brian,

How comfortable are you with C++? The AEP Conduit does not have java installed by default.

Jeff Hatch

[Brian Wyld]

Ok… could do C++ but its a pain…

Is there a package containing the utility ‘socat’ for the Conduit?
(coz then I can just bridge the lora UDP packets to/from the lora network server out to my remote cloud…)

Supplementary question : does nodeRED attach to the Lora subsystem by listening on the ‘appPortUp’ and sending to ‘appPortDown’? ie if I bind a UDP listener to appPortUp (1784) will this break the connection to nodeRED?

thx

Brian

[Brian Wyld]

Can’t find a pre-built package with socat (hint hint)…

Using nc works but isn’t very stable (as nc tends to exit if there is any network up/down type activity…) ie:
# nohup nc –udp –listen –local-port 6227 | nc –udp localhost 1786 > /tmp/maas_pkts_down.log 2>&1 &
# nohup nc –udp –listen –local-port 1784 | nc –udp 192.168.5.7 16227 > /tmp/maas_pkts_up.log 2>&1 &

(this listens for downstream packets arriving on 6227 from my server, and sends it upstream packets to 192.168.5.7:16227…)

Anyone got anything better? Any way to configure the lora-network-server to accept/sendto an IP other than 127.0.0.1?

thanks!

Brian

[Brian Wyld]

Just to update this thread with my ‘final’ config.
1/ I gave up on nodeRED, the https issue was too hard and the ‘real-time’ness too little.

2/ To get the upstream lora datagrams, I listen on my remote machine (via a openVPN tunnel) for UDP on a specific port (192.168.5.7, port 16000 in this example) and run nc on the MTCT:
# nc -u -n -p 1784 -L 192.168.5.7:16000 &
[actually I incorporated a startup script into the /etc/init.d/lora-network-server start/stop script to make it come up automatically!]

3/ To send downstream datagrams, I enabled the lora-network-server listening on all IPs (add attribute”allowPublic”: true to object “udp” in the lora-network-server.conf), and then send UDP packets to the port 1786.

The UDP packets rx/tx are a very useable ascii format (MQTT?) as described in the getting started docs.

A+

[Author]

Posts