[Jason Reiss]

When the network server is shutdown all the database is saved to flash and reloaded on boot with all node session keys still intact. Nodes should not have to rejoin the network after a reboot.

Let us know if it is actually the case and we will address that.

Under what scenario would a Node-RED app that has been installed and running need to be rebooted? There may be an issue with other systems of the device not functioning properly. Perhaps the full reboot would be the appropriate action.

[Jason Reiss]

We will be addressing this in an upcoming upgrade. You should be able to setup a static route to able red ui with wan enabled.
You will want to route 1880 on the external to 1880 on 127.0.0.1.

[Jason Reiss]

The ping rssi and snr are the values received by the gateway. We will update mdot.h to document.

AT+PING uses that function and is documented here.
http://www.multitech.com/manuals/s000612_8.pdf

[Jason Reiss]

If the custom nodes are installed in /opt/node-red then they will not be saved over upgrade. Only files in the /var/config will not be touched by an upgrade.

This will also need some dev to get working. It appears the nodeDir option is not used in the settings.js file.

[Jason Reiss]

Looks like the /sbin/app.py script is writing the settings.js file.
There appears no place for a user settings.js file to incorporate functionality you are attempting.

At the end of line 604 in /sbin/app.py is the global context setting

I added the following and was able to use bcrypt in node-red.

functionGlobalContext: {bcrypt: require(“/opt/node-red/node_modules/bcrypt”)}

I tried using the bcryptjs modules hashSync it was not very responsive (never returned).
The bcrypt module version seemed to work ok.

[Jason Reiss]

From the node-red.log the settings file can be found. It has been moved into the /var/config directory so it will not be overwritten during a firmware upgrade.

/var/log/app/node-red.log

30 Oct 21:09:46 – [info] Settings file : /var/config/app/install/development/settings.js
30 Oct 21:09:46 – [info] User directory : /var/config/app/install/development
30 Oct 21:09:46 – [info] Flows file : /var/config/app/install/development/flows.json

[Jason Reiss]

Look at /etc/init.d/node-red, it maybe using the –userDir option. Try moving the settings.js file to that folder.

[Jason Reiss]

I think the file may need to be settings.js

[Jason Reiss]

For OTAA you need to set the following info:

“network” : { “eui”: “1122334455667788”, “key”: “” }

You can remove the “name” and “passphrase” settings, they are there to generate network eui and key from a string. If set you can see the generated eui and key in the log on start of the network server.

On the device the network eui setting is AppEUI and network key is AppKey.

I the above json the network key setting is missing. This needs to match the AppKey on the device.

[Jason Reiss]

Can you try the private network setup again?

Or you can try to connect to TTN with the AT Command firmware.

AT+PN=1
AT+NJM=0
AT+NA=
AT+DSK=
AT+NSK=
AT+ACK=1
AT&W
ATZ
AT+SEND=data

[Jason Reiss]

The eui can be configured in /var/config/lora/lora-network-server.conf on the Conduit.

Refer to the following page for configuration options:

Conduit mLinux: Advanced LoRa Configuration

[Jason Reiss]

Do you have the mLinux version?

If so there is no UUID and it cannot be used with devicehq.

[Jason Reiss]

Andrew,

When in MANUAL join mode, the call to join will not send a message out since it has the address and keys that would have been assigned and generated in the join request/accept messages.

What settings are you using for the packet forwarder config?
Have you configured the “synch_word” to be 52 for public network?

[Jason Reiss]

Assuming you are using Windows, have you installed the ST-Link driver?

https://developer.mbed.org/teams/st/wiki/ST-Link-Driver

[Jason Reiss]

Gilen,

The PinNames.h file has the pin mapping info.

https://github.com/mbedmicro/mbed/blob/master/libraries/mbed/targets/hal/TARGET_STM/TARGET_STM32F4/TARGET_MTS_MDOT_F411RE/PinNames.h

I’ll check into the component info.

[Jason Reiss]

What information are you looking for that would be found on the schematic?

[Jason Reiss]

Currently the network-server used on Conduit uses a network configuration similar to a wifi network with a network-id and network-key pair.

We will consider adding the ability to configure app-keys per device in a future release, as this will be a familiar concept to public network users.

[Jason Reiss]

There is a bootloader in the mDot accessible through the debug pins.

https://developer.mbed.org/platforms/MTS-mDot-F411/

30 PA_10 / DB_RX / USBRX NA
31 PA_9 / DB_TX / USBTX NA

Connect at 115200 baud with no flow control.
Press “enter” right after a reset to enter bootloader prompt.
From there enter “help” for options.
You can upgrade device firmware via ymodem.

[Jason Reiss]

James,

The quickest way to develop a demo using mLinux will be using node.js to post data via http/https to M2X.

Node.js https:
https://nodejs.org/api/https.html

M2X API:
https://m2x.att.com/developer/documentation/v2/overview

[Jason Reiss]

Building software for Conduit will require using a Linux distribution, we support and test Ubuntu and Debian.

Information for coding C for applications running in mLinux in Conduit can be found here:

Application Development

C/C++ Toolchain

[Jason Reiss]

The format of the cloud data will be dependent on the Cloud back-end you are using. Also delivery methods will be different depending on the version of Conduit you have. AEP includes Node-RED to connect to a cloud service, where as mLinux will need a separate application to deliver the data.

Questions:
1. What flavor of Conduit do you have? AEP or mLinux

2. What cloud service are you wanting to send data to?

[Jason Reiss]

To list the currently installed versions of lora packages on Conduit:

$ opkg list | grep lora

Upgrade page for mLinux:

Upgrade LoRa Server & Packet Forwarder

Upgrade page for AEP:
http://www.multitech.net/developer/software/aep/upgrading-the-aep-firmware/

[Jason Reiss]

Lewis,

Checkout the latest Developer Guide on
http://www.multitech.com/models/94557148LF.

See “Sleep/Serial Data Mode Options” section as the sleep configuration of the commands have changed.

The Serial Data mode is designed to work in conjunction with sleep.
The use case is when you want the mDot to wake-up periodically, signal a host, read data from the serial port and send it over the radio. Future enhancements will allow serial mode to be entered and escaped from the command line without entering the sleep cycle.

You can also type “help” or “?” to list the commands available in the firmware. Type “help ” to show description for one command.

The basic setup is as follows after configuring network settings:

0) See Wake mode help
> help AT+WM
AT+WM: Wakeup mode, INTERRUPT uses DIO7 as wake-up pin (0:INTERVAL,1:INTERRUPT)
1) Set to wake-up on interval (0:INTERVAL, 1:INTERRUPT)
> AT+WM=0
2) Set wake interval for 10 minutes
> AT+WI=600
3) Wait for serial data for 500 ms
> AT+WD=500
4) Timeout reading serial if no character for 20 ms
> AT+WTO=20
5) Enable auto-join mode to join on start and save session info in flash
> AT+NJM=2
6) Configure ACK’s or set LCC to send periodic link checks
> AT+ACK=4 (make 4 attempts to get response from server)
or
> AT+LCC=5 (request response every 5 packets)
7) Set number of missed responses to consider link dead and rejoin
> AT+LCT=10
5) Configure the mDot to start in Serial Data mode
> AT+SMODE=1
6) Save changes
> AT&W

Now if you issue AT+SD or ATZ the mDot will enter the wake-read-send-sleep cycle and monitor responses from the server to stay connected.

[Author]

Posts