Connect to a Meshtastic device: Connection status

[roberthadow]

I observe the following behavior in client.meshtastic.org V0.0.0-#2C409A7 at the "Connect to a Meshtastic device" screen.

For example, I'm looking at a screen with six devices. Two rows, three columns.

===

My machine curently has two devices connected by USB: B4F8 and A658. Both are advertising a IP on my local net, as are two others. Two others are currently offline.

Connection card

Each device has its own connection card with eight attributes. Here is box [1,2] Device 60C0.

(A) An icon (signficance unknown to me)
(B) Connection title - "My node" (user created)
(C) Connection status
(D) Meatball menu (one selection currently, Delete)
(E) Connection type icon
(F) Device ID (VID:PID)
(G) Connection history
(H) Action button

I believe this box was appropriately named in (B) Connection title. See dicussion in "My node" below. In (C) Connection status, it says "Connected". In the nodes list for the two USB-connected devices, I see one "Direct" connection and one "Unknown." In one case, it was seen an hour ago and in the other, seven. The device in the card above is advertising its IP on the local net, but it is not connected by USB to the web app.

The connection card attribute (F) Device ID is 10c4:ea60 Silicon Labs CP210x UART Bridge, It shares this attribute with three other cards, one of which is using that bridge right now.

The Connection history (G) for 60C0 says "Never connected." This is inaccurate. It has been previously connected.

The Action button (H) for 60C0 says "Disconnect", implying that the device is currently connected. It is not.

====

Now we look at a device that is currently connected: B4F8.

At (C) Connection status, it says "Disconnected". It is connected in another tab.

At (G) Connection history, it says "Never connected." But it is connected, right now.

The Action button (H) says "Connect" implying that the device is not connected. Clicking the Action button results in an error, "Failed to execute 'open' on 'SerialPort': Failed to open serial port." That's entirely logical. The serial port is already in use.

My node

In the "Add connection" dialog box, the user is invited to name the card as he or she chooses. That name will show up in (C) "Connection title". Names need to have signficance to the user. In my view, the name of the LoRa device (owner_long)_ is the logical text to go in this field. Technically, it might be more appropriate if the user were to put in the manufacturer and name of the USB device. That however requires that the user go digging around in a terminal session to cut and paste this name. Here is what it would look like for me.

===
I suggest this would lead to more user errors than it would solve. If this is the naming convention the designer intended, then don't let "Connection title" be a free text entry. Give a drop-down with manufacturer/product from the OS.

When BLE and TCP are enabled in the "Add connection" dialog, presenting the user with a drop-down list of available Bluetooth devices or a list of currently connected IP hosts will prevent the tears from folks who are asked to try an address.

Recommendations/Requests

Document the significance of Icon (A)
Correct the display of (C) "Connection status" or get rid of it.
Correct the display of (G) "Connection history" or get rid of it.
When a connection card has been used in another tab, label it "In use", make it grey, and disable the button.
In the "Add connection" dialog box, change "My serial node" from free text to a drop-down. [more discussion required]
In the "Add connection" dialog box, for the time being, when HTTP is selected, give an error message.
In the "Add connection" dialog box, when Bluetooth is selected, please correct the warning text. I use Chrome and still get the message.
In the "Add connection" dialog box, when Serial is selected, change the blank text warning to "Please select a USB port."

[roberthadow]

Naming My Node

Names need to have signficance to the user. They need also to be unique. And they should be unchanging from session to session.

Devices connected by Bluetooth

For the sake of consistency, we might adopt the same naming scheme used by the Android app. A name in the form aaaa_bbbb where aaaa is the short_name, underscore is underscore, and bbbb is the last four characters fo the MAC address. This name is easy for the user to recognize and remember.

Devices connected by TCP

If you've assigned a unique static IP to each device, naming a connection card by long_name (as I did in the original example of W2NJ 60C0) or by its address, say 192.168.1.203, are equivalent. The long_name is better for the user. It's unique and recognizable. It's not ideal,though. In order for the user to choose the correct connection card, he or she would need to loolk both at the "My node" name and the Connection type icon. Better to have the name include the connection type.

If we were to assign the "My node" name instead of letting the user name it, one way to do it that would be human readable, unique, and immutable would be to assign it a name in this form: aaaa_bbbb_TCP, where aaaa is the short_name, bbbb is the last four characters fo the MAC address, and TCP is the suffix for all WiFi connection cards.

Devices connected by USB

I reconsidered the proposalI I made above. It's not workable. Creating a connection card based on the text manufactuer/product, for example Espressif USB JTAG/serial debug unit or Silicon Labs CP210x UART Bridge won't work very well. If you own two similar devices, say two Heltec V4s, both devices will present the same manufactuer/product string. In the UNIX world, what would be the unique identifier would be the bus/device pair. The problem with that is that it is mutable. The next time you boot up, this identifier will change. A license plate is a good way to identify a car today, but next year that car may get a different plate.

The challenge is to create a human recognizable name that we can associate with an immutable connection identifier. In UNIX-land we can't do that. That why at each connection we force the user to choose a USB port from a drop-down list. Today, the right choice may be ttyUSB1. Tomorrow, the right choice might be ttyUSB3. If the user has two similar devices connected, the choice will be ambiguous. He or she will be presented with two choices: say ttyUSB4 and ttyUSB5. Without some more fanciy coding to see which of the two is already in use, the user will have to start trying the various options in turn or unplugging units until only one choice is left. That's not a user-friendly approach.

My best suggestion so far

Don't let the user name the connection card. Name them automatically in the form aaaa_bbbb_ccc where:

• aaaa is the short_name
• bbbb is the last four of the MAC address
• ccc is the connection type; TCP for http (WiFi or ethernet), BLE for Bluetooth, and USB for serial

In the short term, accept that the user will have to select the serial connection from a drop-down. In the longer term, do some fancy coding to determine the only reasonable available serial connection.