[Tom Z]

thanks for the quick reply Jeff

We are using Python for the custom app. Actually when I log in to the UI, the app is running, and I see it is subscribed even to the mqtt broker.

Is your script generating a pid file?

yes we are.

question: can we restart the app from within the app?

this way i can publish and subscribe to /test every 5 min and if it fails I can restart the script

your thoughts?

[Tom Z]

hi,
did you find a solution for this?

our script will randomly stop

and the last message I see is:

2021-05-03T14:41:02.572515+00:00 mtcdt ppp-rx-monitor: No packets Received from last 2130 seconds
2021-05-03T14:41:32.843217+00:00 mtcdt ppp-rx-monitor: No packets Received from last 2160 seconds
2021-05-03T14:42:03.038134+00:00 mtcdt ppp-rx-monitor: No packets Received from last 2190 seconds
2021-05-03T14:42:20.241522+00:00 mtcdt APPMANAGER: LockFile::GetLockNB: attempting to get file lock
2021-05-03T14:42:20.242940+00:00 mtcdt APPMANAGER: LockFile::GetLockNB: Got lock on fd 5
2021-05-03T14:42:20.623567+00:00 mtcdt APPMANAGER: AppCommand::executeStatus: Getting app statuses
2021-05-03T14:42:20.629987+00:00 mtcdt APPMANAGER: AppCommand::getBasePathFor returning /var/config/app/
2021-05-03T14:42:20.633370+00:00 mtcdt APPMANAGER: AppCommand::executeStatus: can't read pid as a string, trying as number:#012 in Json::Value::asCString(): requires stringValue
2021-05-03T14:42:20.635486+00:00 mtcdt APPMANAGER: AppCommand::executeStatus: kill 0 detected process at 2815, setting status to RUNNING
2021-05-03T14:42:20.643069+00:00 mtcdt APPMANAGER: Released lock on fd
2021-05-03T14:42:20.643731+00:00 mtcdt APPMANAGER: Exiting with success status
2021-05-03T14:42:33.121958+00:00 mtcdt ppp-rx-monitor: No packets Received from last 2220 seconds
2021-05-03T14:42:50.453283+00:00 mtcdt APPMANAGER: LockFile::GetLockNB: attempting to get file lock
2021-05-03T14:42:50.454696+00:00 mtcdt APPMANAGER: LockFile::GetLockNB: Got lock on fd 6
2021-05-03T14:42:50.877799+00:00 mtcdt APPMANAGER: AppCommand::executeStatus: Getting app statuses
2021-05-03T14:42:50.883935+00:00 mtcdt APPMANAGER: AppCommand::getBasePathFor returning /var/config/app/
2021-05-03T14:42:50.888186+00:00 mtcdt APPMANAGER: AppCommand::executeStatus: can't read pid as a string, trying as number:#012 in Json::Value::asCString(): requires stringValue
2021-05-03T14:42:50.889581+00:00 mtcdt APPMANAGER: AppCommand::executeStatus: kill 0 detected process at 2815, setting status to RUNNING
2021-05-03T14:42:50.897556+00:00 mtcdt APPMANAGER: Released lock on fd
2021-05-03T14:42:50.898960+00:00 mtcdt APPMANAGER: Exiting with success status

what strange is that in some cases, I see this same error, but the script doesn’t malfunctions

and in other cases I see the same error and I see a script restart in the logs

2021-05-03T12:46:23.243569+00:00 mtcdt annexcd: [INFO] mts_device_interface.cc:getNetworkInterface:444: link_type = ETHER
2021-05-03T12:46:23.271378+00:00 mtcdt annexcd: [DEBUG] courier.cc:InspectContainer:149: send container: packages {#012  message_id: 172#012  time_packaged: "2021-05-03T12:46:22Z"#012  time_sent: "2021-05-03T12:46:23Z"#012  content {#012    type: TYPE_ATTRIBUTE#012    attribute {#012      type: TYPE_NETWORK_INTERFACE#012      network_interface {#012        name: "br0"#012        link_type: LINK_TYPE_ETHER#012        flags {#012          up: true#012          lower_up: true#012          loopback: false#012          broadcast: true#012          pointtopoint: false#012          multicast: true#012          dynamic: false#012          noarp: false#012          allmulti: false#012          promisc: false#012        }#012        mtu: 1500#012        inet_settings {#012          method: METHOD_MANUAL#012          ip_addrs {#012            addr: 16951488#012            network_prefix_length: 24#012          }#012          default_route: 16951488#012          name_servers: 4261521600#012          interface_name_servers {#012            name_servers: 0#012          }#012        }#012        link_statistics {#012          rx_bytes: 0#012          rx_packets: 0#012          rx_errors: 0#012          rx_dropped: 0#012          rx_overrun: 0#012          rx_multicast: 0#012          tx_bytes: 42#012          tx_packets: 1#012          tx_errors: 0#012          tx_dropped: 0#012          tx_carrier: 0#012          tx_collisions: 0#012        }#012        current_wan: false#012      }#012    }#012  }#012}#012
2021-05-03T12:46:23.299298+00:00 mtcdt annexcd: [DEBUG] delivery_agent.cc:FillDhcpServer:562: filling dhcp service message
2021-05-03T12:46:23.301487+00:00 mtcdt annexcd: [INFO] delivery_agent.cc:RunnableCore:3590: sending GPS data
2021-05-03T12:46:23.302232+00:00 mtcdt annexcd: [INFO] delivery_agent.cc:RunnableCore:3593: gpgaa: 
2021-05-03T12:46:23.303524+00:00 mtcdt annexcd: [INFO] delivery_agent.cc:RunnableCore:3594: gpgll: 
2021-05-03T12:46:23.304341+00:00 mtcdt annexcd: [INFO] delivery_agent.cc:RunnableCore:3606: sending active apps
2021-05-03T12:46:23.306308+00:00 mtcdt annexcd: [INFO] mts_device_interface.cc:getActiveApps:527: Skip node-red apps as node-red is not supported
2021-05-03T12:46:23.346141+00:00 mtcdt annexcd: [DEBUG] courier.cc:InspectContainer:149: send container: packages {#012  message_id: 173#012  time_packaged: "2021-05-03T12:46:23Z"#012  time_sent: "2021-05-03T12:46:23Z"#012  content {#012    type: TYPE_ATTRIBUTE#012    attribute {#012      type: TYPE_DHCP_SERVER#012      dhcp_server {#012        enabled: true#012        range_start: 1677895872#012        range_end: 4261587136#012        lease_time: 86400#012        netmask: 16777215#012        gateway: 16951488#012        dns: 16951488#012        interface: "br0"#012        leases {#012        }#012        fixed_addresses {#012        }#012      }#012    }#012  }#012}#012packages {#012  message_id: 174#012  time_packaged: "2021-05-03T12:46:23Z"#012  time_sent: "2021-05-03T12:46:23Z"#012  content {#012    type: TYPE_ATTRIBUTE#012    attribute {#012      type: TYPE_GPS_NMEA#012      gps_nmea {#012        gpgga: ""#012      }#012    }#012  }#012}#012
2021-05-03T12:46:23.455495+00:00 mtcdt APPMANAGER: LockFile::GetLockNB: attempting to get file lock
2021-05-03T12:46:23.456924+00:00 mtcdt APPMANAGER: LockFile::GetLockNB: Got lock on fd 5
2021-05-03T12:46:23.705925+00:00 mtcdt APPMANAGER: AppCommand::executeStatus: Getting app statuses
2021-05-03T12:46:23.712323+00:00 mtcdt APPMANAGER: AppCommand::getBasePathFor returning /var/config/app/
2021-05-03T12:46:23.717049+00:00 mtcdt APPMANAGER: AppCommand::executeStatus: can't read pid as a string, trying as number:#012 in Json::Value::asCString(): requires stringValue
2021-05-03T12:46:23.718691+00:00 mtcdt APPMANAGER: AppCommand::executeStatus: kill 0 detected process at 2815, setting status to RUNNING
2021-05-03T12:46:23.726695+00:00 mtcdt APPMANAGER: Released lock on fd
2021-05-03T12:46:23.727851+00:00 mtcdt APPMANAGER: Exiting with success status
2021-05-03T12:46:23.739908+00:00 mtcdt annexcd: [DEBUG] delivery_agent.cc:FillActiveApps:1091: =======================================
2021-05-03T12:46:23.741101+00:00 mtcdt annexcd: [DEBUG] delivery_agent.cc:FillActiveApps:1092: App type = CUSTOM
2021-05-03T12:46:23.743669+00:00 mtcdt annexcd: [DEBUG] delivery_agent.cc:FillActiveApps:1093: App name = IotGatewayRecieverMQTT
2021-05-03T12:46:23.745468+00:00 mtcdt annexcd: [DEBUG] delivery_agent.cc:FillActiveApps:1094: App _id = 60009a81d76dad6793d4e7c6
2021-05-03T12:46:23.746660+00:00 mtcdt annexcd: [DEBUG] delivery_agent.cc:FillActiveApps:1095: App version = 2.5
2021-05-03T12:46:23.748280+00:00 mtcdt annexcd: [DEBUG] delivery_agent.cc:FillActiveApps:1096: App status = RUNNING
2021-05-03T12:46:23.749459+00:00 mtcdt annexcd: [DEBUG] delivery_agent.cc:FillActiveApps:1097: App info = Published success for proxy.iot-experts.net on topic /incoming/thingsboard#012
2021-05-03T12:46:23.750682+00:00 mtcdt annexcd: [DEBUG] delivery_agent.cc:FillActiveApps:1107: Adding this app to ActiveApps annex message..
2021-05-03T12:46:23.751993+00:00 mtcdt annexcd: [INFO] delivery_agent.cc:SendActiveApps:1022: Sending Active Apps data
2021-05-03T12:46:23.754048+00:00 mtcdt annexcd: [INFO] delivery_agent.cc:RunnableCore:3616: sending lora
2021-05-03T12:46:23.771958+00:00 mtcdt annexcd: [DEBUG] courier.cc:InspectContainer:149: send container: packages {#012  message_id: 175#012  time_packaged: "2021-05-03T12:46:23Z"#012  time_sent: "2021-05-03T12:46:23Z"#012  content {#012    type: TYPE_ATTRIBUTE#012    attribute {#012      type: TYPE_ACTIVE_APPS#012      active_apps {#012        active_apps {#012          name: "IotGatewayRecieverMQTT"#012          id: "60009a81d76dad6793d4e7c6"#012          version: "2.5"#012          status: "RUNNING"#012          info: "Published success for proxy.iot-experts.net on topic /incoming/thingsboard\n"#012          type: "CUSTOM"#012        }#012      }#012    }#012  }#012}#012
2021-05-03T12:46:23.951725+00:00 mtcdt annexcd: [INFO] delivery_agent.cc:FillLoraServerStats:1129: lora network is running
2021-05-03T12:46:23.951984+00:00 mtcdt annexcd: [INFO] delivery_agent.cc:FillLoraServerStats:1133: lora network server is enabled

i am using 5.3.3

my script uses paho mqtt to grab messages from the local mqtt server and to send it to the mqtt server in the cloud.

any idea how to ensure stability here?

[Tom Z]

Thanks for the reply Jason, that is awesome to learn!

Tell me, currently the only way to initiate a firmware process is with AEP Gateway, is that correct?

Will it support FOTA from other network servers in the future?

Also, for the mDot, how long takes a typical FOTA process? We are trying to calculate battery consumption as ours is a very power-restricted device.

Thanks in advance,

• This reply was modified 5 years, 3 months ago by Tom Z.

[Tom Z]

Hi Ajay

they will probably add it soon, meantime you can find it in the ZIP you download for 5.0

but I will also post it here for you 🙂

AEP firmware 5.0.0 – June 2019
—————————————————–
Changes made since release 1.7.4:
– Migration of Web UI to vueJS. Look and Layout has changed.
– Added RADIUS support.
– DHCP Lease Time displays expiration date and time.
– Firewall display/layout aligns more with Linux layout.
– Implement X.509 Certificate support.
– Eliminate Default Username and Password. User prompted to set up a Username and
secure Password upon Factory Default/Hard Reset, Commissioning Mode.
– The Logout option has changed to Door Exit icon.
– The browser tab name references page name.
– Changed LogIn screen to sign-in.
– Page links have removed the .html extension.
– Add IPSec certificate based authentication support.
– Updated supported ciphers in multiple features (SSH, HTTPS, etc…).
– Implement Trusted IP feature.
– Implement Self-Diagnostics beta feature to check Resource Overuse and
Security Violations.
– Incorporated Signed Firmware support.
– SNMPv3 advanced security settings enhancements and support for multiple trap
destinations. Extended SNMP read parameters.
– Usage Policy implementation in the Web UI.
– Display Notifications sent via Email, SMS, or SNMP.
– RADIUS Message Authenticator Attribute was added to all PAP requests.
– Implement tunnel features.
– Implementation of more Network Interface capabilities under
Setup > Network Interfaces.
– Updated Global DNS Configuration under Setup > Global DNS.
– Added Bootloader password configuration to the Initial Setup Wizard.
– LoRa Network Server updated to v2.2.27.
– LoRa Packet Forwarder: Added duplicate packet filter, fix for GPS lock and time
synchronization and increased radio lead time for better downlink success.

[Tom Z]

Hi

for starters you should upgrade to 1.7.4 or 5.0.0

Downloads

now because node-red and nodeJS on the conduit are older less updated versions, you might run into install issues with some of the nodes.

I will try it tomorrow when I work on the conduit and let you know, but meantime, upgrade and try again.

• This reply was modified 5 years, 4 months ago by Tom Z.

[Tom Z]

Thanks for the quick and accurate reply Jason, much appreciated.

Yea we do not have SPI to SPI wiring on our board right now and adding it not really an option.

[Tom Z]

Hi Jason,

Is it possible to create a custom AT+Command on the xDot?

Currently, our end-device is wired via UART and we work with the lorawan stack with AT+Command. But for an upcoming project, we need to use proprietary msg format (as to my previous message in this thread). But as it seems, from our private conversation, we will need to re-wire our board to connect to SPI which complicate things for us and requires board modification.

So I had this wild idea, if we could write code to the xdot or even wrap it as an AT+Command, we can keep our current wiring, and work the radio from the xDot and not our MCU.

Does this make sense? is it possible?

Thanks

[Tom Z]

also, recently a very relevant NODE was added to node-red library.

https://flows.nodered.org/node/node-red-contrib-msg-queue

might work for you

[Tom Z]

May I ask, where are you forwarding your packets to?

[Tom Z]

Hi
thanks for the reply

we also had a correspondence with the Actility tech team and they identified the issue and corrected the issue.

Turnout our gateway is automatically provisioned with EU LoRa frequencies (it has a EU cellular modem and P/N, but a US915 lora mcard). Changing the frequencies from the Actility console worked only partially as the joinAccept were being sent using EU ISM format, which is longer then what is supported by US ISM.

So Actility will release a bug fix in the next image for the conduit, and in the meantime they applied a hot-fix on our gateway.

you can see the tread here to get a bit more technical.

I must tip the hat for the actility team for helping us identify and address the issue within 2 days while we are still on the Developer Free Plan!

[Tom Z]

Hi Jason

So if we go with the Conduit network server, on each gateway, is there a way to configure the network server remotely? Will it just be a script that updates the config files and resets it?

The idea here is to handle device provisioning on each gateway remotely, and also to update keys if needed.

Can we use AEP to do so?

[Tom Z]

Great, so I could have a logic in place that if network connectivity is down, the packet will be forwarded to the locally ran network server, where it will be decoded and some action will be triggered. Otherwise it will go uplink to TTN. For that though the keys from TTN will have to be known to the locally hosted network server, is there a way to sync those?

[Tom Z]

Thanks for the clarification @jason, can we run both a network server and a network packet forwarder on the gateway? This way perhaps in the firmware of the device, we can send 2 messages on alerts, one to be decoded by the local network server, and the other to be picked by the main network server?

do you have any other suggestions here?

[Author]

Posts