Firmware 1.6.2 – Node-red issues
Home › Forums › Conduit: AEP Model › Firmware 1.6.2 – Node-red issues
- This topic has 7 replies, 4 voices, and was last updated 4 years, 4 months ago by Jeff Hatch.
-
AuthorPosts
-
September 20, 2018 at 5:03 pm #26375Bob DoironParticipant
I just upgraded to firmware 1.6.2 to try it out. I’m seeing two errors that I didn’t experience with 1.4.16:
First these show up periodically in the app/node-red.log:
20 Sep 21:49:46 – [info] [lora in:b7eef807.7c5078] LoRa-IN node reconnect
20 Sep 21:49:46 – [info] [lora in:b7eef807.7c5078] Connected to MQTT for LoRa in node.Second, and more important, the http request node fails often with this error:
payload: ‘Error: getaddrinfo ESRCH : <removed>’,
method: ‘POST’,The 2nd one is a bigger issue because it doesn’t retry, it simply drops that packet.
Any ideas as to what might cause this?
September 21, 2018 at 8:22 am #26379Jeff HatchKeymasterHello Bob,
On the Conduit, can you ping the host that you are trying to connect to with the http request node? Usually the ESRCH tends to indicate a problem with DNS or a proxy being used to forward DNS.
For the LoRa-IN node/MQTT messages this is most likely due to the upgrade of several packages (Mosquitto and libmqtt). I have seen this same kind of reconnect behavior in other (C++) code doing MQTT. Something in libmqtt seems to time out the MQTT connections or something. It appears to me that the “re-connects” don’t seem to be harming anything.
Jeff
September 21, 2018 at 11:16 am #26381Bob DoironParticipantIt works most of the time – it’s an intermittent thing that didn’t seem to exist with 1.4.16.
New problem – downgrading from 1.6.2 back to 1.4.16 seems to prevent all xdots/mdots from being able to join the lora conduit. Seems like this is a one way upgrade and I’m going to have to implement retries to our api in the node-red flow. Nasty.
- This reply was modified 6 years, 2 months ago by Bob Doiron.
September 28, 2018 at 2:37 am #26412MichaelParticipantHi Jeff,
same problem here after upgrading:
28 Sep 09:14:22 – [info] [lora out:xx.xx] Published downstream lora packet
28 Sep 09:14:23 – [info] [lora out:xx.xx] LoRa-OUT node reconnect
28 Sep 09:14:24 – [info] [lora in:xx.xx] LoRa-IN node reconnect
28 Sep 09:14:24 – [info] [lora out:xx.xx] Connected to MQTT for LoRa out node.
28 Sep 09:14:24 – [info] [lora in:xx.xx] Connected to MQTT for LoRa in node.
28 Sep 09:15:11 – [info] [lora out:xx.xx] Published downstream lora packet
28 Sep 09:15:33 – [info] [lora out:xx.xx] Published downstream lora packetthe first downstream packet you can see in the log never reached the connected lora device, it was definitely lost and didn’t appear in the downlink queue, perhaps due to LoRa-OUT node reconnect. that did not happen with former versions.
- This reply was modified 6 years, 2 months ago by Michael.
July 10, 2020 at 2:45 pm #30919William LaingParticipantHi Jeff,
We’re seeing this as well on an MTCDT-LVW2-247A Conduit running 5.1.2:
10 Jul 19:26:59 - [info] [lora in:2c1fb2ef.b2b7be] Connected to MQTT for LoRa in node. 10 Jul 19:27:00 - [info] [lora in:2c1fb2ef.b2b7be] LoRa-IN node reconnect 10 Jul 19:27:01 - [info] [lora in:2c1fb2ef.b2b7be] Connected to MQTT for LoRa in node. 10 Jul 19:27:06 - [info] [lora in:2c1fb2ef.b2b7be] LoRa-IN node reconnect 10 Jul 19:27:06 - [info] [lora in:2c1fb2ef.b2b7be] Connected to MQTT for LoRa in node. 10 Jul 19:27:08 - [info] [lora in:2c1fb2ef.b2b7be] LoRa-IN node reconnect 10 Jul 19:27:08 - [info] [lora in:2c1fb2ef.b2b7be] Connected to MQTT for LoRa in node. 10 Jul 19:27:09 - [info] [lora in:2c1fb2ef.b2b7be] LoRa-IN node
Rebooting the device clears it up. Has any solution/workaround been identified since the last post?
Thanks,
WilliamJuly 20, 2020 at 12:30 pm #30976Jeff HatchKeymasterHello William,
That is interesting. Does it come back after a while when the LoRa node is being used? The last time I looked into this, the libmqtt seemed to be causing the “reconnects”. I have seen the same behavior in C++ code doing MQTT with libmqtt in the past.
Jeff
July 21, 2020 at 11:23 am #30981William LaingParticipantI’m not sure, Jeff. We see it intermittently, so we’ll take notes when we see it again.
We’re not using C++; we use MQTT extensively from Node-RED.
William
- This reply was modified 4 years, 4 months ago by William Laing.
July 21, 2020 at 1:33 pm #30984Jeff HatchKeymasterWilliam,
The Node-RED stuff uses libmqtt “under the hood” to do it’s connections. A bunch of it is not external connections, but brokers on the device locally. Thus my question since I’m trying to figure out where they may be getting generated. Maybe a library or two need upgrading in mPower.
Thanks for helping out!
Jeff
-
AuthorPosts
- You must be logged in to reply to this topic.