[Ajay K]

Hi Mike,

I have asked this question before as I started this particular issue thread. I was wondering if this is an issue with MDot as well as we use the MDot and we have seen this reproduce in the field although very sporadically. Do you suppose we have an MBED ticker issue here as well?

Thanks,
Ajay

[Ajay K]

Thanks a Lawrence your earlier response. I still don’t understand how you would find out when to send, when one of the nodes is not able to communicate with the conduit, since in class A you can’t even send a packet to the mdot, without mdot successfully uplinking packet. Can MAC commands be sent without such restrictions.

In my case most of the nodes seem to be falling under the second scenario you have mentioned i.e.

Also we have a situation where RF environment changes and has caused well performing nodes to fall off net occasionally coming back online. ADR needs to at least 20 packets to access a change in DR. So when we see a nodes who RSSI has a big delta we want to take action then.

What did you mean by “when we see a nodes whose RSSI has a big delta”?

Thanks,
Ajay

[Ajay K]

Hi Lawrence,

I get the part of the lowering the data rate, but how do you figure out which node you need to target from node-red? Are you parsing the lora uplink packets to see what data rate it is operating at and deciding based on that?

Thanks,
Ajay

[Ajay K]

Hi Ben,

Are you trying to connect to the MQTT broker via node-red workflows or are your writing a custom application to connect to the broker? I am not sure about if there were any restrictions on 1.3.2 of AEP, but I currently connect to the mqtt broker both via node-red and a custom nodejs app.

Here is the configured MQTT input node in node-red flow that subscribes to the topic for nodes joining the lora network.

[{"id":"6055ed4f.b43264","type":"mqtt-broker","broker":"localhost","port":"1883","clientid":""},{"id":"75f5e3e1.22c47c","type":"mqtt in","name":"Look for Nodes Joining LORA Network","topic":"lora/+/joined","broker":"6055ed4f.b43264","x":189,"y":110,"z":"b70e5bb9.38ab48","wires":[["6e3f40c.a7bafc"]]}]

Thanks,
Ajay.

[Ajay K]

So I seemed to have managed to reset it to defaults, however I get the following error below and can’t seem to connect to the 192.168.2.1 ip and i am guessing it is because of the error below.

udhcpc (v1.22.1) started
Setting IP address 0.0.0.0 on eth0
Sending discover…
Sending discover…
Sending discover…
Usage: /etc/udhcpc.d/lanup {bound|renew|deconfig}
run-parts: /etc/udhcpc.d/lanup exited with code 1
No lease, failing

Thanks,
Ajay

[Ajay K]

Hi Jeff,

I seemed to have run into something similar. Is there a way to reset to factory settings from the putty command prompt? I pressed the reset button for over 20 seconds and everything is as is. I am logged in via the putty command prompt via the debug port and my updated admin password is still intact inspite of doing a reset as mentioned above and I am on 1.4.1 firmware version.

Thanks,
Ajay

[Ajay K]

Hi Alexis,

Are you using Class A/Class C mode while transmitting data between the MDot and conduit. Because in Class A if you send a packet from the MDot to the conduit and the conduit needs to have already queued a packet in response even before the MDot packet made it to the conduit.

So what I am trying to say is if the response to the mdot packet is generated after it was received by the conduit, you will receive an empty packet if nothing was queued previously on the lora downlink queue for that mdot. So when you transmit the next packet from the mdot, the conduit will send a packet that you last queued. Hope that makes sense?

Thanks,
Ajay

[Ajay K]

Multitech team can you comment on what Mark has called out, is this something that could be an issue on the MDot as well. Especially the ticker problem that has been described in one of Mark’s earlier posts.

Don’t use deep sleep in combination with ADR, the xDot forgets about the ADR after it comes back from deep sleep.

This one worries me and again all though I am on the mdot, I am hoping the same issue isn’t occurring there, as we do use the deep sleep and the ADR.

Thanks,
Ajay.

[Ajay K]

You should be able to use the MQTT o/p Node. Import the below node-red script into using the node-red menu option, Import->clipboard.

You should be able to look at the info tab how best to use the node. Currently I have set the msg topic to be “lora/<DEV-EUI>/clear” in the code below, however you will need to modify the EUI of the end node before running this node. I usually change the msg.topic property via a function node, based on which nodes needs to be cleared or if I need to publish downlink data.

[{"id":"6055ed4f.b43264","type":"mqtt-broker","broker":"localhost","port":"1883","clientid":""},{"id":"6ae772a3.88a52c","type":"mqtt out","name":"MQTT Clear Node","topic":"lora/<DEV-EUI>/clear","qos":"","retain":"","broker":"6055ed4f.b43264","x":174.28571319580078,"y":224.28572463989258,"z":"513a453e.d720dc","wires":[]}]

Thanks,
Ajay

[Ajay K]

Hi Peter,

I have not been able to get this to work. What should I choose for the settings for the LAN setup when I create a bridge of the two network connections. No matter what I tried, the conduit settings for LAN and WAN it seems like the conduit is not connected to the internet. In my last attempt, I can’t seem to login to via the admin screen either now. I am only able to SSH via the USB cable in the back panel.

Thanks,
Ajay

[Ajay K]

Any thoughts on this issue?

[Ajay K]

Hi Alexis,

I am assuming you want to clear the queue for a particular node in the conduit.

You could use the MQTT node in node-red to send a “clear” topic message as mentioned below.

Clear queue – clear the downlink queue for a node
lora/<DEV-EUI>/clear

The various MQTT messages supported are described in this URL.

MQTT Messages

Thanks,
Ajay

[Ajay K]

Hi Lawrence,

I had asked a similar question a while back, look at Mike Fiore’s response to figure out if ADR is enabled or not correctly and can be found at the very bottom of the forum thread.

Enabling ADR on the mdot and conduit issue!

Thanks,
Ajay

[Ajay K]

Thanks Mike for taking the time to respond. Just a follow up question regarding the comment mentioned below:

Current firmware & library implementation doesn’t allow a US dot to operate on AU frequencies or vice versa.

Did you mean we could use the existing production mdot library as is, however if we use an US dot, it would prevent it from operating at the Australian frequencies? Also the Australian frequencies seem to be a subset of the US channel frequencies.

Thanks,
Ajay

[Ajay K]

Any thoughts Multitech team?

Thanks,
Ajay

[Ajay K]

Thanks Mike for getting back to me so soon and asking around the conduit development team. But just was wondering how would that work if only the Mdot plans on supporting this and not the conduit, especially in the ADR Mode?

[Ajay K]

Thanks Mike for your prompt response. Hopefully the gateway if and when they implement a similar feature, has this timeline as well.

Thanks,
Ajay

[Ajay K]

Hi Mike,

Thanks for taking the time to respond. Do you have an idea as to the timeline when this particular version would be available. I understand that this an mDot specific release that supports custom channel plan. However for this to work the Conduit will need to support this as well right?

Thanks,
Ajay

[Ajay K]

Yeah we could check for the existence of the app dir, However I guess i just think we will make do with logging under /var/logs. I am not sure why this occurs, but that was the first things I noticed, the app folder under /var/logs would take a little longer than usual to get created, whenever it failed.

Thanks,
Ajay.

[Ajay K]

Hi Jeff,

Just want to give an update, I think we figured out the root cause. One I had to cap the memory of the application as it was prudent to do so and second the main issue, was that the /var/log/app folder is not created, which is where the custom app used to log. Since the custom app’s priority was modified to be run before the lora-wan-server application and the node-red startup scripts used to be the one that creates this folder I guess. I think based on our tests it seems to be fixed and is not reproducible, after I re-routed the custom app’s logs to /var/logs instead of /var/logs/app. Also this anomaly only occurs during when you power cycle in less than 30 seconds.

Thanks,
Ajay

[Ajay K]

Adding that switch to manage the memory didn’t help either.

Its almost like whenever it fails, one of the things I have noticed is that the /var/log/app folder takes a little while to be created. I am going to try and see if write my log file to a different location does it help.

Thanks,
Ajay

[Ajay K]

I actually saw the run level mentioned in the boot logs and it mentioned Runlevel 5, so the application should technically run.

I also could confirm my startup scripts are being called as I have added log statements using the logger object in my Applications Start Scripts.

Here is one thing I have noticed, when I have the /sbin/angel loading my app, the angel application loads up fine, however the node application or rather my custom app is not run. Could this be an memory issue?

In the node-red startup in app.py i see the following lines, is this setting some kind of memory cap on the node-red app?

/usr/bin/node --max-old-space-size=40 /opt/node-red/red.js

if so, should I be limiting the memory usage on my custom app as well and would the same number applied to node-red suffice for my app as well?

Thanks,
Ajay

[Ajay K]

Hi Jeff,

Where does the start-stop-daemon typically look for the pid file?

Thanks,
Ajay.

[Ajay K]

Hi Dean,

It depends on which settings.js file on the conduit you updated. There is one under /opt/node-red/settings.js. You don’t want to update that one as it gets overwritten during firmware upgrades. The one you want to update is I believe under /var/config/app/current.

Btw why do you want to use the “fs” module, isn’t it available as file in/out nodes on node-red?

Thanks,
Ajay.

[Ajay K]

Hey Jeff,

What happens different when an additional –initd param is passed via the app-manager script?

May 30 17:50:35 mtcdt user.info APPMANAGER: AppCommand::executeStartScript: executing: /var/config/app/TestLoraUplinkPktManager/Start start –initd

as opposed to the one called from starting the app manager via the url.
“/api/customApps/LOCAL/start”

May 30 17:55:33 mtcdt user.info APPMANAGER: AppCommand::executeStartScript: executing: /var/config/app/TestLoraUplinkPktManager/Start start

Thanks,
Ajay

[Ajay K]

Thanks Jeff, I never thought of that possibility. Is there a way to figure out what the run level was, when it was booted up?

Also I have another update, I could reproduce it consistently on the ATT based AEP conduit now. However I removed the /sbin/angel dependency from my startup scripts, I just use the following

My environment variables in my start scripts.

NAME="TestLoraUplinkPktManager"
APP_LOGDIR="/var/log/app"

# Use MultiTech Provided $APP_DIR environment variable
DAEMON="/usr/bin/node"
DAEMON_ARGS="$APP_DIR/app.js > $APP_LOGDIR/$NAME.log 2>&1"

RUN_DIR=$APP_DIR

START_STOP_DAEMON="/usr/sbin/start-stop-daemon"
PID_FILE="/var/run/$NAME.pid"

My start script for my app. Let me know if you see any concerns with the start script.

$START_STOP_DAEMON --start --background --pidfile "$PID_FILE" --make-pidfile --chdir "$RUN_DIR" --startas /bin/bash -- -c "exec $DAEMON $DAEMON_ARGS"

Even though the application hasn’t started the app-manager believes the application has started successfully, even though there is no app running with that PID as stored in the pid file.

Thanks,
Ajay

[Ajay K]

Hi Jeff,

I do provide the PID and status information via status.json. But I don’t think the application didn’t even run to begin with. At the least the <app-name>.log file should have been created as the o/p of the console is piped to a log file and moreover I have Winston logging as well and handle the “ExitOnError” event as well. So as far as I can see the application never runs. Mostly I am worried about the difference in behavior of the exact same application working differently on two different conduits.

Also as an experiment, I removed the /sbin/angel from launching the nodejs app, instead launched it directly using the node application and still fails loading the app, under under 30 seconds power cycle.

If you would rather prefer I rather open a ticket, let me know I can attach the log files for review and the application tar file so the issue can be reproduced?

Thanks,
Ajay

[Ajay K]

Hi Peter,

When attempting to install the paho-mqtt library on the conduit, I just run into dependency issues and every time I resolve one, another one props up. Let me know if you have any luck installing this library?

Thanks,
Ajay

[Ajay K]

I did increase the logging level to Maximum as per your suggestion and most detail seems to be in the messages log file under \var\log\messages. Looking at the failed and success scenarios in the log file doesn’t elicit any new information as to why the custom app doesn’t come up on a quick power cycle and more over the APP-MANAGER indicates success in both scenarios as per the log file.

Should I be looking at any other log files for better information?

Just fyi, I do use the /sbin/angel application to load the nodejs custom app I have built, could this be causing any issues? Although I have renamed it/created a soft link appropriately so that it doesn’t clash with the node-red’s use of the same application.

Are there are any hardware differences between the ATT model and the Verizon conduit AEP models?

Thanks,
Ajay

[Ajay K]

Thanks Jeff will do that and see if I have some better luck wrt to troubleshooting this issue.

Thanks,
Ajay

[Author]

Posts