Network available devices (ESP*, MKR) are only listed with IP. label should be visible from the mdns-discovery

[ubidefeo]

Describe the bug

When deploying more than a single Local OTA enabled board, the mdns-discovery finds as many as available, and exposes the correct fields, but the label field is not transferred to / used by the IDE, hence listing the board as just an IP.
Once the board type is manually selected, it become associated.
(this connection seems to also be hard to break, needs investigation)

sample output of mdns-discovery for an ESP32 and a MKR1000

{
  "eventType": "remove",
  "port": {
    "address": "10.0.1.25",
    "label": "Arduino\\ MKR1000\\ v2 at 10.0.1.25",
    "protocol": "network",
    "protocolLabel": "Network Port",
    "properties": {
      ".": "mkr1000",
      "auth_upload": "yes",
      "board": "mkr1000",
      "hostname": "Arduino\\ MKR1000\\ v2.local.",
      "port": "65280",
      "ssh_upload": "no",
      "tcp_check": "no",
      "ttl": "4500"
    }
  }
}
{
  "eventType": "add",
  "port": {
    "address": "10.0.1.26",
    "label": "FeatherESP32 at 10.0.1.26",
    "protocol": "network",
    "protocolLabel": "Network Port",
    "properties": {
      "hostname": "FeatherESP32.local.",
      "port": "3232",
      "ttl": "120"
    }
  }
}
{
  "eventType": "add",
  "port": {
    "address": "10.0.1.24",
    "label": "MKRWiFi1010 at 10.0.1.24",
    "protocol": "network",
    "protocolLabel": "Network Port",
    "properties": {
      ".": "arduino",
      "auth_upload": "yes",
      "board": "arduino",
      "hostname": "MKRWiFi1010.local.",
      "port": "65280",
      "ssh_upload": "no",
      "tcp_check": "no",
      "ttl": "4500"
    }
  }
}

the last item is a MKR WiFi 1010 which as per the ArduinoOTA library (3rd party) returns arduino as a generic fallback, rendering the CLI unable to reverse-identify the board based on the board filed in boards.txt

To Reproduce

1. upload an OTA Sketch to one of the supported boards (MKR1000, ESP*)
2. MDNS Discovery will offer the newly available board in the Port menu
3. in Java IDE this item will also include the user-specified hostname
4. in IDE 2 this association is not created

Expected behavior

the label field returned by the Discovery should be used in place of address

Screenshots

IDE 1.8.16:

---

IDE 2.0 beta 12:

Desktop

• OS: any

Additional context

• Reported in ESP8266 as Arduino 2.0.0-beta.12 No hostname shown in OTA update, only IP address... esp8266/Arduino#8344
• Referenced in Network port support #123

[silvanocerza]

Closing this issue as we won't do it.

Recent versions of the mdns-discovery was returning ports that must not have been returned including those not supporting Arduino OTA. i.e. Printers, laptops and similar.

After arduino/mdns-discovery#23 is merged unsupported ports won't be shown anymore in the IDE.

[me-no-dev]

Closing this issue as we won't do it.

Recent versions of the mdns-discovery was returning ports that must not have been returned including those not supporting Arduino OTA. i.e. Printers, laptops and similar.

After arduino/mdns-discovery#23 is merged unsupported ports won't be shown anymore in the IDE.

I am not sure why you will not do it, given that you need to only change which property of the Port structure is being shown in the list, but OK. Also, those are not unsupported boards. At least they were supported up until now. Are you dropping OTA support for all third-party boards?

[per1234]

Hi @me-no-dev. I didn't see any mention of unsupported boards here.

"Unsupported ports" is in reference to random consumer devices (e.g., network connected printers) that were being discovered incidentally and cluttering the "ports" listing. The reason that is relevant is that it is more difficult for a user to find the correct port when there are additional irrelevant items in the listing.

There is no intention to filter the ports of 3rd party Arduino boards, and in fact Arduino has done a lot of work lately creating a general purpose pluggable discovery system which will allow boards platform developers (both Arduino's and 3rd party) to make their hardware discoverable by the Arduino development software via any communication channel.

[me-no-dev]

Hi @per1234 . I am commenting more or less on the issue's title and then the declination comment sounded like it will drop the above mentioned boards (which are good Arduino boards). I've been digging into the IDE and CLI the last few days in order to prepare ESP32-Arduino for the new features. The new discovery is what I am spending most time on. An issue I found can be seen here.

[ubidefeo]

@me-no-dev @per1234

I am convinced we should display a combination of label and IP, but the issue is that the ArduinoOTA library will default to arduino for board name, and that can be confusing.

We should resort to displaying the value of label coming out of the Discovery.

{
  "eventType": "add",
  "port": {
    "address": "192.168.1.10",
    "label": "MyMKR_wifi_1010 at 192.168.1.10",
    "protocol": "network",
    "protocolLabel": "Network Port",
    "properties": {
      ".": "arduino",
      "auth_upload": "yes",
      "board": "arduino",
      "hostname": "Peppe.local.",
      "port": "65280",
      "ssh_upload": "no",
      "tcp_check": "no"
    }
  }
}

Conforming to the Discovery Protocol specifications.
This will allow us to define the device name using the following syntax in ArduinoOTA

ArduinoOTA.begin(WiFi.localIP(), "MyMKR_wifi_1010", "password", InternalStorage);

and get the correctly formatted label as seen above.

I will assign this issue to @AlbyIanna to get it fixed and move on.
Thank you @me-no-dev for your patience

[kittaakos]

We should resort to displaying the value of label coming out of the Discovery.

Unfortunately, the IDE2 does not receive this information from the CLI. Although the properties are available, it does not contain the desired label. The IDE2 cannot do much without CLI changes.

See #1331 (comment)

---

I update the issue title to reflect that the label is the expectation, not the hostname.