Firmware 1.6.2 – Node-red issues

Home Forums Conduit: AEP Model Firmware 1.6.2 – Node-red issues

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #26375
    Bob Doiron
    Participant

    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?

    #26379
    Jeff Hatch
    Keymaster

    Hello 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

    #26381
    Bob Doiron
    Participant

    It 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.
    #26412
    Michael
    Participant

    Hi 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 packet

    the 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.
    #30919
    William Laing
    Participant

    Hi 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,
    William

    #30976
    Jeff Hatch
    Keymaster

    Hello 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

    #30981
    William Laing
    Participant

    I’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.
    #30984
    Jeff Hatch
    Keymaster

    William,

    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

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.