[Ajay K]

I am not sure how the u-boot is done. But the debug port Eric is talking about is the mini usb port at the front panel located where the SD card and SIM card slots are present. You will need a mini-usb cable to connect to the port.

Thanks,
Ajay

[Ajay K]

Hi Jeff,

I use Winston to log to the console and I have redirected the console logs to the /var/log/apps/<app-name>.log in the start up scripts of the custom app. However when the conduit reboots, within a minute or two, I would see the log files, however when the application fails to start, I don’t see any log file even being created and that is one of the reasons I know the app failed to startup when the init.d scripts are executed for custom app. What is weird is boot logs not sure why it assumes that the application was started successfully, when it has not.

I am not sure why time plays any role here, i.e. if the conduit is power cycled within 30 seconds the app doesn’t startup and why doesn’t it reproduce on the other conduit, except on the Verizon specific conduit and also we can reproduce it consistently.

Thanks,
Ajay

[Ajay K]

Hi Jeff,

The application doesn’t access the internet. It connects to a local port by creating a socket connection and also listens for uplink packets by subscribing to the uplink message.

So technically nodejs should handle any failed connections, what I mean by that I have error handling for those scenarios and not sure why when its lesser than 30 seconds that app fails to come up.

Thanks,
Ajay

[Ajay K]

Thanks Peter, I don’t have a linux environment available. However I can try the steps you have mentioned on my windows box and finally run the setup on the paho-mqtt library on the conduit and see if that helps.

Thanks,
Ajay

[Ajay K]

Thanks Jeff for confirming as well. I did find this eclipse’s paho-mqtt library yesterday. But I have no idea as to how to install it in the conduit. Do you have any suggestions as to how best I can install this on the conduit? Unlike node modules, which I could just copy it to the nodes folder under my application this one I am not sure how I could copy this library and install it?

Thanks,
Ajay

[Ajay K]

Thanks Jason for your timely response. What version of python is supported on the conduit? Also like the nodejs mqtt client support, does python have any support for mqtt without me having to import or install any dependencies on the conduit?

Thanks,
Yogesh

[Ajay K]

Thanks a lot Jason, that helps.

[Ajay K]

Thanks Jason, I will review the link you sent. Just curious does python based custom applications have the same amount of latency in terms of startup as the nodejs applications?

Also what is the best way to build c++ applications for the conduit, I mean in terms of compiling etc and also if I want do socket programming what is the best way to do that using the c++? I am new to the whole linux os and since the nodejs had built in objects, the turn around to write a custom application was fast enough, but not sure how I would achieve that with c++ applications?

Thanks,
Ajay

[Ajay K]

Any pointers?

[Ajay K]

Hi Javier,

I am just calling dot->Sleep(nSeconds); I am using the defaults for the rest of the parameters and the default seems like is mdot::RTC_ALARM and so I am not sure if I need to manage the state of the wake pin?

Why would it run thru’ the entire sleep/wake cycle and stall after a long run of sleep/wake cycle and mostly seems to happening since the latest build 2.0.17

Thanks,
Ajay

[Ajay K]

Jason I am confused, is this payload not required by the libmdot? If so any application consuming libmdot to communicate with the conduit, can not ignore this packet with ADR enabled correct? Also like I mentioned previously at the beginning of this thread, the application never received this payload before, even if it did the libmdot may have consumed it and not have handed it over to the custom firmware. It seems to be happening since the latest build 2.0.17 of the libmdot.

Until the explanation above what the payload was, I had no clue what that payload was, so my concern again is that we transmit custom payloads which gives specific configurations/directions to the mdot and I don’t want to handle these payloads that have no meaning to my firmware. But as you suggested I could apply some filter, which I don’t understand how to do that yet? But filtering that payload would it prevent the libmdot from ignoring that payload?

Thanks,
Ajay

[Ajay K]

Thanks Jason for the explanation, however shouldn’t this packet be shielded from the custom application or not handed to it, as it is not of much of use to the custom firmware and since this packet is required only the libmdot to deal with DR changes?

Thanks,
Ajay

[Ajay K]

Thanks Jeff. Although that makes sense, but 2 minutes is quite a lot. Can you point me to any samples of code that can talk to the mqtt using c++. Sorry for the ask, I am just trying not to re-invent the wheel if there is existing code that has already been written, like the lorawan service that comes with the conduit, which handles both uplink and downlink of packets?

Thanks,
Ajay.

[Ajay K]

Hi Mike,

Thanks for getting back to this thread. We have already opened a ticket already for the same issue and have provided the necessary logs. Its not that it can’t be reproduced easily, but in my case when the mdot is run over a period of time, it starts to generate the “Transmit In Progress” error.

The case# for the ticket opened is 5079839.

Also the mdot lib version the custom firmware was built against is 2.0.17 and mbed os 5.4.2.

Thanks,
Ajay

[Ajay K]

Thanks Jeff for confirming. Yup will ensure on re-install of firmware the customapp priority levels are set correctly.

Thanks,
Ajay

[Ajay K]

Hi Jeff,

For the stop levels i.e. 0, 1 and 6 the priority of the custom app is at 1 on my conduit, so its going to be run/shutdown after the lora-network-service and mosquitto has already been shut down.

For the Start level i.e. 2, 3, 4, 5, the Lora-network-service is running at a priority of 80 and the mosquitto is at 75 and the customapp on my conduit is at 95. So I would like to run the customapp between the priority levels of the mosquitto and lora-network-server, say 77. so I would end up running the command as you have mentioned above and as shown below.

update-rc.d customapp defaults 77 1

So once the firmware upgrade has completed I am guessing it will begin any customapp installs. In the post install step, i will remove the customapp init.d settings using the “update-rd.d -f customapp remove” command and install the customapp init.d settings with the changed priority level as shown above. Do you see any issues with this approach or any obvious concerns?

I did make those changes on my conduit to test it out, and this time the custom app starts 20 seconds ahead of the lora-network-server” service and at least i can be assured no loss of packets, because of service startup delays.

Thanks,
Ajay.

[Ajay K]

3) You should be able to use the postinstall step to do that. I think in the case you have described you will need two init scripts. One with just a start() to start the app before the LoRa WAN server with an empty stop() that does nothing, and a second script that will be run after the LoRa WAN script that has the stop() defined to stop the app that has an empty start().

Based on the comments above. Instead of creating two brand new scripts, do you see any issues in updating the start priority of customapp script in the init.d folder, as the kill is being done in the correct order, lorawan server first and then the custom app.

if you don’t see any issues, Should I update the priority of the customapp script during the install of my custom app. Since there is only one custom app and I would like it to start before the Lorawan service is up and running?

Again yesterday while testing this we lost a packet just because the custom app launched 20 seconds after the lorawan service.

Thanks,
Ajay

[Ajay K]

Jeff,

I was able to both start/stop the application from node-red based of the URL you had mentioned earlier and I used the http request node. Also the LOCAL id worked perfectly well.

Thanks once again for your timely responses.

Thanks,
Ajay

[Ajay K]

Hi Jeff,

Thanks so much for taking the time to respond and write out a detailed way to start/stop the custom app. I did try to get the custom App Id based of the suggestion above. I am not sure why though the appId is written out as “LOCAL“. Is that correct? The custom app was installed on the conduit flash.

Thanks,
Ajay.

[Ajay K]

Thanks Jeff for your response. I was hoping the start/stop was being executed via one of the AEP Web API Command endpoints. So currently the Web UI uses the app-manager to start and stop the application?

Thanks,
Ajay

[Ajay K]

Thanks Jeff for your response.

1)However if you look at it the files are compressed into the tar.gz file and the app-manager copies over to the /var/app folder and runs the install and start scripts, so if it is able to do all that not sure why giving it permissions to execute is making it less secure, unless the install and start scripts are a suspect. Having said that I will update my scripts to do just that.

2) Regarding the firmware upgrade, I never thought of that of creating the soft links via the install, that will solve the issue, I will do that. So I am guessing the App-Manager during a firmware upgrade looks for the tar.gz file under the /var/app/<app-name> folder or is there an upgrade dir where the <app-name>tar.gz file needs to be present?

3) Lastly instead of creating a brand new init script, is it possible to run the rc.update utility in the postInstall step and still change the priority? Also while it boots I was hoping the custom app starts before the lora wan server and when the conduit is being rebooted the custom app is terminated after the lora wan server is shut down. I should be able to do all that with the rc.update utility right?

All this I am doing just to compensate for the scenario where we end up loosing packets that were ack-ed by the lora wan server for an uplinked packet, but node-red already was either shutdown or not yet up and running when the conduit boots up.

Thanks,
Ajay

[Ajay K]

Hi Jeff,

I had the permission issue resolved, however I think the app-manager or some other script should handle the step that I did it to get it to work.

So I had to run chmod +x Install and chmod +x Start commands on the Install and Start scripts so they have execute permissions and then generate the tar files. After which the Install went thru’ fine.

Also I wasn’t initially couldn’t pipe the console.log outputs of my custom application to a log file using the “–startas /usr/bin/node”, however using the angel process as a part of my start scripts allowed me to do pipe the console o/p successfully to a custom log file.

As you suggested I created a soft link to the angel application under /sbin and gave it a unique name and that shouldn’t clash with node-angel. However I am wondering how we would deal with a firmware upgrade and creating a soft link and installing the custom app?

Also is there a way I can get a custom app launch before the lora-wan server/service is up and running?

Thanks for all your help and inputs.

Thanks,
Ajay

[Ajay K]

Since the scripts don’t seem to be honoring the SDCard settings in the manifest.json, so I removed the SD card from the conduit and ran the script and this time I get a “Permission Denied” error and is as shown below.

Locally installing [LoraUplinkPktManager]
sh: /var/config/app/LoraUplinkPktManager/Install: Permission denied
AppCommand::runInstall: failed to execute Install script: /var/config/app/LoraUplinkPktManager/Install install

AppCommand::executeLocalInstall: Install failed in /var/config/app/LoraUplinkPktManager/
Command local failed with:
appId UNKNOWN
appName LoraUplinkPktManager
appVersion UNKNOWN
appType CUSTOM
appStoreIP http://www.devicehq.com
configids {“ids”:[]}

However the folder structure seems to have been created under /var/config/app, but the overall application fails to be installed.

Thanks,
Ajay

[Ajay K]

Hi Jeff,

Yes I did upgrade my firmware to 1.4.1 firmware as soon it was released. I double checked the firmware version again and it is 1.4.1. The command that was executed as mentioned below and like the link suggests I have set the SDCard key to false in the manifest.json.

app-manager --command local --appfile LoraUplinkPacketManager.tar.gz --appname "LoraUplinkPacketManager" --apptype CUSTOM

Thanks,
Ajay

[Ajay K]

Is there anything else I need to pass to the app-manager command line to clearly indicate this needs to be installed on the flash, other than using the “local” command? Currently even with the SDCard key set to false in the manifest.json, the App-manager still installs it on the SD card on my conduit

Thanks,
Ajay

[Ajay K]

Thanks Jeff for pointing that out. So I am guessing using the node-angel is risky. Since I need my custom app running even if node-red is shutdown. Also as far as piping the o/p logs to a file, I did as you suggested in an earlier thread, is this the correct way to handle it?

$START_STOP_DAEMON --start \
                      --background \
                      --pidfile "$PID_FILE" \
                      --make-pidfile \
                      --chdir "$RUN_DIR" \
                      --startas "$DAEMON" \
                      -- "$DAEMON_ARGS >& $APP_LOGDIR/$NAME.log"

Thanks,
Ajay

[Ajay K]

Also in the Start scripts for the custom app, is it okay to use the node-angel like the node-red start up script?

for ex:

$START_STOP_DAEMON --start \
             --background \
             --pidfile "$PID_FILE" \
              --make-pidfile \
               --chdir "$RUN_DIR" \
               --startas /sbin/node-angel \
               -- /bin/bash -c "exec $DAEMON -- $DAEMON_ARGS >& $APP_LOGDIR/$NAME.log"

or can the same thing be achieved from the daemon command below.

$START_STOP_DAEMON --start \
                      --background \
                      --pidfile "$PID_FILE" \
                      --make-pidfile \
                      --chdir "$RUN_DIR" \
                      --startas "$DAEMON" \
                      -- "$DAEMON_ARGS >& $APP_LOGDIR/$NAME.log"

Thanks,
Ajay

[Ajay K]

Hi Jeff,

Thanks for taking the time to respond and writing in such detail. In terms of restarting an application, do other apps like lora-wan server, and node-red, do they implement this at their end. I am just wondering if its worth spending time on this?

Also is there a way to invoke this script that you mentioned above from node-red flow to say re-start a custom app, if it went down by any chance?

Thanks,
Ajay

[Ajay K]

Hi Jeff,

Here is the contents of the manifest.json. Is it because the false set for the SDCard is not enclosed in double quotes?

{
    “AppName” : “LoraUplinkPacketMgr”,
    “AppVersion : “1.0”,
    “AppDescription” : “Manages LORA Uplink Packets”,
    “AppVersionNotes” : “instaling on flash”,
    “SDCard” : false
}

Thanks,
Ajay

[Ajay K]

Roman,

I have reproduced this every time. When an MDot is connected previously to a network and the conduit is power-cycled, the only way the mdot can send a packet successfully is when you rejoin the network. In my case I have acks enabled, so I would get continuous ack failures, even after the conduit is up and running and the mdot api getNetworkJoinStatus() will return true, even though the conduit has been power cycled . I am not sure why the re-join helps, may be the multi-tech team can shed some light on it.

Thanks,
Ajay

[Author]

Posts