[Jeff Hatch]

Youssuf,

Be aware that the AEP Conduit runs an old version of Node-js (0.10.40) and an older version of Node-RED (0.11.1). My point is that some of these dashboard GUIs require a newer version of Node-RED and most likely Node-js. Make sure to verify that the dependencies can be met up front if you can.

Jeff

[Jeff Hatch]

Pradeep,

By “get the sensors notification on server/application” do you mean that you want to use the Conduit as the gateway to send information from the mDot to a server running an application on the Internet/Cloud? If that is the case, is there an API for the server on the Internet/Cloud that you can use? If it is an HTTP REST API, for example, there are http nodes and even some API specific nodes that are available. Which service do you want to use?

The Conduit currently does not have Geo-location ability. That is about to change soon with the new hardware that will be release sometime Q1 2017.

As for question #3, I am not sure which application you are talking about on DeviceHQ. Is it a Node-RED application? Is it the DeviceHQ application itself?

Jeff

[Jeff Hatch]

Hello,

Yes, there are plans for built-in WiFi support. The hardware and supporting firmware are due to be released in this current Q1 2017. Testing of the firmware and hardware are starting this month. From that point it shouldn’t be more than a month or two and it will be released to customers.

Jeff

[Jeff Hatch]

Hello,

There is currently not a USB accessory card. For the SD Card, the maximum size that we have successfully tested with Conduit is 32GB. There are currently no SATA modules “built in” to the Conduit kernel, and no SATA drivers on-board. It is not currently supported, so you would have to build and install the SATA kernel modules yourself to get that working.

Jeff

[Jeff Hatch]

Ack, second paragraph of previous entry should say:

On AEP, for a short press a SIGHUP is sent to the reset-monitor. For a long press a SIGUSR1 is sent to the rest-monitor. For an extra long press a SIGUSR2 is sent to the reset monitor. These are not the hard-coded defaults, but are set on boot by the AEP watchdog process. On the AEP Conduit the reset monitor process is the watchdog process. The following is what happens for each button press length:

Jeff

[Jeff Hatch]

All,

I looked at the code that handles the reset button press. It is handled in the mts-io kernel module and by the reset-monitor process. The kernel module keeps track of a short press (~5s), a long press (> ~5s && <= ~30s), and an extra long press (> ~30s).

On AEP, for a short press a SIGHUP is sent to the reset-monitor. For a long press a SIGUSR1 is sent to the rest-monitor. For an extra long press a SIGUSR2 is sent to the reset monitor. These are not the hard-coded defaults, but are set on boot by On the AEP Conduit the reset monitor process is the watchdog process. The following is what happens for each button press length:

short press (< ~5s): the system just reboots long press (> ~5s && < ~30s): the device is reset to user defined defaults and rebooted. The factory settings are used if user defined defaults have not been set. extra long press (> ~30s): the device is reset to factory defaults.

I believe that the status LED should go solid at the start of reboot until the kernel is back up and the mts-io module is reloaded, then the status LED should start blinking normally again, but don’t quote me on that as I have not dug into that functionality to verify that.

I have not observed any behavior outside these parameters on my device, however it is only one device, and the hardware is almost a year old.

I am interested what the load is on these devices that are exhibiting this bad behavior on reset. If you have time to gather some information and let me know here or file a support portal ticket at https://support.multitech.com, please let me know. If you can provide the following information:

1) Output of a top command to see what the CPU and memory state of the system is.
2) A ‘cat’ of /sys/devices/platform/mts-io/reset-monitor.
3) A ‘cat’ of /sys/devices/platform/mts-io/reset-monitor-intervals

That would be a start to figure some of these issues out. If #’s 1, 2, and 3 look OK, maybe it is an actual bad hardware problem.

Thank You,

Jeff

[Jeff Hatch]

JJ,

Please open a support portal case at https://support.multitech.com for this. The odd behavior you are seeing with the LEDs when you just touch the device looks like there is something wrong with the board. If this is indeed a defective device, you can get it changed out for a new one.

Jeff

[Jeff Hatch]

Tae,

Pretty much all of the Conduit documentation for both the AEP and mLinux models is online on the multitech.net developer site. The software developer documentation can be found at:

Software

Jeff

[Jeff Hatch]

Adam,

Could you run the “route -n” command on the Conduit and copy the output to this thread? Also, do you have a PPP interface configured?

Jeff

[Jeff Hatch]

Szymon,

On the AEP Conduit in the Web UI the Cellular options are what configure and control the PPP connection. You can enable access to the Web UI over the PPP connection by going to Administration->Access Configuration and enabling HTTPS Via WAN (upper right hand side of the page).

Jeff

[Jeff Hatch]

Tae,

The debug console micro-usb connector is behind the little white plate on the “front” of the Conduit. You can remove it by removing the screw. You can then use a USB cable and connect the debug console to your PC. From there you should be able to use PuTTY or some other terminal program to log in at the console. The default credentials are root/root for an mLinux Conduit, admin/admin for an AEP Conduit.

Once you get into the debug console you should be able to change the IP on the Conduit using the /etc/network/interfaces file or whatever preferred method you have for setting the IP on LINUX.

The Conduit does support DHCP. You will have to enable/start the DHCP client using a script.

Jeff

[Jeff Hatch]

Jerome,

We are currently working on a release that has support for configuring what we call WAN failover. When this is released you will be able to prioritize your WAN interfaces, and the Conduit will detect when a failover needs to occur. This functionality is not available in the current release.

You could create a script that pings through the LAN interface, and when it detects failure, change the gateway settings to point to the PPP interface.

Jeff

[Jeff Hatch]

Ajay,

We have not tested installing Mongo on a Conduit. There have been customers that have installed Postgres DB, but not Mongo that I know of.

In order to install Mongo it will have to be compiled for ARM architecture. The AEP Conduit is based off of the Yocto OpenEmbedded project. There is a Mongo bitbake recipe for building it here:

https://layers.openembedded.org/layerindex/recipe/24093/

I would recommend using the mLinux distro to build Mongo and to generate the *.ipk files (packages) to install on the Conduit. There are instructions for getting started with that here:

Building Images

You can add your bitbake recipe to the meta-mlinux bitbake layer, and build Mongo. You will have a lot more questions, so don’t hesitate to ask.

Jeff

[Jeff Hatch]

Ajay,

In the case of the expressHelloWorld example, all the node dependencies are right in the application, and are not installed outside of the application’s directory in /media/card/expressHelloWorld. That means that all the require statements are relative to the app.

The Mongodb server software can probably fit on the Conduit, but I would recommend that if you are going to have a significant amount of data (over 1 Meg) then you should probably have the actual data on the SD Card. There is maybe 7MB available of persistent flash available in /var/config that won’t get overwritten on upgrade.

As for localhost connections, you can pretty much use whatever ports you want. However, 53, 80, 443, and 1081 are used by DNS, the API, and Node-RED, respectively.

Hope that is helpful.

Jeff

[Jeff Hatch]

Ivan,

I have heard that one has to download and install/reinstall some drivers in order to get the debug console to work. I do not have a Windows 10 machine to replicate the process, but you should be able to Google for a solution, or set up a virtual Ubuntu Linux machine and use that to connect to the Conduit.

Jeff

[Jeff Hatch]

Tae,

The default IP on the Conduit is 192.168.2.1. It is possible that your PuTTY connection is being routed to the WiFi interface. If you log into the debug console on the Conduit, can you ping your PC’s address on the interface the Conduit is connected on?

Jeff

[Jeff Hatch]

Michael,

The AEP also provides a number of features implemented on the Conduit including Cellular connection management, Node-RED and Custom application management, firewall rule management in a Web UI, remote management through DeviceHQ, and several other features.

Jeff

[Jeff Hatch]

Yusuf,

You should not have to remove the do_flash_upgrade file if it is in /var/volatile. That directory is volatile and gets erased on reboot. That is why umountfs doesn’t reflash over and over again in the normal upgrade path.

For flashing with and SD card out of the factory, please file a support portal case at https://support.multitech.com.

Jeff

[Jeff Hatch]

Ivan,

Which version of Windows are you using? Usually a driver installation is not required.

Jeff

[Jeff Hatch]

Magouero,

Other than enabling the Web UI over WAN, I am not sure there are any alternatives at the moment. The LoRa configuration may be added to DHQ at a later date, but for now it is not available.

Sorry,

Jeff

[Jeff Hatch]

Magouero,

There is a reference for our MTR API which is pretty much the same as the AEP API (with the exception that there are different features and thus different collections in the API database):

http://www.multitech.net/developer/software/mtr-api-reference/

You should be able to use this interface to set whatever parameters are available in the AEP Web UI. The URL paths for the API follow the patterns in the collections in the /var/config/db.json file on the AEP Conduit.

Jeff

[Jeff Hatch]

Radu,

Have you tried using the multi serial out node instead? That node is designed to work with the multitech serial accessory card.

Jeff

[Jeff Hatch]

Yogesh,

The API for the MTR is very similar:

http://www.multitech.net/developer/software/mtr-api-reference/

Just the paths for some of the collections have changed and there are a bunch of features like the LoRa configuration that have collections that are not documented in the MTR API reference for obvious reasons.

The API URL paths correspond to the nesting of the json collections in the /var/config/db.json, so to find a collection you can use that file as a reference. Maybe someday we’ll have time to create the reference for AEP.

Jeff

[Jeff Hatch]

Steve,

It has not been patched yet. We are working on integrating the patch with mLinux and it should be available soon. Hopefully in the mLinux 3.2.1 that we are preparing to announce the release of.

Jeff

[Jeff Hatch]

Shmuel,

Don’t worry about recreating for our sake. Thank you for posting what you found and what fixed your problem for other people to reference. I’m sure this has happened to other people, and it gives people another possible fix when this type of thing happens.

Cheers,

Jeff

[Jeff Hatch]

Shmuel,

Could you capture a “tail -f /var/log/messages” to a file either using a terminal program or “tail -f /var/log/messages > /var/config/upgrade.log” during an upgrade attempt. Then file a Multitech Support Portal case at https://support.multitech.com and attach the captured logging to the case?

I would like to see what the logs are saying during the upgrade attempt. I have not heard of this type of thing happening much since we fixed a memory leak in the Conduit API back on 1.2.1.

Jeff

[Jeff Hatch]

Shmuel,

I’m assuming that you are using the Web UI upgrade and haven’t gotten the jffs2 and kernel images from somewhere.

How full is the root filesystem on the device? I have seen instances on upgrades in the past where if the API process or lighttpd process cannot allocate enough memory for the download of the upgrade file it will appear to silently fail. The failure will show up in the logs, but the reboot clears out all the logs so we lose any record of the failure.

Jeff

[Jeff Hatch]

Heath,

If you are looking to create an .ipk file to install the newer version of Curl with I would check out the version of mLinux that your Conduit is running from git://git.multitech.net/mlinux.git, build it, and then get the bitbake recipes for the updated version of Curl that you want, add the newer recipe(s) to the meta-mlinux or meta-multitech layer in your local mLinux distro repository, then build curl with bitbake:

bitbake -c compile -f curl

This command will rebuild Curl and should try to use your new recipe. If that builds successfully, remove everything underneath the build directory and rebuild the mLinux factory image:

bitbake mlinux-factory-image

Then, under build/tmp/deploy/ipk/arm926ejste you should find the .ipk file for the new version of libCurl that you built. You can use this .ipk with the opkg command to install the upgraded version of libCurl.

Let us know if you’ve got more questions.

Jeff

[Jeff Hatch]

To get back to running AEP I think that the easiest way would be to create a support portal case at multitech.net and then we can provide you with the jffs2 and uImage.bin files to flash the AEP firmware. There are other ways, but that would be the most straight forward way to get the files you need to flash from u-boot.

Sorry about the misunderstanding,

Jeff

[Jeff Hatch]

Dibya,

I think you had an AEP model Conduit and not an mLinux model Conduit. This thread is on the mLinux forum so I guess I assumed you were using the mLinux model. You have flashed the mLinux firmware and not the AEP firmware. Please file a support portal case at https://support.multitech.com and someone can get you the rootfs and uImage files for AEP 1.3.2.

Sorry about that.

Jeff

[Author]

Posts